# Software und Code in der Abschlussarbeit zitieren — der praktische Leitfaden > R, Python, SPSS, GitHub-Repos, Excel-Makros: Wann du Software zitieren musst, wie du es in APA, MLA und Chicago richtig machst und welche Fehler dich Punkte kosten. Acurio · 2026-07-27 · Zitieren, Software, R, Python, Reproduzierbarkeit, Bachelorarbeit 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](https://acurio.ch/blog/chatgpt-als-quelle-zitieren) — 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: ```r 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): > 1. 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: 1. **R:** `citation("paketname")` in der R-Konsole. Liefert formatierte Angabe plus BibTeX. 2. **Python:** Schau nach einer `CITATION.cff`- oder `CITATION`-Datei im Repository. Fehlt sie, prüfe `pip show paketname` für Autor und Version. 3. **CRAN/PyPI/Conda:** Die Projekt-Landingpage listet Autor:innen und die aktuellste Version. 4. **Zenodo/Figshare:** Viele Forschungssoftware-Pakete bekommen dort einen DOI mit einer offiziellen Zitierempfehlung. 5. **`--version`-Flag:** Bei Kommandozeilen-Tools liefert `toolname --version` mindestens 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](https://acurio.ch/blog/chatgpt-als-quelle-zitieren). ## 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](https://acurio.ch/), 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. ## Häufige Fragen ### Muss ich Excel oder Word wirklich zitieren? Nein. Allgegenwärtige Standardsoftware wie Word, Excel oder ein Browser wird nicht zitiert — genauso wenig wie ein Kugelschreiber. Zitieren musst du Software, die deine Ergebnisse formt: statistische Pakete, spezialisierte Analysewerkzeuge, R- oder Python-Bibliotheken, Datenbank-Software. Faustregel: Würde jemand mit anderer Software ein anderes Ergebnis bekommen? Dann zitieren. ### Reicht es, die Software im Methodenteil zu erwähnen? Fast — aber nicht ganz. Die Nennung im Fliesstext ('analysiert mit R 4.4.2 und dem Paket lme4 1.1-35') gehört zwingend in den Methodenteil. Dazu kommt aber ein vollständiger Eintrag im Literaturverzeichnis, sonst fehlt die formale Nachvollziehbarkeit. Ohne den Eintrag könnte man deine Analyse nicht replizieren. ### Wie zitiere ich ein GitHub-Repo, das keine offizielle Publikation ist? Als Software mit Urheber, Titel, Version (Commit-Hash oder Release-Tag), Jahr, URL und Abrufdatum. Wenn das Repo einen Zenodo- oder Figshare-DOI hat, nutze diesen — er ist stabiler als der GitHub-Link, weil er auf eine unveränderliche Kopie zeigt. Ohne DOI ist der Commit-Hash der einzige Weg, den Stand deiner Analyse eindeutig zu dokumentieren. --- Source: https://acurio.ch/blog/software-code-zitieren