Als Thomas Hapke und ich die Idee “beluga” im September 2007 auf der GBV-Verbundkonferenz vorstellten, haben wir dabei ein Zitat aus der Nachhaltigkeitsbewegung benutzt: Global denken, lokal handeln. Warum? Weil wir rechtfertigen wollten, warum wir uns in Hamburg selbst an die Entwicklung eines Katalog 2.0 wagen wollten, während es auch damals schon mit vuFind und Co. einige Lösungen gab, die man hätte einsetzen können. Wir wollten aber bestehende Lösungen (zum Beispiel aus den ViFas für die Normierung von Metadaten) nutzen, um eigene Erfahrungen mit Suchmaschinentechnologie zu machen, unabhängig über Oberflächen entscheiden zu können und vor allem unsere im Projektantrag gemachten Versprechen bezüglich der partizipativen Entwicklung und der Anbindung der neuen Plattform an die Lernmanagementsysteme einhalten zu können. Wir waren – und sind – immer noch von dem Glauben beseelt, dass man den aktuellen Anforderungen an die neuen Kataloge am besten zunächst auf lokaler Ebene begegnet, nämlich über einen engen Kontakt mit der Zielgruppe und deren Wünschen, der Berücksichtigung der lokalen Gegebenheiten (welche Lernmanagementssysteme sind vorhanden) und der eigenen Ziele und Ressourcen.
In der “Make or Buy”-Frage haben wir uns also sehr bewusst für das “Make” entschieden und sind damit dem Vorbild anderer Bibliotheken gefolgt, die die Entwicklung solcher “Discovery Layer” wie beluga ebenfalls komplett selbst in die Hand genommen haben, z.B. Libris in Schweden, Summa in Dänemark, der KUG in Köln. Dass wir dabei ebenso wie genannten Projekte auf Open-Source-Lösungen in Punkto Suchmaschinentechnologie, Entwicklungsframework, Literaturverwaltung etc. gesetzt haben, zeigt, dass die “Make or buy”-Entscheidung im Grunde so nicht mehr gibt: Wer sich aufmacht, einen Katalog 2.0 zu entwickeln, wird sicher kaum je an bereits bestehenden Komponenten vorbeikommen, diese in seine Architektur einbauen und für die eigenen Zwecke anpassen. Von Grund auf selbst gemacht haben wir beluga also nicht – jedoch sehr bewusst auf die “Buy”-Schiene, also den Einsatz von kommerziellen Tools verzichtet. Zumal es eben auch auf dem kommerziellen Sektor keine maßgeschneiderten Lösungen für die Funktionen gab, die wir besonders gut machen wollten, nämlich die Anbindung an die Lernmanagementsysteme.
Warum ich das erzähle? Weil mir einer kürzlich angestellten historischen Betrachtung der Bibliotheksautomation aufgegangen ist, dass es so eine Art Goldgräberstimmung in den Bibliotheken schon einmal gegeben haben muss – nämlich damals in den 1970er Jahren, als sich man sich langsam zu regionalen Katalogisierungsverbünden zusammenschloss und einzelne Bibliotheken damit bekommen, so etwas wie ein integriertes Bibliothekssystem selbst zu entwickeln. Und ganz offensichtlich waren die damals in einzelnen Bibliotheken entstandenen Lösungen die Keimzelle für so manches kommerzielles Produkt, wie man beispielsweise im PICA-Museum nachlesen kann (niederländische Sprachkenntnisse vorausgesetzt). Marshall Breeding hat eine interessante Übersicht dazu erstellt, wie sich dann im Laufe der Zeit die erstmals große Vielfalt von kleinen Lösungen durch “Merger and Acquisitions” auf dem Markt der Hersteller von Bibliothekssystemen über die Jahre systematisch reduziert hat. Ken Chad hat auf dieses Phänomen die Theorie der “Disruptive Technologies” angewendet und aufgezeigt, dass der aktuelle Trend zum (Wieder-) Selbermachen von Software-Lösungen im Grunde eigentlich unausweichlich war: “Disruptive Libraries: The Potential for New Services” heißt sein lesenswerter Vortrag dazu.
Aber noch mal zurück zu den Pionieren in den 1970er Jahren: Die Kollegen (es ist wohl davon auszugehen, dass es eher Männer waren) haben sich also ihre eigenen Lösungen gebaut. Dass sie dabei konsequent ihre lokalen Bedarfe im Auge gehabt haben, halte ich für gegeben. Klar: Die Zeiten waren andere, ein “Public Access Catalog” war noch nicht dafür gedacht, von Usern in Eigenregie benutzt zu werden, sondern nur mit Anleitung durch Fachpersonal. Das Erbe dieser Zeit spüren wir mitunter noch bei den hoch spezialisierten Funktionen, die so manche OPACs noch haben und die die Bibliothekarin freuen, aber vom Publikum konsequent ignoriert werden (Stichwort: Erweiterte Suche!). Wir haben heute eher die BenutzerInnen und ihre Bedürfnisse im Blick – zwangsweise, möchte man sagen, denn ein Monopol auf wissenschaftliche Information haben Bibliotheken nicht mehr. Auch das hat sich seit den 1970er Jahren geändert. Und: Open Source ist erfunden. Uns stehen Lizenzmodelle zur Verfügung, mit denen wir unsere Eigenbau-Produkte einer Community zur Verfügung stellen können und damit so manche Mittelsmänner überflüssig gemacht in Angst versetzt. Es gibt also viele gute Gründe für Bibliotheken, Softwareentwicklung zu betreiben. Im Teilen von Code müssen wir bei beluga zwar noch besser werden, aber das Teilen von Erfahrungen funktioniert schon mal gut, oder?
Tags:theorie
Neben “Make” oder “Buy” gibt es ja noch “Buy someone to Make it”. Statt jahrelang zu warten “was von den Herstellern kommt” oder sich darüber zu beklagen dass zum Selbermachen kein Personal da ist, können ja auch Firmen oder freie Programmierer, Usability-Experten etc. beauftragt werden, etwas als Open Source zu entwickeln bzw. bei bestehenden OpenSource-Produkten benötigte Funktionen hinzuzufügen.
Der wesentliche Unterschied zu den 1970ern ist wie du richtig beschrieben hast Open Source. Ich befürchte nur dass durch Hosting-Angebote das wieder hintertrieben wird, solange nicht die Affaero General Public License verwendet wird.
Das Teilen von Erfahrungen funktioniert bei Beluga hervorragend (werde ich vsl. auch übernächste Woche bei meinem Vortrag bei der ELAG nochmal erwähnen, weil wir von eurer geteilten Arbeit bei der Suchkiste durchaus profitiert haben).
Aber: Wenn ihr es ernst meint mit Open Source, gebt euren Code frei, egal wie er aussieht! Open Source Projekte funktionieren nur in einer Community. Und die kann sich nur bilden, wenn sie Code hat. Und der Community ist es auch erstmal egal, wie der Code aussieht. Der eine Teil der Community wird sowieso nicht reinschauen, der andere kommt auch mit schlechtem, undokumentierten Code klar und wird ihn verbessern.
Ich habe in VuFind nie Code-Dokumentation vermisst und es war dennoch einfach, die Erweiterungen und Änderungen für die Suchkiste da hinein zu bauen. Ich habe mich auch nie über schlechten Code, sondern ihn einfach verbessert und committed… Ärgern kann man sich bei geschlossener Software, weil man nichtmal einfache Fehler schnell selbst beheben kann…
Und wie Jakob neulich schrieb: “Open Source ist unter Anderem deshalb oft kommerziellen Produkten überlegen, weil offene Systeme nicht so einfach ihren Dreck unter den Teppich kehren können.” Ich kann nach manchem Einblick in Code von kommerzieller Software nur sagen: Das ist so, da ist längst nicht alles schön, nur merkt es keiner. Bzw. wenn man es merkt, darf/kann man es nicht ändern…
Also: Los! Wenn ihr’s ernst meint, dann ab nach Sourceforge oder Google Code mit Beluga…
Viel könnte man noch diskutieren über die Wichtigkeit von Communities bei Open Source Projekten. Dazu ist aber schon sehr viel geschrieben worden. Einige aktuelle Überlegungen dazu, aufgehängt an einem Fall aus der Bibliothekswelt (Koha), kann man bei einem Blogartikel von Roy Tennant nachlesen (in Englisch, auch die Kommentare beachten): http://www.libraryjournal.com/blog/1090000309/post/280054428.html
Interessante Gedanken zum Thema. Dein Vortrag hier wird Augen öffnen, kann ich nur hoffen.
Nebenbei bemerkt, da wir schon ein paar Mal das Thema Frauen in Bibliotheks-IT angesprochen haben: NOTIS, wohl eins der ersten Bibliothekssysteme, wurde nicht nur von Männern entwickelt. Eine wesentlich Rolle spielte Velma Veneziano, und später wurde die Entwicklung von Jane Burke geleitet, die noch in der Branche tätig ist.
http://www.library.northwestern.edu/archives/new_libhist.pdf#page=5
Ob das in den USA eine Ausnahme ist, kann ich nicht ohne weitere Recherche nicht sagen. Aber NOTIS war eine bahnbrechende Entwicklung, also die Bedeutung kann man nicht unterschätzen, und da waren tatsächlich Frauen dabei. Schade, dass wir seitdem wenig Fortschritt gemacht haben, vielleicht sogar rückwärts gegangen sind.
Auch ich kann mich nur für die Verbreitung Eurer Erfahrungen durch dieses Blog bedanken. Denn gerade von diesem Teil der Software-Entwicklung – Usability-Tests, Fokusgruppen usw. konnten auch wir in Köln gut profitieren.
Überhaupt bin ich sehr dankbar für die vielen einschlägigen Blogs wie dem von Euch, Jakob usw., die mit ihren dort veröffentlichten Informationen immer wieder interessante Ideen für eine Weiterentwicklung und Verbesserung der eigenen Lösungen liefern.
Was dann konkret aus diesem Pool an Ideen, Code und Informationen kompatibel mit der eigenen Lösung ist, hängt ohnehin von den oft sehr individuellen Einsatzbedingungen vor Ort ab.
Die Fähigkeit aber, überhaupt davon unmittelbar profitieren zu können, geht nur mit offenen Systemen der Variante “Make” bzw. “Buy to make”.
Noch ein Anmerkung, zu einem anderen Aspekt des Artikels (da werden ja eine ganze Menge Themen angerissen): “Make or buy” ist doch eigentlich gar nicht die Frage. Denn selbst bei “buy” bleibt immernoch genug “make” übrig, wenn man am Ende etwas brauchbares haben will…
Ohne Anpassungen an lokale Gegebenheiten funktioniert im Bibliothekswesen doch keine Software von der Stange. Die Verbundzentrale macht eigentlich zum großen Teil nichts anderes als Anpassungen an gelieferter Software (“Systemintegration”). Und irgendwo stößt man dabei immer an Grenzen…
Vielleicht ist die Frage ja gar nicht “make or buy?” oder “kommerziell oder Open Source?”, sondern ob Bibliotheken Betrieb, Anpassung und Entwicklung ihrer “Informationstechnik”(!) als Teil ihres Kerngeschäfts begreifen und entsprechend professionell(!) betreiben? Man kann sich dafür ja vielfältige Modelle vorstellen, unter denen mir persönlich Community-Modelle sehr reizvoll erscheinen. Communities funktionieren aber eben nur, wenn die Mitglieder auch etwas beitragen…
Danke für die Kommentare! Rückmeldungen! Wir haben gerade teamintern darüber gesprochen, dass wir für “Friends and Family” gern ab sofort Einblick in den Quellcode geben. Dazu habt ihr teilweise schon eine Mail bekommen. Andere Interessierten ermöglichen wir das natürlich auch gerne – Gutwilligkeit beim Blick auf das unfertige und undokumentierte Werk vorausgesetzt. Bei Interesse einen Kommentar mit Mailadresse hinterlassen – aus Urlaubsgründen werden die Kommentare aber voraussichtlich erst in zwei Wochen bearbeitet.
“Richtiges” Open Source folgt später!
@Dale: Danke für den Hinweis auf Velma Veneziano und NOTIS – hochinteressant, auch der Artikel, auf den du verweist, denn da sind ja gleich zwei wichtige Themen angesprochen: Die Geschichte von Open Source in Bibliotheken und die Rolle von Frauen in der Software-Entwicklung. Erkläre Velma zu meinem Vorbild!
@Oliver: Das Lob für Transparenz in Form von Projektblogs etc. freut mich sehr. Ich gebe es dir aber mit dem gleichen Dank zurück, denn OpenBib an sich und dein Blog haben mich und das gesamte Team hier ebenso inspiriert.
@Till: Toller Satz: “Denn selbst bei “buy” bleibt immernoch genug “make” übrig, wenn man am Ende etwas brauchbares haben will…” Stimmt absolut – und erinnert mich an einen Einwand von Jakob auf dem Bibliothekskongress, dass der Ankauf einer kommerziellen Lösung auf keinen Fall bedeuten darf, dass man sich damit einspart, selbst nachzudenken und eben auch Hand anzulegen.
Interessante Überlegungen, aber sie kommen wohl doch eher bei den wissenschaftlichen Bibliotheken zum tragen, auch wenn sie für die öffentlichen Büchereien bestimmt ebenfalls von Bedeutung sind. Dort sind nach meiner Kenntnis i.d.R. die Ressourcen (Manpower & KnowHow) nicht vorhanden, um eigene komplexe Bibliothekssoftware zu entwickeln und – zu pflegen! In den 80er Jahren gab es dazu bei uns Versuche mit ISIS und ein Schulprojekt auf Excel-Basis. Ein Projekt mit einem fachfremden Programmierer musste Ende der 90er-Jahre abgebrochen werden. So hat nach meiner Kenntnis nur Allegro in der ÖB-Version den erfolgreichen Einsatz in die Praxis geschafft. Es ist für öffentliche Büchereien daher einfacher, Basis-Bibliothekssoftware und Anpassungen an spezielle Erfordernisse einzukaufen.
[...] Source und die Hilfe der Community wäre das Projekt bachelopac nicht möglich gewesen. Vielen Dank an alle, die uns unterstützt [...]
[...] Zitat im Zitat stammt aus einem Kommentar von Till Kinstler im Beluga-Blog. Ich würde den Einsatz von OSS nicht nur als Chance, sondern als zwingende [...]