Datum des Workshops: 07.09.2023
đ Themen und Ablauf
Im Rahmen des Workshops wurden zunĂ€chst einige grundsĂ€tzliche Informationen zur Initiative âStĂ€rkung von CRISâ wiederholt.
AnschlieĂend wurden anhand von drei PrĂ€sentationen die Besonderheiten, Vor- und Nachteile von Open-Source-Software vorgestellt und diskutiert. Als Beispiele fĂŒr Open-Source-Systeme dienten dabei die Forschungsinformationssysteme GRIS, VIVO und OSIRIS.
AuĂerdem wurde eine Mentimeter-Umfrage zum fachlichen Hintergrund der Teilnehmenden und zu Erfahrungen mit und Erwartungen an Open-Source-Software und Open-Source-CRIS durchgefĂŒhrt.
đ PrĂ€sentationen und Dokumente
Die im Rahmen des Workshops prÀsentierten Folien finden Sie hier in einem PDF-Dokument:
Zum Workshop gab es drei BeitrĂ€ge zum Thema âOpen-Source-CRISâ.
Holger Heuser vom GESIS â Leibniz-Institut fĂŒr Sozialwissenschaften erlĂ€uterte das Thema vor dem Hintergrund des Forschungsinformationssystems GRIS.
Christian Hauschke von der TIB â Leibniz-Informationszentrum Technik und Naturwissenschaften und UniversitĂ€tsbibliothek erlĂ€uterte das Thema vor dem Hintergrund des Forschungsinformationssystems VIVO.
Dr. Julia Koblitz von der DSMZ - Deutsche Sammlung von Mikroorganismen und Zellkulturen erlÀuterte das Thema vor dem Hintergrund des Forschungsinformationssystems OSIRIS.
Die Fragen und Ergebnisse der im Rahmen des Workshops durchgefĂŒhrten Mentimeter-Umfrage finden Sie hier:
đĄ Fragen und Antworten
Hier finden Sie einige im Verlauf des Workshops aufgeworfene Fragen und Antworten zum Thema âOpen-Source-CRISâ. Klicken Sie auf die Pfeilsymbole neben den Fragen, um die jeweiligen Antworten anzuzeigen.
â Der Begriff âOpen Sourceâ bedeutet, dass der Quellcode einer Software frei verfĂŒgbar ist, z.B. ĂŒber Services wie Git. Der Begriff âOpen Sourceâ an sich enthĂ€lt jedoch noch keine Angaben dazu, wie und unter welchen UmstĂ€nden der Quellcode (weiter) verwendet werden darf.
Hinter Open-Source-Projekten stehen in der Regel Communities von Entwickelnden und Nutzenden, die den Code pflegen und laufend weiter anpassen. Dies ist ein Unterschied zu proprietĂ€rer Software, hinter der in der Regel ein Unternehmen steht, das allein ĂŒber das Know-How und die Expertise fĂŒr die Software verfĂŒgt. Auch das Datenmodell einer Software ist bei Open-Source-Projekten offen.
â Da der Quellcode von Open-Source-Software frei verfĂŒgbar ist, ist jeder Zugriff darauf zunĂ€chst kostenlos. Dies bedeutet jedoch nicht automatisch, dass auch die Nutzung der entsprechenden Software kostenlos ist. In diesem Zusammenhang ist unbedingt auf die fĂŒr den Quellcode geltende Lizenz zu achten. Die Lizenz stellt die Nutzung der Software unter gewisse Bedingung, z. B., dass immer ein Urheberrechtshinweis enthalten sein muss oder dass jede weitere Ănderung dokumentiert werden muss. Je nach Lizenz könnten auch Kosten an den Urheber oder die Urheberin der Software zu entrichten sein.
Hiervon unabhĂ€ngig ist bei der Planung zu beachten, dass auch bei der Einrichtung und dem Betrieb von Open-Source-Software Ressourcen fĂŒr IT-Infrastruktur (Hardware), Betriebskosten, die Arbeit der Entwickler, fĂŒr Betreuungspersonen (User-Support, Administration und Wartung, Updates, Backup, etc.) benötigt werden. Durch die mit der EinfĂŒhrung von Software einhergehenden Ănderungen von Arbeits- und Organisationsprozessen entstehen ebenfalls AufwĂ€nde bzw. Kosten.
â In der Regel folgt die Programmentwicklung dem Modell des âuser centered designâ â der Blick auf die Nutzenden und ihre Anforderungen ist zentral, um neue Features einzufĂŒhren, die aus Anwendungsszenarien heraus entwickelt wurden. Die Prozesse können im Detail je nach Software unterschiedlich sein. Im Kern werden Features von Entwickelnden fertiggestellt (Commit) und spĂ€ter in eine aktuelle Version der Software eingefĂŒgt (Release). Dann können alle Nutzenden diese neue Version mit allen neuen Features ĂŒber ein Update erhalten. Hat eine Einrichtung weitergehende individuelle WĂŒnsche, kann sie sich von der laufenden Entwicklung abspalten (Fork) und die Software in eigener Regie selbst weiterentwickeln. Stellen sich die hierdurch individuell entwickelten Features als sinnvoll fĂŒr die Community heraus, können sie spĂ€ter auch in die offizielle Version der Software aufgenommen werden (Pull-Request).
â Die Lyrasis-Guidelines fĂŒr nachhaltige Open-Source-Software nennen folgende vier Aspekte:
- Governance: Es muss klar geregelt sein, wie neue Anforderungen, Erweiterungen, Bugfixes, Sicherheitsupdates usw. in das Open-Source-Projekt eingebracht werden und welche Rollen und Prozesse fĂŒr die strategische, taktische und operative Entscheidungsfindung existieren (Gesamtheit der Grundregeln fĂŒr eine Teilnahme am Projekt).
- Technology: Die Open-Source-Software muss den Herausforderungen der Community gewachsen sein. Die Technologie (der Code) muss verstĂ€ndlich und pflegbar sein; er sollte nicht ĂŒberkomplex sein und Weiterentwicklungen nicht erschweren.
- Resources: Open-Source-Programmierung nimmt Zeit in Anspruch, die Entwicklerinnen und Entwickler mĂŒssen in der Regel bezahlt werden. Gibt es dafĂŒr Sponsoren? Bekommen die Entwickler*innen ansonsten fĂŒr ihre Arbeit auf andere Weise genĂŒgend Anerkennung? Auch nicht-finanzielle Ressourcen spielen eine Rolle (z.B. Ăffentlichkeitsarbeit und Marketing, strategische Beratung, genĂŒgend spezifische AnwendungsfĂ€lle, um die Entwicklung der Software voranzutreiben, usf.). Um erfolgreich zu sein, benötigt ein Open-Source-Projekt daher eine stabile und vielfĂ€ltige UnterstĂŒtzungsstruktur, durch die klar wird, auf welche Weise und fĂŒr welchen Zeitraum das Projekt getragen und finanziert wird.
- Community Engagement: Es muss eine ausreichend groĂe Community von Nutzenden geben, die sich aktiv in das Open-Source-Projekt einbringen. Aus diesen sollen möglichst Stakeholder werden, die ein stabiler Teil des Systems sind und sich langfristig engagieren. Zentral dafĂŒr ist es, deren Engagement sichtbar zu machen und zu wĂŒrdigen. Da ein System niemals âfertig entwickeltâ ist, hinterlĂ€sst eine Software, die aus Mangel an Engagement seit lĂ€ngerer Zeit nicht mehr upgedatet bzw. modernisiert wurde, eher einen zwiespĂ€ltigen bzw. keinen guten Eindruck.
Sofern ein Open-Source-Projekt diese Anforderungen erfĂŒllt, kann der Einsatz der entsprechenden Software guten Gewissens in Betracht genommen werden. Die Eignung der Software fĂŒr einen spezifischen Zweck hĂ€ngt letzten Endes natĂŒrlich von ihrer FunktionalitĂ€t ab.
â Open-Source-Software kann viele Vorteile haben. Davon sind einige abhĂ€ngig von der ErfĂŒllung der Guidelines fĂŒr nachhaltige Open-Source-Software (s. oben).
- Wenn der Quellcode nicht nur frei verfĂŒgbar, sondern unter der fĂŒr ihn geltenden Lizenz auch frei nutzbar ist, entstehen keine Sachkosten fĂŒr die Anschaffung. Dennoch darf nicht davon ausgegangen werden, dass die Nutzung von Open-Source-Software keinerlei Kosten erzeugen wĂŒrde.
- Die gemeinsame Arbeit der Community an der Weiterentwicklung der Software kann die QualitĂ€t des Codes heben. HierfĂŒr kann auch ein Peer-Review-System sinnvoll sein.
- Da keine wirtschaftlichen Interessen hinter der Entwicklung der Software stehen, werden Fehler im Code nicht vertuscht, sondern von der Community angesprochen und nach Möglichkeit behoben.
- Beim Design stehen die Bedarfe der Nutzenden im Vordergrund. Es werden keine Features entwickelt, die nicht tatsÀchlich gebraucht werden.
- Die Daten der betreibenden Einrichtungen bleiben immer in eigener Hand. Das Datenmodell ist offen und transparent. Bei einem spĂ€teren Systemwechsel können Daten in der Regel daher ohne gröĂere Schwierigkeiten extrahiert werden, weil Architektur und Datenmodell der Open-Source-Software bekannt sind. Bei proprietĂ€rer Software hingegen ist das Datenmodell meist nicht oder nicht ausreichend beschrieben.
- Die ungewĂŒnschte Nutzung der eigenen Daten seitens Unternehmen mit kommerziellem Interesse (Datentracking) wird vermieden.
- Es entsteht keine AbhĂ€ngigkeit von einem Anbieter proprietĂ€rer Software in Bezug auf die Software selbst, die Metadaten oder die Integration mit anderer Software ĂŒber Schnittstellen. Ein Vendor Lock-In wird also vermieden.
- Open-Source-Software ist individuell anpassbar, sofern in der betreibenden Einrichtung die Expertise hierfĂŒr vorhanden ist.
- Open-Source-Software kann nachhaltiger als proprietĂ€re Software sein. LĂ€uft proprietĂ€re Software z. B. ĂŒber ein Lizenzmodell, kann sie nicht mehr verwendet werden, wenn die Lizenz nicht verlĂ€ngert wurde. Auch bei Mietmodellen ohne Lizenzerwerb ist eine Nutzung in der Regel nicht mehr möglich, wenn der Mietvertrag ablĂ€uft. Bei proprietĂ€rer Software kann auĂerdem der Support des Herstellers irgendwann eingestellt werden (z.B. um den Umstieg auf eine neuere Version zu befördern).
â Open-Source-Software bringt besondere Herausforderungen mit sich, die bei proprietĂ€rer Software nicht oder nicht im gleichen Umfang entstehen. Einige hiervon sind:
- FĂŒr den Betrieb von Open-Source-Software mĂŒssen neben finanziellen hĂ€ufig andere materielle oder immaterielle Ressourcen bereitgestellt werden, z. B. fĂŒr IT-Infrastruktur und fĂŒr das Personal, das die Software und die Nutzenden betreut. Zu beachten ist hierbei, dass auch bei proprietĂ€rer Software in der Regel solche Betreuungspersonen in der nutzenden Einrichtung vorhanden sein mĂŒssen. Es kann nicht davon ausgegangen werden, dass der Anbieter einer proprietĂ€ren Software dem Kunden 100 % der Arbeit abnimmt.
- FĂŒr alle Fehler der Software haftet bei einem Open-Source-Projekt die betreibende Einrichtung selbst. Dabei ist zu beachten, dass auch bei proprietĂ€rer Software der Anbieter hĂ€ufig nicht vollumfĂ€nglich die Haftung fĂŒr Fehler ĂŒbernimmt.
- Im Gegensatz zu proprietĂ€rer Software können bei Open-Source-Software in der Regel keine Service Level Agreements vereinbart werden, es existieren keine Notfall-Hotlines und keine direkt verantwortlichen Ansprechpersonen fĂŒr den Kundensupport. Eventuelle SystemausfĂ€lle oder -fehler mĂŒssen also primĂ€r selbst behoben werden.
- Die Gesamtkosten von Open-Source-Software sind schwer zu ĂŒberblicken, da sie zu groĂen Teilen aus Entwicklungszeiten und Arbeitszeiten von Betreuungspersonen bestehen. Zu beachten ist hierbei allerdings, dass auch die Kosten fĂŒr proprietĂ€re Software im Voraus schwer abzuschĂ€tzen sind, da hĂ€ufig nachtrĂ€gliche Ănderungen und Erweiterungen erforderlich werden. Kosten, die aus der notwendigen Anpassung von Organisations- und Arbeitsprozessen in der betreibenden Einrichtung entstehen, fallen sowohl bei Open-Source-Software als auch bei proprietĂ€rer Software an, werden von Anbietern proprietĂ€rer Software jedoch nicht mit eingepreist. Der Einsatz proprietĂ€rer Software fĂŒhrt also nicht in jedem Fall zu geringerem Personalaufwand als der Einsatz von Open-Source-Software.
- Bei der EinfĂŒhrung der Software kann es sinnvoll sein, zwischen den Nutzenden (die den Bedarf kennen) und den Entwickelnden eine vermittelnde Stelle einzurichten, um Probleme bei der Kommunikation zu vermeiden.
- Möglichst alle Nutzenden sollten fĂŒr die Open-Source-Software Verantwortung ĂŒbernehmen und ĂŒber Community-Arbeit an ihrer Weiterentwicklung mitwirken.
- Eine groĂe Community ist nicht in jedem Fall ein Vorteil. Werden Entwicklergemeinschaften zu groĂ, kann dies zu lĂ€ngeren Weiterentwicklungszeiten fĂŒhren.
- Es kann auch der Fall eintreten, dass die Open-Source-Software von ihrer Community in eine Richtung weiterentwickelt wird, die fĂŒr die eigenen Zwecke ungeeignet ist.
â Nein. Es ist möglich, Open-Source-Software zu nutzen und mit einem externen Anbieter mit entsprechender Expertise einen Vertrag ĂŒber die Einrichtung und/oder die Wartung und den Support zu schlieĂen. Auf diese Weise bleiben viele Vorteile der Nutzung von Open-Source-Software erhalten, wĂ€hrend gleichzeitig Supportleistungen im Prinzip wie bei proprietĂ€rer Software verfĂŒgbar sind. Ein Vendor Lock-In kann vermieden werden, da Open-Source-Software von unterschiedlichen Anbietern betreut werden kann. Je nachdem, welche Leistungen benötigt werden, können Support- und Wartungsleistungen allerdings sehr teuer werden (z. B., wenn es um die Programmierung von Schnittstellen zu anderer Software geht).
â In Einrichtungen der Leibniz-Gemeinschaft sind zurzeit folgende Open-Source-CRIS im Einsatz:
- GRIS: https://gris-leibniz.org/
- VIVO: https://vivo.lyrasis.org/
- OSIRIS: https://osiris-app.de/
- In Zukunft auch DSpace-CRIS: https://wiki.lyrasis.org/display/DSPACECRIS/DSpace-CRIS+Home
â Ja, das ist grundsĂ€tzlich möglich. Dabei ist allerdings zu beachten, dass fĂŒr die Einrichtungen dann in der Regel nur wenige (oder gar keine) individuellen AusprĂ€gungen des CRIS möglich sind. In diesem Zusammenhang ist die VerstĂ€ndigung auf eine einrichtungsĂŒbergreifende Standardisierung von groĂer Bedeutung. AuĂerdem muss geklĂ€rt werden, wie die verschiedenen Pflegeaufgaben (Nutzersupport, Einspielen von Updates, Anlegen von Datensicherungen, etc.) verteilt werden und wie ein solches gemeinsames Rechenzentrum langfristig finanziert werden kann.
Falls Sie noch Fragen haben, zu denen Sie die Antwort hier nicht finden konnten, schreiben Sie uns gerne eine Nachricht an cris@leibniz-gemeinschaft.de.