2. Handlungsbereiche

01 Recherche

Empfehlung: Bevor eine Software eingesetzt oder entwickelt wird, sollte recherchiert werden, welche Softwarelösungen bereits für die zu lösende Aufgabe existieren. Nutzer:innen sollten darauf achten, unter verfügbaren Lösungen möglichst nachhaltige Software auszuwählen (siehe Kriterien für nachhaltige Forschungssoftware). Für Entwickler:innen geht es darum sicherzustellen, dass es für die Aufgaben, für die sie eine eigene Software entwickeln möchten, noch keine anderweitigen Umsetzungen gibt. Außerdem müssen Entwickler:innen ggfs. recherchieren, auf welchen bestehenden Softwarekomponenten sie bei ihrer eigenen Arbeit aufbauen können. Diese sollten möglichst nachhaltig sein.

Anwendung: Recherche in Softwareverzeichnissen und Software Journals, in allgemeinen Code-Verzeichnissen oder in Plugin-/Modulsuchen für bestimmte Programmiersprachen und Softwarepakete.

02 Dokumentation

Empfehlung: Sowohl die Nutzung als auch die Entwicklung einer Forschungssoftware sollte angemessen dokumentiert werden – nicht erst am Ende des Prozesses, sondern von Anfang an. Nutzer:innen sollten z. B. festhalten, welche Software in welcher Version verwendet wurde, wo diese zugänglich ist, welche Anpassungen oder Einstellungen bei der Verwendung vorgenommen wurden (z. B. zusätzlich installierte Module, gesetzte Parameter) und welche Daten ein- und ausgegeben wurden. Ist die Verwendung einer Software Grundlage für Forschungsergebnisse, die publiziert werden, so sollte die Software unbedingt angemessen zitiert werden (08 Zitation und Anerkennung). Entwickler:innen sollten ihren Code von Anfang an dokumentieren (z. B. Funktionen beschreiben). Neben der Code-Dokumentation sind folgende Arten von Dokumentationen wesentlich: eine grundlegende Beschreibung der Ziele und Funktionen der Software, die Erfassung von (standardisierten) Metadaten zur Software, ein Nutzerhandbuch, ein Entwicklerhandbuch, Installationshinweise, die Dokumentation von Abhängigkeiten sowie Beispiele und ein Einstiegs-Tutorial für Nutzer*innen.

Anwendung: Für Entwickler:innen: Ausführliche Dokumentation und Beschreibung der Software in Dokumenten wie README, CONTRIBUTE, LICENSE, etc. Code-Dokumentation je nach Programmiersprache mit Frameworks wie Doxygen, JavaDoc, pydoc, etc.

03 Software Management

Empfehlung: Ein Software-Projekt muss organisiert werden. Hierfür sollte ein laufend zu aktualisierender Plan erstellt werden. Einen nicht zu unterschätzenden Aspekt stellt die Finanzierung dar: Für die Entwicklung, den Betrieb und/oder die Nutzung der Software sollte ausreichend ökonomisches und/oder soziales Kapital für die geplante (idealerweise explizit definierte) Einsatzdauer und den Zweck zur Verfügung stehen. Wer kommt für die Kosten z. B. eines Servers oder einer Lizenz auf? Wer wird die Software warten und aktualisieren? Wer wird sie bei Bedarf weiterentwickeln? Welche Personalkosten entstehen hierdurch und wie werden sie gedeckt? Allgemein sollten die Entwicklung und der Betrieb einer Software durch geeignete Methoden des Projektmanagements, die dem Umfang und den Zielen der Software angemessen sind, begleitet, gesteuert und administriert werden. Dafür können konkrete Workflows und Systeme z. B. zur Aufgabenverwaltung und Versionskontrolle (05 Versionsmanagement) verwendet werden.

Anwendung: Kalkulation/Finanzierungsmodell; Service Agreements z. B. mit einem Daten- oder Rechenzentrum; Issue und Bug Tracking z. B. in GitLab oder GitHub.

04 Qualitätssicherung

Empfehlung: Wie andere Formen wissenschaftlichen Outputs unterliegt auch Software bestimmten Qualitätskriterien. Hierzu zählen neben der Einhaltung von formalen Empfehlungen zur Nachhaltigkeit von Software (wie den vorliegenden) weitere Maßnahmen zur Sicherung der inhaltlichen bzw. Code-Qualität. Die Anwendung und Überwachung von automatischen Tests, z. B. ob eine Software fehlerfrei kompiliert werden kann, ist in diesem Zusammenhang ebenso wichtig wie eine Feedbackmöglichkeit für Nutzer:innen, welche während der Anwendung einer Software auf Fehler/Bugs stoßen (Bug Tracking, vgl. 03 Software Management).

Anwendung: Automatisches Testing, CI/CD-Pipelines, Bug Tracking z. B. in GitLab oder GitHub.

05 Versionsmanagement

Empfehlung: Die Entwicklung von Software ist ein fortwährender Prozess, bei dem die Software stetig angepasst, verbessert und weiterentwickelt wird. Um nachvollziehen zu können, wann, wo und von wem Änderungen durchgeführt werden und welcher Versionsstand einer Software in der Forschung eingesetzt wurde (Reproduzierbarkeit), wird die Nutzung eines Versionskontrollsystems dringend empfohlen. Der Einsatz von Konventionen zur Benennung von Software-Versionen ist unbedingt erforderlich.

Anwendung: Es existieren verschiedene Versionskontrollsysteme, von denen Git aktuell am weitesten verbreitet und für die Anwendung empfehlenswert ist. Speziell für kollaborative Projekte kann die Plattform GitLab sehr nützlich sein, da sie weitergehende Funktionalitäten wie Issue Tracking, Rechteverwaltung und Wikis bietet. Viele Einrichtungen bieten den Zugang zu institutionseigenen GitLab-Instanzen. Eine mögliche Alternative bieten GitLab oder GitHub, welches jedoch kommerziell betrieben wird. Der Einsatz von Git kann auch ohne webbasierte Plattform erfolgen. Für die Benennung einzelner Versionen bzw. Releases von Software existieren Konventionen (z. B. Semantic Versioning).

06 Lizenzierung

Empfehlung: Urheber:innen bzw. Vertreiber:innen müssen festlegen, in welchem Rahmen Anwender:innen Software einsetzen und ggfs. verändern und weiterverbreiten dürfen. Bei der Festlegung einer Lizenz sollten möglichst offene Lizenzen zum Einsatz kommen. Hier kann eine Abwägung mit der Anerkennung der Entwicklung und Bereitstellung der Software erfolgen, z. B. über erforderliche Namensnennung der Bereitsteller:innen.

Anwendung: Es steht eine Vielzahl veschiedener Lizenzmodelle zur Verfügung. Vor der Wahl einer konkreten Lizenz sollten Informationen über die Auswirkungen des Einsatzes eingeholt werden. Zur Orientierung gibt es vielfältige Informationsangebote (z. B. choosealicense.com). Nach der Wahl einer Lizenz sollte diese explizit und gut sichtbar in Softwareprojekten dargestellt werden, etwa in Metadaten, Beschreibungen und Dokumentationen der Software, und/oder mittels einer Datei namens LICENSE mit dem Lizenztext als Inhalt im Wurzelverzeichnis des Software-Pakets.

07 Publikation und Archivierung

Empfehlung: Wird Forschungssoftware genutzt, um zu veröffentlichende wissenschaftliche Ergebnisse zu produzieren, so sollten in der Publikation der Forschungsergebnisse auch Angaben zur Verwendung der Software gemacht werden (02 Dokumentation und 08 Zitation und Anerkennung). Nutzer:innen sollten auf den Ort verweisen, an dem eine Software publiziert oder archiviert ist. Entwickler:innen sollten die von ihnen entwickelte Forschungssoftware frühzeitig in Versionen veröffentlichen, soweit möglich unter einer offenen Lizenz (05 Versionsmanagement und 06 Lizenzierung). Dadurch kann es früh Feedback von Nutzer:innen und anderen Entwickler:innen geben, welches in die weitere Entwicklung einfließen kann (04 Qualitätssicherung). Zur Publikation einer Forschungssoftware gehört, dass sie mit geeigneten Metadaten beschrieben wird, dass sie dokumentiert ist, und auch, dass von den Entwickler:innen ein Vorschlag gemacht wird, wie die Software selbst von anderen Wissenschaftler:innen zitiert werden kann. Publizierte Versionen der Software sollten auch archiviert werden, damit sie dauerhaft verfügbar bleiben. Es ist anzustreben, die Software sowohl in Form von Source Code als auch in ausführbaren Formaten zu veröffentlichen, um Transparenz und eine leichte Nutzung und Nachnutzung zu gewährleisten. Darüber hinaus können eine wissenschaftliche Publikation über die Software (Software Paper) und die Veröffentlichung von Metadaten über die Software in Software-Repositorien und Registries dazu beitragen, dass die Software gut gefunden werden kann.

Anwendung: Publikation der Software selbst (Source Code, Package), Publikation von Dokumentation und Metadaten (in Software-Repositorien/Registries), ggf. Publikation eines Software Papers, Archivierung publizierter Software-Versionen und Vergabe von persistenten Identifikatoren für die Software und ihre Versionen z. B. bei Zenodo.

08 Zitation und Anerkennung

Empfehlung: Die Zitation von Software erfüllt wichtige Funktionen zum Beispiel für die Anerkennung ihrer Entwicklung und die Offenlegung von Quellen und Methoden im wissenschaftlichen Diskurs. Der notwendige Verweis auf verwendete Software basiert im Idealfall auf Zitationsempfehlungen seitens der Software selbst. Diese sollten konkret regeln, wie Anwender:innen die Software zitieren können und sollten. Die bislang weit verbreitete Angabe einer Webadresse/URL als Zitationsmethode greift i. d. R. deutlich zu kurz, vielmehr sollten Softwarezitationen in Form und Bedeutung denen bibliographischer Angaben gleichgestellt werden.

Anwendung: Die notwendige Zitation von Software durch Anwender:innen sollte durch eine konkrete und deutlich sichtbare Zitationsvorgabe in der Beschreibung und den Metadaten (möglichst zusätzlich als Datei CITATION.cff im Quellcode – wird z. B. unterstützt von GitHub, Zenodo, Zotero) zur Software vorgegeben werden. Mindestangaben umfassen hierbei die verwantwortlichen Personen, den Publikationszeitpunkt, die Softwareversion sowie eine persistente Referenz auf die Software-Quelle mittels PID (Persistent Identifier), DOI (Digital Object Identifier) o. ä.