Wer eine empirische Abschlussarbeit schreibt, arbeitet praktisch nie ohne Software: R für Statistik, Python für Textanalyse, SPSS für die Umfrage, ein Python-Paket für Netzwerkanalyse, ein GitHub-Repo mit einem Preprocessing-Skript. Trotzdem taucht diese Software in vielen Arbeiten gar nicht im Literaturverzeichnis auf — und wenn doch, dann formal falsch. Dieser Beitrag zeigt dir, wann Software zitiert werden muss, wie du sie in APA 7, MLA 9 und Chicago 17 korrekt belegst, und warum die richtige Softwareangabe mehr über deine Reproduzierbarkeit sagt als jede Methoden-Beteuerung.
Wann Software zitiert werden muss
Nicht alles, was du am Computer öffnest, gehört ins Literaturverzeichnis. Die Trennlinie ist einfach: Formt die Software das Ergebnis mit — oder ist sie nur Werkzeug für die Darstellung?
- Zitieren: Statistikpakete (SPSS, Stata, R, SAS), R- und Python-Bibliotheken (lme4, scikit-learn, pandas), Analyse-Tools (MAXQDA, NVivo, Atlas.ti), Simulationssoftware, spezialisierte Modelle, jedes selbstgeschriebene oder aus GitHub übernommene Skript.
- Nicht zitieren: Word, Excel für Standardtabellen, PowerPoint, dein Browser, Zotero (das Tool, nicht die Zitate darin), das Betriebssystem.
Grenzfälle sind Excel für Berechnungen (nicht zitieren, aber die Formel dokumentieren) und generative KI wie ChatGPT (siehe unseren Beitrag zur KI-Quellenangabe — es gelten Sonderregeln). Für alles darüber hinaus gilt: Wenn dein Ergebnis von der Softwareversion abhängt, ist die Software eine Quelle.
Was in eine Softwareangabe gehört
Fünf Felder sind Pflicht in jeder Softwarezitation:
- Urheber:in — Person, Forschungsgruppe, Unternehmen oder Konsortium (bei R-Paketen häufig der/die Package-Maintainer:in, nicht “R Core Team”)
- Titel — Name der Software oder des Pakets
- Version — exakte Versionsnummer (bei GitHub-Code: Commit-Hash oder Release-Tag)
- Jahr — Veröffentlichungsjahr dieser Version
- URL oder DOI — bevorzugt DOI (Zenodo, Figshare, CRAN), sonst offizielle Projektseite
Die Version ist der am häufigsten übersehene, aber wichtigste Punkt. pandas 1.5.3 und pandas 2.1.0 verhalten sich in Randfällen unterschiedlich — wer deine Auswertung reproduzieren will, muss die exakte Version kennen.
APA 7 — der Standard in Sozialwissenschaften und Psychologie
APA 7 behandelt Software als Werk mit Autor:in, Jahr, Titel und Verlag/URL. Die Formatvorlage in [Software] bzw. [Computer software] ist Pflicht.
R und ein R-Paket
R selbst zitierst du so:
R Core Team. (2024). R: A language and environment for statistical computing (Version 4.4.2) [Computer software]. R Foundation for Statistical Computing. https://www.R-project.org/
Ein einzelnes R-Paket:
Bates, D., Mächler, M., Bolker, B., & Walker, S. (2024). lme4: Linear mixed-effects models using Eigen and S4 (Version 1.1-35) [R package]. https://CRAN.R-project.org/package=lme4
Die Autor:innen findest du mit der eingebauten citation()-Funktion:
citation("lme4")Das gibt dir eine formatierte Referenz plus ein BibTeX-Snippet. Verlass dich immer auf citation() — die Package-Metadaten sind autoritativ, im Gegensatz zu dem, was auf der GitHub-Seite steht.
Python-Paket
Python wird in Arbeiten meist als Sprache nur im Fliesstext erwähnt (Version im Methodenteil), einzelne Pakete aber vollständig zitiert:
Pedregosa, F., Varoquaux, G., Gramfort, A., et al. (2024). scikit-learn: Machine learning in Python (Version 1.5.2) [Computer software]. https://scikit-learn.org/
Viele Python-Pakete haben eine CITATION.cff-Datei im Repository — sie liefert die Autor:innen-Liste und einen DOI, wenn vorhanden. Ist ein Paper mit dem Paket verknüpft (bei scikit-learn das Pedregosa-et-al.-Paper), zitierst du zusätzlich das Paper.
SPSS, Stata, MAXQDA
Kommerzielle Software mit Firma als Herausgeber:
IBM Corp. (2023). IBM SPSS Statistics for Windows (Version 29.0.2) [Computer software]. IBM Corp.
VERBI Software. (2024). MAXQDA 2024 [Computer software]. VERBI Software. https://www.maxqda.com
GitHub-Repo ohne Publikation
Wenn du Code aus einem GitHub-Repo verwendet hast, das nicht als Paper oder Paket veröffentlicht ist:
Nguyen, T. (2024). thesis-preprocessing-pipeline (Commit 7a3f9b2) [Computer software]. GitHub. https://github.com/tnguyen/thesis-preprocessing-pipeline
Commit-Hash statt “main” — nur so ist dein Stand zitierbar. Wenn das Repo einen Zenodo-DOI hat (viele Repos bekommen den mit einem Klick), nimm den:
Nguyen, T. (2024). thesis-preprocessing-pipeline (Version 1.2.0) [Computer software]. Zenodo. https://doi.org/10.5281/zenodo.10123456
MLA 9 — die Core-Elements-Logik
MLA 9 hat keine feste Vorlage für Software, sondern nutzt seine Core Elements. Beispiel für ein R-Paket:
Bates, Douglas, et al. lme4: Linear Mixed-Effects Models Using Eigen and S4. Version 1.1-35, CRAN, 2024, cran.r-project.org/package=lme4.
Für ein GitHub-Repo:
Nguyen, Thi. thesis-preprocessing-pipeline. Version 1.2.0, GitHub, 2024, github.com/tnguyen/thesis-preprocessing-pipeline. Commit 7a3f9b2.
MLA verlangt im In-Text nur den Kurzverweis: (Bates et al.) oder (Nguyen) reicht. Bei mehreren Werken derselben Autor:in ergänzt du den Titel.
Chicago 17 — Fussnoten-Variante
Chicago Notes & Bibliography behandelt Software in der Fussnote ausführlicher als in der Bibliografie.
Fussnote (erste Nennung):
- Douglas Bates et al., lme4: Linear Mixed-Effects Models Using Eigen and S4, version 1.1-35 (CRAN, 2024), https://CRAN.R-project.org/package=lme4.
Bibliografie:
Bates, Douglas, Martin Mächler, Ben Bolker, and Steve Walker. lme4: Linear Mixed-Effects Models Using Eigen and S4. Version 1.1-35. CRAN, 2024. https://CRAN.R-project.org/package=lme4.
Bei GitHub-Repos ergänzt Chicago die Angabe um den Commit-Hash und ein Abrufdatum: commit 7a3f9b2, accessed July 12, 2026.
Wie du die Autor:innen und die Version findest
Die häufigste Ausrede für schlechte Softwarezitation ist “ich wusste nicht, wen ich zitieren soll”. Fünf Wege, die immer funktionieren:
- R:
citation("paketname")in der R-Konsole. Liefert formatierte Angabe plus BibTeX. - Python: Schau nach einer
CITATION.cff- oderCITATION-Datei im Repository. Fehlt sie, prüfepip show paketnamefür Autor und Version. - CRAN/PyPI/Conda: Die Projekt-Landingpage listet Autor:innen und die aktuellste Version.
- Zenodo/Figshare: Viele Forschungssoftware-Pakete bekommen dort einen DOI mit einer offiziellen Zitierempfehlung.
--version-Flag: Bei Kommandozeilen-Tools lieferttoolname --versionmindestens die Version, die du gebraucht hast. Ergänze das im Methodenteil.
Für R und Python empfehlen wir ausserdem, im Anhang einen sessionInfo()- bzw. pip freeze-Ausdruck einzufügen. Das ist die maximale Transparenzstufe und macht deine Analyse vollständig reproduzierbar.
Die häufigsten Fehler
Fehler 1: Nur “R Studio” ohne Version. RStudio ist die IDE, nicht die Sprache. Zitiert wird R (die Sprache) mit Version. RStudio-Version im Methodenteil erwähnen, wenn relevant, aber nicht im Literaturverzeichnis.
Fehler 2: “GitHub” als Verlag. GitHub ist der Hosting-Dienst, nicht der Herausgeber. Autor:in ist die Person oder das Team, das den Code geschrieben hat — GitHub gehört maximal in die URL, nicht ins Autorenfeld.
Fehler 3: Version fehlt oder ist “aktuellste Version”. Ohne Version ist die Softwareangabe wertlos. Reproduktion braucht die exakte Version, die du tatsächlich verwendet hast — nicht das, was heute auf CRAN steht.
Fehler 4: Paper zitiert statt Paket. Wenn du lme4 benutzt und das Bates-et-al.-2015-Paper zitierst, das die Methode beschreibt, hast du die Methode belegt, aber nicht die Software. Beides gehört ins Literaturverzeichnis, wenn du beides verwendet hast.
Fehler 5: Keine Angabe zu Custom-Code. Wenn du selbst ein Skript geschrieben oder ein Notebook zusammengestellt hast, das die Analyse durchführt, gehört das in den Anhang oder in ein öffentliches Repo mit DOI. Ohne diese Ablage ist deine Arbeit nicht reproduzierbar — und das schwächt die Bewertung, gerade in Fächern mit hohem empirischem Anspruch.
Fehler 6: KI-Tools als Software zitieren. ChatGPT, Claude oder Copilot als “Software” im Literaturverzeichnis zu führen, ist nicht korrekt — für generative KI gelten eigene Regeln (Prompt, Datum, Version, ggf. der Chat-Link). Diese Details behandeln wir im Beitrag zu ChatGPT als Quelle.
Reproduzierbarkeit ist der eigentliche Grund
Softwarezitation ist nicht Bürokratie, sondern Prüfstein deiner Methode. Wer die Version, den Paketstand und den Commit-Hash offenlegt, macht die eigene Arbeit angreifbar — aber auch belastbar. Wer sie weglässt, hat entweder nichts zu verbergen und wirkt trotzdem unsauber, oder er hätte etwas zu verbergen und riskiert bei jeder ernsthaften Prüfung einen Rückfrageblock, den er nicht mehr auflösen kann.
Faustregel für deine Abschlussarbeit: Ein anderer Mensch mit deinem Datensatz, deinem Skript und deiner Softwareliste muss auf dieselben Zahlen kommen. Wenn das nicht möglich ist, fehlt in deiner Dokumentation etwas — meist die Version einer Bibliothek oder der Commit-Hash eines Skripts.
Acurio prüft auch das
Wenn deine Arbeit Softwarezitationen enthält, prüft Acurio, ob sie im Fliesstext, im Methodenteil und im Literaturverzeichnis konsistent auftauchen. Häufigster Fund: Eine Version wird im Text erwähnt, im Literaturverzeichnis steht eine andere. Ein Paketname wird im Methodenteil aufgeführt, taucht aber im Verzeichnis nicht auf. Solche Inkonsistenzen sind für Prüfende ein Signal, dass die Reproduzierbarkeit nicht ernsthaft geprüft wurde — und genau darauf achten sie in empirischen Arbeiten inzwischen sehr genau.
Software zu zitieren ist eine Minute Arbeit pro Paket — und macht den Unterschied zwischen einer Arbeit, die replizierbar ist, und einer, die es nur behauptet. citation(), CITATION.cff, Zenodo-DOIs, Commit-Hashes: Die Werkzeuge sind da, sie werden nur zu selten benutzt.