ZBW MediaTalk

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.

Blogpost-Software-Logos-1100x619

 

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.

 

Autor: Dr. Timo Borst (Leiter der Abteilung Innovative Informationssysteme und Publikationstechnologien (IIPT), ZBW – Leibniz-Informationszentrum Wirtschaft)

The ZBW – Leibniz Information Centre for Economics is the world’s largest research infrastructure for economic literature, online as well as offline.

View Comments

  • Jakob VoßJakob Voß

    Author Reply

    Danke für den Überblick! Die Zahl von “bundesweit in etwa 120 bis 150 Personen”, die schätzungsweise in Deutschland als SoftwareentwicklerInnen an bibliothekarischen Institutionen tätig sind ist etwas willkürlich, scheint aber plausibel. Ich würde die Zahl etwas höher ansetzen, es kommt aber auch darauf an, ab wann jemand als SoftwareentwicklerIn im Gegensatz zu anderen IT-Tätigkeiten zählt.


    • Timo BorstTimo Borst

      Author Reply

      @Jakob: In der Tat etwas willkürlich, als „Hausnummer“ aber vielleicht nahe liegend. Ich habe natürlich keine systematische Erhebung gemacht, sondern anhand einer Liste akademischer Bibliotheken bzw. des mir dort bekannten Personals sowie von Veranstaltungen wie der SWIB überschlagsweise auf die Gesamtsituation zumindest in Deutschland geschlossen. Und auch in dem anderen Punkt gebe ich dir recht: Als reine Softwareentwickler beschäftigte Personen dürfte es eher weniger geben, darüber hinaus mit systemtechnischen und -administrativen Aufgaben versehene Personen eher mehr.


    • Ich glaube auch eher an wesentlich mehr Entwickler im deutschen Bibliothekswesen. Wenn man sich allein die SUB Göttingen anschaut, die ja zusätzlich noch eine F&E haben, kommt man bestimmt dort an 15 reine Entwickler/innen. Wenn dann andere große Häuser und die Verbünde ebenfalls noch hinzugerechnet werden, denke ich, dass es wahrscheinlich über 300 insgesamt sein werden. Es ist aber die natürlich die Frage, wen man als Entwickler rechnen will.

      P.S.: die Darstellung im Formular ist bei der Eingabe suboptimal, grau auf grau 🙂


      • Timo BorstTimo Borst

        Author Reply

        …richtig, die SUB hat in ihrer F&E einen relativ hohen Anteil – allerdings sind das m.W. fast durchgängig befristete Stellen. Ich war jetzt wirklich von Stammpersonal ausgegangen.

        P.S.: Das mit der Darstellung habe ich intern weiteregegeben, wird sich sicherlich beheben lassen…


  • Danke für den schönen Überblick.

    Ein Gedanke zu diesem Abschnitt:

    “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 […]”

    Es scheint tatsächlich im Bibliotheksumfeld sehr häufig Eigenentwicklungen von Einzelpersonen zu geben, aber das muss ja nicht so sein. Im Team kann man durch entsprechende Prozesse erreichen, dass alle die Software kennen. Von daher liegen die langfristigen negativen Folgen vielleicht eher daran, dass Einzelpersonen entwickeln, als dass es Eigenentwicklungen sind.


  • Timo BorstTimo Borst

    Author Reply

    @Fabian: Das ist sicher ein guter und wichtiger Punkt, meine Formulierung ist an dieser Stelle missverständlich: Gerade Eigenentwicklungen können und müssen seitens Bibliotheken und vergleichbaren Einrichtungen so organisiert sein, dass sie nicht von Einzelpersonen abhängen – auch wenn die Praxis häufig eben anders aussieht.


Next Post