Softwareentwicklung in Bibliotheken: Von Open Source bis "Not invented here"

Softwareentwicklung im BAM-Sektor (Bibliotheken, Archive, Museen) ist ein eher kleines Gebiet. Institutionen, die im Bibliotheksbereich eine eigene Softwareentwicklung aufweisen, sind vor allem:

• Akademische Bibliotheken (vorzugsweise Universitätsbibliotheken und überregionale National- und Zentralbibliotheken),
• Verbundzentralen (wie GBV, HEBIS, hbz, SBZ, KOBV),
• Fachinformationszentren (wie GESIS, DIPF, ZPID, FIZ Karlsruhe),
• Forschungseinrichtungen mit eigener Infrastrukturentwicklung (etwa Forschungszentrum Jülich, KIT Karlsruhe)
• sowie in Forschung und Lehre an Hochschulen und Universitäten (HdM Stuttgart, HAW Hamburg, FH Potsdam, Universitäten Konstanz, Regensburg, Hildesheim).

Eine Liste von Bibliotheken, Verbünden, Zeitschriften und Projekten sowie Entwicklerinnen und Entwicklern aus Bibliotheken hat Dr. Hendrik Bunke auf Github zusammengestellt . Diese Liste umfasst circa 40 Personen, was die grobe Hochrechnung zulässt, dass in dem Bereich bundesweit in etwa 120 bis 150 Personen als Softwareentwicklerinnen und -entwickler tätig sind.

Breites Spektrum an Themen

Die Tätigkeitsbereiche umfassen dabei schwerpunktmäßig wesentliche Aspekte einer “Digitalen Bibliothek” wie Bibliothekssysteme inklusive Benutzerverwaltung, Ausleihe, Bestandsentwicklung und Beschaffung, Katalogisierung, Webpräsenz, automatisiertes Metadatenmanagement, Suchmaschinentechnologie, Digitalisierung und Langzeitarchivierung, Publikationsplattformen, Repositorien, aber auch disziplin- oder institutionsspezifische Themen wie etwa eine softwaregestützte Thesaurusentwicklung und -verbreitung. Zu den in “neuerer” Zeit hinzugekommenen Themen zählen darüber hinaus Infrastrukturentwicklung für Forschung und Lehre, Forschungsdaten und -software, eigene (Informatik-)Forschung, Semantic Web oder auch Bestands- und Dokumentenanalyse in Form von Textmining.

Vielfältiger Technologiestack mit Open Source-Affinität

Der Vielfalt an geforderten softwaretechnischen Lösungen steht ein ebenso breites Spektrum an eingesetzten Technologien gegenüber. Im Allgemeinen kommt dabei eine Mischung aus kommerziellen Systemen beziehungsweise Komponenten (speziell bei Bibliotheks- und Discovery-Systemen), Open Source-Paketen und eigenen Entwicklungen zum Einsatz.

Ein branchentypisches Portfolio würde etwa die folgenden Frameworks, Plattformen, Entwicklungsumgebungen, Datenbanken und Programmiersprachen auflisten:
Postgre SQL, OCLC Pica, redhat, GitHub, DSpace, Eclipse, Apache, Apache SoIr, Apache Tomcat, phyton, perl, Rails, ExLibris Alma, ExLibris Aleph, Typo 3, Drupal.

Dabei zeichnen sich die im Bibliotheksbereich tätigen Entwicklerinnen und Entwickler im Allgemeinen durch eine große Affinität zu Open Source-Projekten und -Communities aus. Gründe dafür sind teils Reflexe gegen kommerzielle Softwareanbieter, obwohl Unternehmen wie Microsoft, SAP, Apple oder Oracle wesentlich zur Entwicklung und Akzeptanz von Software in vielen Lebensbereichen beigetragen haben oder sich selbst mitunter an Open Source-Projekten und -Entwicklungen beteiligen, wie die Beispiele Eclipse oder RedHat zeigen. Eher substantielle Argumente, die für eine Bevorzugung von Open Source im akademischen Kontext sprechen, sind dagegen: Die prinzipielle Offenheit von und der Zugang zu Standards, Protokollen, Formaten und Quellcodes sowie die grundsätzliche Wiederverwendbarkeit, möglichst unter gleichen Bedingungen. Zudem stellt das Open Source-Prinzip eine wichtige Basis für das Paradigma der Open Science dar, da beispielsweise die Replizierbarkeit von maschinell betriebenen Datenanalysen nur mittels einer Offenheit der dazugehörigen Software und Quellcodes erreicht werden kann.

Organisatorische Entwicklung von Software-Abteilungen in Bibliotheken

Insgesamt ist die Einrichtung eigener Software-Abteilungen im BAM-Bereich immer noch als verhalten zu bezeichnen. Zum Teil gibt es – wie zum Beispiel an der Universitätsbibliothek Tilburg – sogar Gegenbewegungen im Sinne von Outsourcing; es wird also auf Einkauf und Hosting von Dienstleistungen beziehungsweise Lösungen gesetzt. Softwareentwicklung als eigene Organisationseinheit dagegen “leisten” sich nur größere akademische Einrichtungen. Die organisatorische Verortung liegt dabei entweder in der ursprünglichen “klassischen” IT (Beispiele hierfür sind SUB Hamburg oder ZB MED),

oder in einer eigenen Abteilung, wie dies beispielsweise in der Niedersächsischen Staats- und Universitätsbibliothek Göttingen, in der Deutschen Nationalbibliothek oder in der Technischen Informationsbibliothek (TIB) zu beobachten ist.

Auch in der ZBW – Leibniz-Informationszentrum Wirtschaft wurde der zweitgenannte Weg gewählt. Der Wunsch, für IT-gestützte (Drittmittel-)Projekte und “Neuentwicklungen” besser gerüstet zu sein, führte vor circa zehn Jahren zur Gründung einer eigenen IT-Entwicklungsabteilung. Sie trägt mittlerweile den Namen “Innovative Informationssysteme und Publikationstechnologien (IIPT)” und umfasst aktuell neun Personen. Von Anbeginn wurde dabei ein dezentraler Ansatz verfolgt: Die Mitarbeiterinnen und Mitarbeiter werden bei den Services beziehungsweise (Haupt-)Produkten oder (Drittmittel-)Projekten angesiedelt. Dabei stand die Abteilung am Anfang vor allem personalstrategisch vor Herausforderungen.

Es ist kompliziert… Der Stellenmarkt

Als angespannt lässt sich der Stellenmarkt für IT-Entwicklerinnen und –Entwickler seit jeher bezeichnen – und zwar aus Bibliotheks- bzw. Arbeitgebersicht. Geeignete Personen, die auf der Suche nach einer neuen Stelle sind, lassen sich nur schwer finden. Insbesondere Entwicklerinnen zu finden, gleicht der Suche nach der Nadel im Heuhaufen, da der Anteil an Bewerberinnen von vornherein deutlich geringer ist. Die Verlängerung von Ausschreibungsfristen entsprechender Stellen lässt sich daher regelmäßig beobachten.

Zusätzliches Problem: Zumeist handelt es sich um befristete Projektstellen, die eine nachhaltige Personal- und Organisationsentwicklung erschweren – nicht selten ist die Vertragslaufzeit auf ein Jahr beschränkt, und Anschlussfinanzierungen werden nicht frühzeitig genug geklärt, um vorhandenem Personal eine längerfristige Perspektive bieten zu können. Dies führt entsprechend zu einer geringen Attraktivität für potentielle Bewerberinnen und Bewerber, zumal von ihnen in Stellenausschreibungen und daraus abgeleiteten Tätigkeitsprofilen oft verlangt wird, die sprichwörtliche “eierlegende Wollmilchsau” zu verkörpern. So werden neben den eigentlichen Kernkompetenzen auf dem Gebiet der Softwareentwicklung häufig auch Kenntnisse und Fähigkeiten im Projektmanagement, in der Betreuung verschiedenster Angebote sowie im systemadministrativen Bereich erwartet.

“Paradefall” Drittmittelprojekt

Oft sind Software-Entwicklerinnen und -Entwickler im Rahmen von Drittmittelprojekten in Bibliotheken tätig, bei denen die eigenen Entwicklungsleistungen in Form von Personalmitteln beantragt werden. Dabei beinhalten Drittmittelprojekte einige spezielle Herausforderungen: Die oft notwendige Vorabentscheidung für eine bestimmte Technologie führt zu einer Verengung des Stellenprofils. Aus diesem Grunde kommt es hier häufig zu offenen Ausschreibungen, um überhaupt zu einer signifikanten Bewerberzahl zu kommen. Drittmittelprojekte berücksichtigen in aller Regel nur die initiale Entwicklungsleistung. Die personelle und organisatorische Verstetigung, die dauerhaft einen wesentlich größeren Personal- und Kostenfaktor darstellt, ist nicht mitgeplant. Zum Teil werden daher mittlerweile Bereitschaftsbekundungen zur Übernahme produktiver Dienste durch Partner, wie etwa Servicezentren, eingesetzt. Aber auch dies stellt keine nachhaltige Lösung dar und ist vor allem bei fachlich getriebenen Entwicklungen nicht unbedingt geeignet, da letztere eine prinzipiell größere Nähe zur Nutzerschaft im Sinne einer bestimmten wissenschaftlichen Community erfordern.

Verbreitete Phänomene und Fallstricke in der Softwareentwicklung im BAM-Sektor

Mitunter lassen sich wechselseitige Missverständnisse zwischen Softwareentwicklung und Bibliotheksleitung beobachten, die daher rühren, dass seitens der Entwicklerinnen und Entwickler gelegentlich eine Haltung des “Was wir machen, interessiert “die da oben” eh nicht so sehr” vorzuherrschen scheint. Softwareentwicklung gilt buchstäblich als “black box”, die von ihren Protagonisten bisweilen gerne auch so gepflegt wird. Denn teilweise lässt sich auch das “Not invented here”-Syndrom beobachten, also ein Misstrauen gegenüber Ideen beziehungsweise Entwicklungen, die außerhalb der eigenen Organisation entstanden sind.

Eine Konsequenz dieser Einstellung ist, dass Eigenentwicklungen oft dem Einkauf oder der unentgeltlichen Übernahme von Fremdentwicklungen vorgezogen werden. Da es mitunter schwierig ist, sich in von anderen entwickelten Programmcodes zurechtzufinden, ist diese Haltung ein Stück weit verständlich. Andererseits ist festzuhalten, dass Eigenentwicklungen oft aufwändiger sind und vor allem langfristig schwerwiegende negative Folgen haben können. Denn wenn nur eine Person mit der von ihr oder ihm entwickelten Software vertraut ist und die Einrichtung verlässt oder ihr auch nur für einen längeren Zeitraum fernbleibt , wird es schwierig – wenn nicht sogar unmöglich – die Software auf einem gebrauchsfähigen Stand zu halten, geschweige denn weiterzuentwickeln.

Abgesehen davon macht das branchentypische Portfolio die Entwicklerarbeit auch nicht gerade einfacher: Die tendenzielle Fragmentierung der Frameworks, Programmiersprachen und Formate führt zwangsläufig auch zu einer Fragmentierung der Kompetenzen. Zudem werden nicht selten Entwicklerkapazitäten durch laufende IT-Aufgaben wie Maintenance und Systemadministration absorbiert, die anderswo dann wieder für möglichst innovative (Weiter-)Entwicklungen fehlen.

Insgesamt bleibt festzuhalten, dass sich auf nationaler Ebene zumindest bei den größeren akademischen Bibliotheken und Infrastruktureinrichtungen eine eigene Softwareentwicklung mittlerweile etabliert hat, die sich im Wesentlichen im Umfeld von Open Source-Projekten und -Communities bewegt. Dies eröffnet auch künftig weit reichende Möglichkeiten, etwa wenn es – abgesehen von den schon bestehenden Handlungsfeldern im Bereich „Digitale Bibliothek“ – im Zuge von “Open Science” um eine noch stärkere Verzahnung mit fachlich-wissenschaftlich motivierter Softwareentwicklung geht.