Citing software and code in your thesis — the practical guide

Anyone writing an empirical thesis works with software: R for statistics, Python for text analysis, SPSS for the survey, a Python package for network analysis, a GitHub repo with a preprocessing script. Yet this software rarely shows up in the bibliography — and when it does, the reference is often wrong. This post shows you when software needs to be cited, how to cite it in APA 7, MLA 9, and Chicago 17, and why a correct software reference says more about your reproducibility than any methods paragraph.

When software has to be cited

Not everything you open on the computer belongs in the bibliography. The dividing line is simple: does the software shape the result, or is it just a tool for presentation?

• Cite: Statistical packages (SPSS, Stata, R, SAS), R and Python libraries (lme4, scikit-learn, pandas), analysis tools (MAXQDA, NVivo, Atlas.ti), simulation software, specialised models, any script you wrote yourself or adopted from GitHub.
• Don’t cite: Word, Excel for standard tables, PowerPoint, your browser, Zotero (the tool, not the sources you manage in it), the operating system.

The edge cases are Excel for calculations (don’t cite, but document the formula) and generative AI like ChatGPT (see our post on citing AI — different rules apply). For anything else the test is: if your result depends on the software version, the software is a source.

What belongs in a software reference

Five fields are mandatory in every software citation:

• Author — person, research group, company, or consortium (for R packages usually the package maintainer, not “R Core Team”)
• Title — name of the software or package
• Version — exact version number (for GitHub code: commit hash or release tag)
• Year — release year of that version
• URL or DOI — DOI preferred (Zenodo, Figshare, CRAN), otherwise the official project page

The version is the most frequently omitted but most important item. pandas 1.5.3 and pandas 2.1.0 behave differently in edge cases — anyone who wants to reproduce your analysis has to know the exact version.

APA 7 — the standard in social sciences and psychology

APA 7 treats software as a work with author, year, title, and publisher/URL. The [Computer software] (or [R package]) descriptor in square brackets is required.

R and an R package

R itself:

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/

A single R package:

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

You find the authors with R’s built-in citation() function:

citation("lme4")

That prints a formatted reference plus a BibTeX snippet. Always rely on citation() — the package metadata is authoritative, unlike whatever appears on the GitHub page.

Python package

Python is usually mentioned as a language in prose only (with the version in the methods section), while individual packages are cited in full:

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/

Many Python packages ship a CITATION.cff file in the repository — it provides the author list and a DOI where available. If there is an associated paper (Pedregosa et al. for scikit-learn), cite the paper on top.

SPSS, Stata, MAXQDA

Commercial software with the company as publisher:

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 without a formal publication

If you used code from a GitHub repo that isn’t released as a paper or package:

Nguyen, T. (2024). thesis-preprocessing-pipeline (Commit 7a3f9b2) [Computer software]. GitHub. https://github.com/tnguyen/thesis-preprocessing-pipeline

Commit hash instead of “main” — it’s the only way to make the state you used citable. If the repo has a Zenodo DOI (many repos get one with a single click), use it:

Nguyen, T. (2024). thesis-preprocessing-pipeline (Version 1.2.0) [Computer software]. Zenodo. https://doi.org/10.5281/zenodo.10123456

MLA 9 — the core-elements logic

MLA 9 has no fixed template for software; it uses its Core Elements. Example for an R package:

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.

For a GitHub repo:

Nguyen, Thi. thesis-preprocessing-pipeline. Version 1.2.0, GitHub, 2024, github.com/tnguyen/thesis-preprocessing-pipeline. Commit 7a3f9b2.

MLA in-text is minimal: (Bates et al.) or (Nguyen). With multiple works by the same author, add the title.

Chicago 17 — the footnote variant

Chicago Notes & Bibliography treats software in more detail in the footnote than in the bibliography.

Footnote (first mention):

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.

Bibliography:

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.

For GitHub repos, Chicago adds the commit hash and an access date: commit 7a3f9b2, accessed July 12, 2026.

How to find authors and versions

The most common excuse for a bad software reference is “I didn’t know who to cite.” Five approaches that always work:

1. R: citation("packagename") in the R console. Returns a formatted reference plus BibTeX.
2. Python: Check for a CITATION.cff or CITATION file in the repository. If missing, pip show packagename gives author and version.
3. CRAN/PyPI/Conda: The project landing page lists authors and the current version.
4. Zenodo/Figshare: Many research software packages have a DOI there with an official citation recommendation.
5. --version flag: For command-line tools, toolname --version gives at least the version you used. Log it in the methods section.

For R and Python we also recommend including a sessionInfo() or pip freeze dump in the appendix. It’s the maximum-transparency level and makes your analysis fully reproducible.

The most common mistakes

Mistake 1: Only “R Studio” without a version. RStudio is the IDE, not the language. Cite R (the language) with its version. Mention the RStudio version in the methods section if relevant, but don’t put it in the bibliography.

Mistake 2: “GitHub” as publisher. GitHub is the hosting service, not the publisher. The author is the person or team who wrote the code — GitHub belongs in the URL at most, never in the author field.

Mistake 3: Missing version or “latest version”. Without a version, the software reference is worthless. Replication needs the exact version you actually used — not whatever CRAN happens to serve today.

Mistake 4: Paper cited instead of package. If you used lme4 and cite the Bates-et-al.-2015 paper describing the method, you’ve cited the method but not the software. Both belong in the bibliography if you used both.

Mistake 5: No entry for custom code. If you wrote a script or built a notebook that runs the analysis, put it in the appendix or a public repo with a DOI. Without that record, your work isn’t reproducible — and that weakens the grade, especially in disciplines that expect empirical rigour.

Mistake 6: Citing AI tools as software. Listing ChatGPT, Claude, or Copilot as “software” in the bibliography isn’t correct — generative AI follows its own rules (prompt, date, version, sometimes the chat link). See our post on citing ChatGPT for the details.

Reproducibility is the actual reason

Software citation isn’t paperwork; it’s the test of your method. Disclosing the version, the package state, and the commit hash exposes your work — but also makes it defensible. Leave it out and you either have nothing to hide but look sloppy, or you did have something to hide and can’t answer a single serious reviewer question.

Rule of thumb for your thesis: another person, given your dataset, your script, and your software list, must arrive at the same numbers. If they can’t, something is missing from your documentation — usually the version of a library or the commit hash of a script.

Acurio checks this too

If your thesis contains software references, Acurio checks that they appear consistently across prose, methods section, and bibliography. The most common finding: a version is mentioned in the text, a different version appears in the bibliography. A package name shows up in the methods section but is missing from the bibliography. Inconsistencies of this kind signal to reviewers that reproducibility wasn’t checked seriously — and reviewers now pay very close attention to exactly that in empirical work.

Citing software is a minute of work per package — and it’s the difference between a thesis that is replicable and one that only claims to be. citation(), CITATION.cff, Zenodo DOIs, commit hashes: the tools are there, they’re just used too rarely.