Wann Software ins Literaturverzeichnis gehört
Programme verdienen ein eigenes Zitat, wenn sie die Erhebung, Transformation, Analyse, Simulation oder Visualisierung inhaltlich geprägt haben. Das betrifft nicht jede Textverarbeitung oder jedes Betriebssystem. Entscheidend ist, ob eine sachkundige Person die Software kennen muss, um den Forschungsweg zu verstehen, den Beitrag anzuerkennen oder die Analyse nachzuvollziehen. Eine Statistikbibliothek, ein spezieller Parser, ein Simulationspaket oder selbst entwickelter Analysecode erfüllt dieses Kriterium häufig.
Trenne zwei Aufgaben: Das Zitat identifiziert ein Forschungsobjekt und schreibt den Beitrag zu. Der Methodenteil erklärt, wie es verwendet wurde. Nur „mit Python analysiert“ ist methodisch zu ungenau; eine lange Installationsliste im Literaturverzeichnis ist dagegen nicht sinnvoll. Zitiere fachlich tragende Software und lagere die vollständige Umgebung in ein Environment-Protokoll aus.
Die bevorzugte Zitierangabe hat Vorrang
Suche auf der Projektseite, in der Dokumentation und im Repository nach „Cite“, „Citation“ oder einer Datei namens CITATION.cff. GitHub kann eine solche Datei maschinenlesbar darstellen und unter anderem APA- oder BibTeX-Ausgaben anbieten. Prüfe dennoch, ob die angezeigte Fassung zur tatsächlich genutzten Version gehört. Manche Projekte wünschen zusätzlich ein Zitat eines Methodenartikels; dieses ergänzt das Softwarezitat, sofern beide unterschiedliche Beiträge belegen.
Fehlt eine Empfehlung, ermittle die verantwortlichen Entwickler oder Organisation, den Softwarenamen, die konkrete Version, das Veröffentlichungsjahr und einen persistenten Identifikator. Ein DOI ist günstig, wenn ein Release in einem Repositorium archiviert wurde. Software Heritage kann archivierten Quellcode über einen SWHID identifizieren. Existiert nur ein laufendes Repository, sichere mindestens Tag oder Commit, Repository-URL und Abrufdatum. Ein Branchname wie „main“ ist allein nicht stabil, weil er auf neue Commits weiterwandert.
Release, Commit oder Softwarefamilie?
Wähle die feinste Ebene, die für deinen Befund relevant und dauerhaft referenzierbar ist. Wenn Version 2.3 die Berechnung erzeugt hat, ist genau diese Version meist geeigneter als ein DOI für alle Releases. Möchtest du die Geschichte oder das Gesamtkonzept eines Projekts besprechen, kann eine übergreifende Referenz passen. Zenodo unterscheidet beispielsweise zwischen dem DOI einer bestimmten Version und einem Concept DOI für sämtliche Versionen. Prüfe die Hinweise des Archivs, bevor du einen von beiden verwendest.
Ein Commit ist präzise, aber nicht automatisch dauerhaft verfügbar. Ein archivierter Release verbindet eine eingefrorene Fassung mit gepflegten Metadaten. Bei fortlaufenden Webdiensten kann eine exakte Wiederholung unmöglich sein; halte dann Zugriffsdatum, Anbieter, sichtbare Versionskennung, Schnittstellenstand und zentrale Parameter fest. Behaupte keine Reproduzierbarkeit, wenn der Dienst alte Ausführungsumgebungen nicht bereitstellt.
Software beschreiben, ohne das Zitat zu überladen
Schreibe in der Methode, welche Funktion die Software übernahm, welche Version lief, welche Module und Einstellungen entscheidend waren und wie die Ausgabe geprüft wurde. Für Codeprojekte gehören Lockfile oder Paketliste, Startbefehl und gegebenenfalls Random Seed in den technischen Nachweis. Bei grafischen Programmen dokumentierst du relevante Filter, Dialogoptionen und Exporte. So bleibt verständlich, welche Entscheidungen vom Programmstandard und welche von dir stammten.
Wenn du fremden Code verändert hast, benenne Ausgangsversion und eigene Änderungen getrennt. Ein Fork oder lokaler Patch ist nicht identisch mit dem Originalrelease. Lege eine Diff-Datei oder einen eigenen archivierten Stand an, sofern Rechte und Vertraulichkeit dies erlauben. Zitieren entbindet nicht von Lizenzbedingungen; Lizenz, wissenschaftliche Anerkennung und methodische Beschreibung sind drei verschiedene Ebenen.
Eigenen Analysecode auffindbar machen
Gib deinem Code einen verständlichen Titel, eine Versionskennung und eine Readme mit Zweck, Voraussetzungen, Startpunkt und erwarteten Ausgaben. Eine CITATION.cff kann Namen, ORCID, Release-Datum, Version und DOI in maschinenlesbarer Form halten. Vor einem öffentlichen Release müssen Zugangsdaten, personenbezogene Informationen, lizenzwidrig eingebundene Dateien und vertrauliche Pfade entfernt werden. Nicht alles, was technisch in einem Repository liegt, darf veröffentlicht werden.
Kann der Code nicht offen zugänglich sein, dokumentiere dennoch seine Identität und die Zugangsgrenze. Eine interne Archivkennung, betreute institutionelle Ablage und Prüfsumme sind belastbarer als „Code auf Anfrage“, wenn spätere Zuständigkeiten unklar sind. Beschreibe transparent, welche Teile aus rechtlichen oder ethischen Gründen fehlen.
Abschlussprüfung für jede Softwarequelle
- Stimmt die zitierte Version mit Logdatei, Ausgabe oder Environment-Datei überein?
- Führt DOI oder SWHID zu genau dem beschriebenen Objekt?
- Ist eine empfohlene Zitierangabe berücksichtigt, ohne sie ungeprüft zu übernehmen?
- Stehen Nutzung, Parameter und Abweichungen im Methodennachweis?
- Sind Begleitartikel und Software nur dann beide zitiert, wenn beide einen eigenen Belegzweck haben?