Repositorien

In welchen Repositorien soll Forschungssoftware hinterlegt werden?

Zunächst sollte der Zweck des “Hinterlegens” geklärt sein:

  • Geht es um ein dauerhaftes “archivieren”, um den Zustand der Software zu einem bestimmten Zeitpunkt (etwa dem Erscheinen einer Publikation) zu dokumentieren? Dann kommen Forschungsdatenrepositorien wie z.B. Edmond oder Zenodo in Betracht, oder auch der Software Heritage Dienst.
  • Oder geht es darum, den Quellcode der Software in einem dafür geeigneten Softwarerepositorium zum Zwecke der Versionskontrolle abzulegen und weiterzuentwickeln? Dann sind spezifische Softwarerepositorien geeignet, zu denen z.B. github.com zählt. Beide Varianten lassen sich derart kombinieren, dass ausgewählte Schnappschüsse (“Tags”, “Releases”) automatisch auf Zenodo oder Edmond archiviert werden und unter einem Persistenten Identifier (DOI) (siehe auch die FAQs zu PIDs und Zitationen) referenzierbar gemacht werden.

Sodann ist zwischen einem weltweit offenen aber kommerziell betriebenem oder nur einem gewissen Nutzerkreis offenstehenden Dienst zu wählen. Beides hat Vor- und Nachteile. Weltweit offene Dienste haben in der Regel einen größeren Nutzerkreis und erleichtern somit das Kommentieren, Erweitern und Pflegen des Codes in dieser Gemeinde. Dagegen ist das kommerzielle Interesse der Dienstbetreiber zu sehen, die aus den veröffentlichten Inhalten und bei ggf. laxeren Datenschutzrichtlinien ihren Nutzen ziehen werden. Dagegen bieten institutionell gehostete Dienste ein größeres Maß an Datenschutz und Schutz von Urheberrechten, stehen aber nur einem begrenzten Kreis von Benutzenden offen, so dass die Verbreitung und Miteinbeziehung von Kolleg*Innen schwieriger ist. Oft kann es sinnvoll sein, die Entwicklung auf einer institutionell gehosteten Plattform zu beginnen, um das Risiko von frühzeitiger Verbreitung vor Veröffentlichung zu reduzieren. Nach erfolgter Veröffentlichung kann der Code dann auf eine kommerzielle Plattform umgezogen werden um die dortigen Vorteile der erhöhten Sichtbarkeit und Einbeziehung der Gemeinde zu nutzen. Die gängigen Plattformen wie github.com unterstützen das Importieren von bestehenden Repositorien über eine einfach zu benutzende Eingabemaske.

Softwarerepositorien

1. Gitlab

Angehörigen der MPG steht die von der GWDG betriebene Gitlab Instanz Verfügung, Nutzer der MPCDF haben zudem Zugang zu https://gitlab.mpcdf.mpg.de. Von einzelnen Instituten betriebene Instanzen stehen meisst nur den jeweiligen Institutsangehörigen offen.

GWDG Gitlab
  • Aufruf: https://gitlab.gwdg.de
  • Zugang: Über die AcademicCloud, d.h. man loggt sich mit dem einheitlichen Nutzernamen und Passwort ein, dass für alle GWDG Dienste genutzt wird (z.B. auch owncloud, overleaf, matrix chat, video conferencing big blue button uvm.). In den meissten Fällen, ist der Nutzername identisch mit der primären Email Addresse.
  • Versionskontrolle: Gitlab verwendet das Versionskontrollsystem GIT. Nutzende können ihre lokalen Repositorien mit Gitlab synchronisieren und darüber mit Kolleg*Innen gemeinsam den Quellcode editieren. Daneben können in Gitlab abgelegte Inhalte auch komplett online editiert werden.
  • Datentypen: Primär für Software (Quellcode) gedacht, unterstützt aber alle textbasierten Dateiformate, also z.B. auch Latex Manuskripte, Markdown Texte oder Tabellen im csv Format. Weniger geeignet für binäre Daten wie kompilierte Software, pdf Dateien, Bilddateien, Excel, o.ä.
  • weitere Informationen unter https://docs.gwdg.de/doku.php?id=de:services:email_collaboration:gitlab:start
MPCDF Gitlab
  • Webseite: https://gitlab.mpcdf.mpg.de
  • Betreiber: Max Planck Computing and Data Facility MPCDF
  • Zugang: Zunächst muss die Nutzung der Dienste der MPCDF beantragt werden, in der Regel geschieht dies über die IT Serviceeinheit des jeweiligen Instituts. Gitlab kann dann im Selfservice Bereich aktiviert werden.
gitlab.com
  • Webseite gitlab.com
  • Betreiber: Gitlab Inc.
  • Zugang: Weltweit offen. Login mit google, github und anderen Accounts per oauth möglich.

2. Github

Unter “GitHub” wird meist der Internetdienst https://github.com verstanden. Wie bei Gitlab kann aber auch Github von einer einzelnen Institution gehostet werden.

Github des MPI für Molekulare Genetik
github.com
  • Webseite: https://github.com
  • Betreiber: github inc, ein Unternehmen der Microsoft Gruppe
  • Zugang:
  • Zugang: Weltweit offen. Login mit google und anderen Accounts per oauth möglich.

3. Software Heritage

Der Webservice https://www.softwareheritage.org ist kein Repositorium wie github oder gitlab, auf dem aktiv Software entwickelt und gepflegt werden kann, sondern versteht sich als Archiv. Als solches durchsucht es automatisiert die gängigen Dienste wie github.com, gitlab.com und archiviert die dort gefundenen Softwareprojekte als Snapshot. Softwareprojekte, die auf nicht-indizierten Plattformen, wie z.B. institutionell gehostetet GitLab Instanzen, können unter https://archive.softwareheritage.org/save/ manuell archiviert werden. Dabei wird eine PID angelegt, ein Software Heritage Intrinsic Identifier (SWHID). Dieser PID kann dann z.B. in einer wissenschaftlichen Publikation angegeben werden, um die Software zu referenzieren. Der Vorteil von SWHIDs besteht z.B. darin, dass auch Fragmente des Quellcodes referenziert werden können. Mehr zu SWHIDs unter https://www.softwareheritage.org/save-and-reference-research-software/.

Generische Repositorien

  1. Edmond
  1. ZENODO
    • Webseite: https://zenodo.org
    • Betreiber: Europäisches Zentrum für Kernforschung (CERN, Hauptstandort ist die Schweiz)
    • Datentypen: Datensätze, Präsentationen, Manuskripte, Video- oder Audiomaterial, Software
    • Begrenzung: 50GB pro Upload, Anzahl der Uploads unbegrenzt (Stand 11/2023)
    • Registrierung: Emailaddresse oder federiert per ORCID (https://orcid.org), github, openaire
    • PID: Jeder Upload erhält eine DOI. Versionierte DOIs für jedes Update, spezieller DOI verlinkt immer auf die aktuelle Version
    • Sammlungen: Es können sog. “Communities” eingerichtet werden, um Datensätze z.B. einer Forschungskollaboration, eines Netzwerks oder eines Instituts zu sammeln.
    • API: REST-API über https://zenodo.org/api, siehe Dokumentation unter https://developers.zenodo.org/.
    • github Integration: Ein github Software Repositorium kann so konfiguriert werden, dass jedes Release automatisch eine neue Version eines Uploads auf zenodo erzeugt. Mehr dazu unter https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citing-content.
    • gitlab Integration: gitlab2zenodo ist ein Python Paket um automatisiert Schnappschüsse eines Softwarerepositoriums auf Zenodo zu publizieren.

Andere Forschungseinrichtungen wie z.B. die Helmholtz Gemeinschaft, Universitäten aber auch einzelne Bundesländer bieten inzwischen ihre eigenen Forschungsdatenrepositorien an, die auch Forschungssoftware unterstützen.

Unter welchen Umständen sollte Forschungssoftware (Quellcode) nicht öffentlich zugänglich gemacht werden?

(siehe auch die FAQs zu Sicherheit und Ethik sowie die FAQs zu Rechtlichen Aspekten)

Harte Kriterien

Die folgenden Kriterien sprechen klar gegen eine Veröffentlichung von Forschungssoftware

  • Vorgesetzte Person hat der Veröffentlichung nicht zugestimmt. Wie die Zustimmung der vorgesetzten Person eingeholt wird, sollte klar geregelt sein. Eine Möglichkeit besteht darin, dass die
    vorgesetzte Person Mitglied im Softwarerepositorium ist und (ggf. als einzige) das Recht hat, einen Release zu machen.
  • Die Software hat Dual Use oder militärische Verwendungsmöglichkeit (siehe OHB MPG VII.02.01 “Außenwirtschaftsrecht – Aufbau einer MPG-weiten Exportkontrolle”
  • Die Software steht nicht unter einer Opensource Lizenz
  • im Code befinden sich persönliche oder personenbezogene Informationen (z.B. Benutzernamen, Passwörter, Dateipfade)
  • Die Software wird im Rahmen einer Kollaboration erzeugt, deren Vertrag einer Veröffentlichung der Software widerspricht. Dies ist oftmals bei Industriekollaborationen der Fall. Auch bei anderen Kollaborationen (z.B. Sonderforschungsbereichen) sollte die Veröffentlichung von Software vertraglich geregelt sein.
  • In der Software wird Code benutzt, gelinkt oder weiterentwickelt, der nicht unter einer mit Veröffentlichung kompatiblen Lizenz steht.

Weiche Kriterien

Abseits der oben genannten harten Kriterien liegt es im Ermessen der Entwickler*Innen ob und zu welchem Zeitpunkt die Forschungssoftware öffentlich zugänglich gemacht werden soll. So ziehen es einzelne Entwickler vor, bereits im Anfangsstadium den Code öffentlich zur Verfügung zu stellen, um der Community die Möglichkeit der Mitwirkung zu bieten. Andere möchten erst eine gewisse Produktreife erreichen oder befürchten, dass ihre Ideen frühzeitig kopiert werden und sie dann ihren Entwicklungsvorsprung einbüßen könnten. Ein anderer Grund gegen Veröffentlichung der Software ist die bisweilen geäusserte Befürchtung, der Code könnte unsachgemäß oder unkorrekt benutzt werden, falsche Ergebnisse produzieren und somit das Renommee der Autoren beschädigen.

Die Fachzeitschrift “Demographic Research” hat hierzu eine Checkliste (pdf) erstellt.

Wo kann ich meine Software öffentlich zugänglich machen?

Unter der FAQ In welchen Repositorien soll Forschungssoftware hinterlegt werden? sind verschiedene spezifische und generische Repositorien aufgeführt, in denen Softwarequellcode abgelegt werden kann. Alle genannten Dienste erlauben es, den Zugang zu reglementieren (“Privates Repositorium”) oder öffentlich zu machen.

Welche Entwicklungsplattformen fördern eine kommunikative, gemeinsame Softwareentwicklung, die Platz für respektvolle gegenseitige Kritik bereithält?

Die oben genannten Softwarerepositorien Gitlab und Github beinhalten verschiedene Funktionalitäten, um Interessierten das Kommentieren, Melden von Fehlern und Bugs, Vorschläge für Erweiterungen bis hin zur direkten Mitarbeit am Projekt zu ermöglichen. Kommentare, Berichte von Bugs etc. werden üblicherweise in einem sogenannten “Issue” erfasst, diskutiert und abgeschlossen. Über die Funktion der Merge Request (gitlab) bzw. Pull Requests (github) können Entwickelnde eigene Erweiterungen vorschlagen und der Besitzer des Repositoriums kann diese wiederum kommentieren, ablehnen oder annehmen. Ein “gutes” Repositorium sollte klare Vorgaben machen, wie Feedback, Bugreports oder Merge/Pull Requests eingebracht werden sollten (z.B. mithilfe von Mustern und Beispielen) und dabei auf respektvollen Umgang hinweisen. Üblicherweise sind diese Vorgaben in einer Datei “Contributing.md”, “Community.md” o.ä. niedergelegt, die imStammverzeichnis des Repositoriums liegt (Beispiel: die Datei https://github.com/Bios4Biol/intronSeeker/blob/master/CONTRIBUTING.md im Repositorium https://github.com/Bios4Biol/intronSeeker).

Welche Infrastruktur muss an einem Institut und/oder durch die Max-Planck-Gesellschaft vorgehalten werden, um Forschungssoftware im Einklang mit Guter Wissenschaftlicher Praxis entwickeln zu können?

Technische Infrastruktur

  • Repositorium: Ein Software Repositorium (gitlab, github) ist in jedem Fall förderlich, muss aber nicht zwingend von dem Institut vor Ort vorgehalten werden, da verschiedene Lösungen MPG weit verfügbar sind (siehe Softwarerepositorien).

Personelle Infrastruktur

  • Wichtiger wäre, dass das Institut über Mitarbeitende verfügt, die fundierte Kenntnisse in der Entwicklung von Forschungssoftware haben, einen guten fachlichen Überblick über die Forschungsschwerpunkte des Instituts und denen die Regeln Guter Wissenschaftlicher Praxis geläufig sind.

Kultur

Entscheidend ist es jedoch, dass ein Klima der Offenheit gegenüber quelloffener Softwareentwicklung besteht. Nur die quelloffene Verfügbarmachung der Software stellt Überprüfbarkeit und Reproduzierbarkeit von erzielten Ergebnissen sicher und ist somit eine Grundlage Guter Wissenschaftlicher Praxis.

Wie werden die verschiedenen Rollen im Softwareentwicklungsprozess verteilt und festgehalten? Wer übernimmt die Projektinhaberschaft, Qualitätssicherung, Testen?

Nach Möglichkeit sollten verschiedene Personen verschiedene Aufgaben wahrnehmen:

  • Erstellen der Anforderungen an das Programm
  • Skizzieren der Komponenten und ihren Relationen (welche Klassen, Funktionen, etc.)
  • Schreiben des Programmcodes und der zugehörigen Tests
  • Review neuer und geänderter Programmteile
  • Autorisierung von Merge/Pull Requests in die Main/Master Branch
  • Autorisierung von Releases

Im wissenschaftlichen Kontext sind diese verteilten Rollen in den meisten Fällen nicht realisierbar. Wo möglich sollten die Aufgaben dann zwischen der/dem PI, und den Mitarbeitenden entsprechend ihrer Qualifikationen im Bereich der Softwareentwicklung aufgeteilt werden. Siehe auch die FAQ zu Unter welchen Umständen sollte Forschungssoftware (Quellcode) nicht öffentlich zugänglich gemacht werden?.

Wo kann ich nach eventuell bereits existierender Software für mein spezielles Problem suchen?

Generic (research) software collections

Humanities

Medical and Life Sciences

Physics

Mathematics

NIST Guide to available mathematical software (GAMS): https://gams.nist.gov/cgi-bin/serve.cgi/Packages (last update in 2010)

Machine Learning

Nanotech

Vorstehende Liste ist zum Teil den “Awesome Research Software Registries” entnommen.

Ist es notwendig neue Software (“from scratch”) zu entwickeln, oder kann ich andere Code-Projekte für meine Bedürfnisse anpassen und spezifisch erweitern?

  • beides ist legitim, aber zweites wäre resssourcenschonender, wenn möglich (Wirtschaftlichkeitsgebot gilt sehr stark für MPG (§ 1 BHO))

Wie archiviere ich Software im Max-Planck-Archiv?

Gar nicht. Archivierung von Software gehört nicht zu den Aufgaben des Max-Planck Archivs (vgl. https://www.archiv-berlin.mpg.de/41320/ueberlieferung)

Um Software zu archivieren, insbesondere über die 10 Jahre Aufbewahrungsfrist hinaus, bieten sich folgenden Dienste an:

Muss die Laufzeitumgebung (Hardware/Software) mitarchiviert werden?

Hier ist Praktikabilität und Langzeitlesbarkeit sowie -Nutzbarkeit abzuwägen. Folgende Gesichtspunkte können für eine möglichst Umfangreiche Komplettarchivierung sprechen (also inklusive aller Abhängigkeiten und Hardware)

  • Ergebnisse hängen stark von den verwendeten Versionen eingebundener Software und/oder Hardware ab
  • Software oder Abhängigkeiten können effizient nur auf einem besonderen Typ von Hardware laufen, der ggf. in absehbarer Zukunft nicht mehr verfügbar sein könnte.

Selbst wenn Argumente dafür sprechen, die komplette Laufzeitumgebung einer Software mitzuarchivieren, bedeutet dies nicht, dass ein kompletter PC oder Laptop achiviert werden muss. Laufzeitumgebungen lassen sich effizient in Softwarecontainern mitabspeichern, z.B. Docker oder Singularity. Diese beinhalten alle Komponenten der zu archivierenden Software, abhängige Bibliotheken aber auch Komponenten des Betriebssystems oder der Programmierumgebung, um das Programm auszuführen. Voraussetzung ist dann natürlich, dass diese Container in “>10 Jahren” selbst noch lesbar und ausführbar sind. Eine neuere Entwicklung sind sogenannte FAIR Digital Objects (FDOs), die nicht nur die Software und Betriebssystem, sondern auch die Forschungsdaten beinhalten. Mehr dazu unter https://fairdo.org/.

Wie stelle ich sicher, dass mein Quellcode 10 Jahre lang lesbar bleibt?

Zur Zeit ist nicht zu erwarten, das heute gängige Dateiformate in 10 Jahren nicht mehr lesbar sein könnten. Insbesondere wird Quellcode in einfachen Textformaten (ASCII) gespeichert, zu deren Lesbarkeit ein einfaches Texteditor Programm ausreicht. Zusätzlich könnte der Quellcode ausgedruckt und adäquat verwahrt werden.

FORS  IT4SCIENCE  GWP4RSE  FAQ  Technische Infrastruktur  Repositorien  github  edmond  gitlab  zenodo  Service  Archivierung