Research software drives modern science — yet most papers still fail to cite it properly. Only about 1% of records in the Data Citation Index explicitly mention research software, despite the fact that computational tools underpin nearly every discipline from genomics to climate modeling. If you have ever used a Python library to analyze data, run simulations with custom scripts, or processed results through an open-source pipeline, you have used research software that deserves a proper citation. Learning how to cite software in an academic paper is not just good practice — it is essential for reproducibility, credit, and scientific integrity.
This guide walks you through everything you need to know: the principles behind software citation, how to make your own code citable, how to format software references in major citation styles, and how to avoid the most common mistakes researchers make when citing code.
Why citing software matters for research integrity
Software is as fundamental to research as the data it processes. A 2016 Nature survey of over 1,500 scientists found that more than 70% had tried and failed to reproduce another researcher's experiments, and 52% described a "significant crisis" of reproducibility in science. Improperly cited or entirely uncited software is a major contributor to this problem. When a paper omits the specific version of a statistical package, the exact script used to clean data, or the computational model that generated results, other researchers cannot verify or build on that work.
Beyond reproducibility, citing software is a matter of fairness. Research software developers — often early-career researchers, research software engineers, or PhD candidates — invest significant effort in building tools the community depends on. Without formal citations, their contributions remain invisible to hiring committees, funding agencies, and promotion boards. Proper software citation creates a paper trail that connects developers to the impact of their work, just as article citations do for authors of traditional publications.
The FORCE11 software citation principles
The FORCE11 Software Citation Working Group published a foundational set of principles in 2016 that have since been adopted by major publishers, including IEEE, Wiley, and PLOS. These principles state that software should be cited on the same basis as any other research product — papers, books, or datasets. The six core principles are:
Importance — software should be considered a legitimate, citable product of research
Credit and attribution — software citations should give scholarly credit to all contributors
Unique identification — citations should include a persistent, globally unique identifier such as a DOI
Persistence — unique identifiers and metadata should persist even if the software itself is no longer available
Accessibility — citations should facilitate access to the software, its documentation, and associated metadata
Specificity — citations should reference the specific version of the software used, not just the project as a whole
These principles are now embedded in the author guidelines of dozens of journals and are the backbone of modern software citation practice. If you follow them, your citations will meet the expectations of reviewers, editors, and funding agencies.
How to make your own code citable with GitHub and Zenodo
If you have written research software — whether a full application, a reusable library, or a set of analysis scripts — making it citable takes just a few steps. The standard workflow involves three tools: GitHub for hosting your code, Zenodo for archiving it and minting a DOI, and a CITATION.cff file for providing machine-readable citation metadata.
Step 1: Add a CITATION.cff file to your repository
The Citation File Format (CFF) is a human- and machine-readable YAML format designed specifically for software citation. When you add a CITATION.cff file to the default branch of your GitHub repository, GitHub automatically displays a "Cite this repository" widget in the sidebar, giving users ready-made BibTeX and APA citations.
Here is an example of a minimal CITATION.cff file:
cff-version: 1.2.0
message: "If you use this software, please cite it as below."
authors:
- family-names: Martinez
given-names: Elena
orcid: https://orcid.org/0000-0002-1234-5678
title: "Genome Alignment Toolkit"
version: 3.1.0
identifiers:
- type: doi
value: 10.5281/zenodo.7654321
date-released: 2025-11-15
Key fields to include are authors (with ORCID identifiers where possible), title, version, doi, and date-released. The CFF specification supports additional fields for references, license information, and repository URLs. You can validate your file using the tools provided on the Citation File Format website.
Step 2: Archive your code on Zenodo and mint a DOI
A GitHub URL alone is not a stable citation target — repositories can be renamed, made private, or deleted. Zenodo solves this by creating a permanent, versioned archive of your repository and assigning a DOI to each release.
To set up the Zenodo-GitHub integration:
Log in to Zenodo with your GitHub account
Enable the Zenodo integration for your repository in the Zenodo settings
Create a new release on GitHub — Zenodo will automatically archive it and mint a DOI
Add the DOI to your
CITATION.cfffile and your repository README
Each new GitHub release generates a new versioned DOI, while Zenodo also provides a "concept DOI" that always resolves to the latest version. Use the version-specific DOI in your citations so readers can access the exact code used in your study.
Step 3: Include citation instructions in your README
Even with a CITATION.cff file and a DOI, many users will look at your README first. Add a clear "How to cite" section that includes a formatted citation example and links to both the DOI and the CITATION.cff file. This removes friction and increases the likelihood that users will cite your software correctly.
How to cite software in different citation styles
The format for citing software varies by style guide, but the core elements are consistent: author(s), title, version, year, publisher or repository, and a persistent identifier (DOI or URL).
APA style (7th edition)
APA treats software as a standard reference entry. Include the author or organization, year, title in italics, version number in parentheses, a description in square brackets, and the URL or DOI.
Format:
Author, A. A. (Year). Title of software (Version X.X) [Computer software]. Publisher or Repository. https://doi.org/xxxxx
Example:
Martinez, E. (2025). Genome Alignment Toolkit (Version 3.1.0) [Computer software]. Zenodo. https://doi.org/10.5281/zenodo.7654321
IEEE style
IEEE follows the FORCE11 Software Citation Principles directly. Software is cited like a journal article with the addition of version and software type.
Format:
A. Author, "Title of software," Version X.X, Year. [Software]. Available: URL or DOI.
Example:
E. Martinez, "Genome Alignment Toolkit," Version 3.1.0, 2025. [Software]. Available: https://doi.org/10.5281/zenodo.7654321
Chicago style (17th edition)
Chicago treats software citations similarly to website or book references, depending on whether the documentation is published formally.
Format (Bibliography):
Author or Organization. Title of Software. Version X.X. Platform or Repository. Last modified Date. URL.
Example:
Martinez, Elena. Genome Alignment Toolkit. Version 3.1.0. Zenodo. November 15, 2025. https://doi.org/10.5281/zenodo.7654321.
MLA style (9th edition)
MLA emphasizes the author and title, with the platform listed as the publisher.
Format:
Author or Organization. Title of Software. Platform or Publisher, Year, URL.
Example:
Martinez, Elena. Genome Alignment Toolkit. Zenodo, 2025, https://doi.org/10.5281/zenodo.7654321.
BibTeX entry
For LaTeX users, the @software entry type (supported by BibLaTeX and many modern tools) is the most appropriate:
@software{martinez2025genome,
author = {Martinez, Elena},
title = {Genome Alignment Toolkit},
version = {3.1.0},
year = {2025},
doi = {10.5281/zenodo.7654321},
url = {https://doi.org/10.5281/zenodo.7654321},
publisher = {Zenodo}
}
If your BibTeX style does not support @software, use @misc as a fallback and include a note field specifying that the reference is computer software.
How to cite a GitHub repository in an academic paper
Citing a GitHub repository directly — without a DOI — should be a last resort. Repository URLs are not persistent, and they do not guarantee access to the exact version you used. However, if no DOI or archived version is available, you can still construct a proper citation.
The minimum information to include:
Author(s) or organization
Repository name
The specific commit hash or release tag you used
The date you accessed the repository
The repository URL
Example (APA):
Martinez, E. (2025). Genome Alignment Toolkit [Source code]. GitHub. Retrieved March 10, 2026, from https://github.com/emartinez/genome-alignment-toolkit (commit 4a8f2c1)
If the repository includes a CITATION.cff file, always use the citation it provides instead of constructing your own. GitHub displays this information directly in the repository sidebar under "Cite this repository."
Best practice: Before citing a GitHub repository, check whether the software has been deposited on Zenodo, Figshare, or another archive. A DOI-backed citation is always preferable to a raw URL.
How to cite Python packages, R libraries, and common research tools
Many researchers use widely adopted packages — pandas, NumPy, ggplot2, scikit-learn — without realizing these tools have preferred citation formats. Most major packages provide citation instructions in their documentation or repository.
Python packages
In Python, many packages include a __citation__ attribute or a CITATION.cff file. You can also check the package documentation or PyPI page. For example, scikit-learn asks users to cite a specific paper (Pedregosa et al., 2011) rather than the software package itself.
R packages
R has a built-in function for generating citations:
citation("ggplot2")
This returns a formatted citation that the package maintainer has specified. Always use this function rather than guessing the correct format.
General-purpose research tools
Tools like MATLAB, SPSS, Stata, and QGIS all have preferred citation formats listed on their websites. For commercial software, cite the company as the author and include the version number, year, and URL. For example:
MATLAB:
MathWorks. (2025). MATLAB (Version R2025a) [Computer software]. https://www.mathworks.com
What to cite: the software, the paper, or both?
Some software projects ask users to cite a published paper describing the software (a "software paper") rather than the software itself. Others ask for both. Follow the instructions provided by the software authors. If no guidance is available, cite the software directly — this ensures the specific version you used is recorded and traceable.
Common software citation mistakes and how to avoid them
Even researchers who understand the importance of software citation often make errors that undermine reproducibility and credit. Here are the most frequent mistakes and how to fix them.
1. Citing only the project website, not the software itself.
A URL like "https://www.example-tool.org" is not a citation. It does not identify a version, an author, or a persistent identifier. Always construct a full reference entry with author, title, version, year, and DOI or repository URL.
2. Omitting the version number.
Software changes between versions — sometimes dramatically. A paper that says "we used Package X" without specifying the version is incomplete. Always record and cite the exact version you used.
3. Mentioning software only in the methods section text without a reference list entry.
An in-text mention like "data were analyzed using R (R Core Team)" is not sufficient unless a full entry appears in the reference list. Treat software like any other cited work: in-text citation plus reference list entry.
4. Citing the wrong version or a generic "concept" DOI.
When Zenodo provides both a concept DOI (resolving to the latest version) and version-specific DOIs, use the version-specific one. The concept DOI is useful for linking to the project overall, but your paper should reference the exact version.
5. Not citing software at all because "everyone uses it."
Ubiquity is not a reason to skip citation. R, Python, and SPSS all have preferred citation formats. Citing widely used software acknowledges the developers and helps readers understand your computational environment.
How ScholarDock simplifies software and code citations
Managing software citations alongside traditional references is one of the most frustrating parts of modern research. Most reference managers were built for journal articles and books — they handle DOIs from Crossref but struggle with software-specific metadata like version numbers, commit hashes, ORCID-linked contributor lists, and repository URLs.
ScholarDock, a research project and reference management platform, is designed to handle non-traditional source types like software, code repositories, and datasets alongside papers and books in a single structured library. Instead of maintaining a separate spreadsheet for your software dependencies or scattering GitHub links across project notes, you can import software references directly into your ScholarDock library, tag them by project or methodology, and generate citation-ready bibliographies that include all the metadata reviewers expect.
For research teams working on computational projects, ScholarDock connects your software references to the projects and papers that use them. When a collaborator adds a new analysis script or updates a package version, the change is visible across the team's shared workspace — no more discovering at submission time that half your software citations are outdated. ScholarDock's collaborative features let you assign citation responsibilities, track which tools are used across multiple studies, and maintain a living inventory of your team's computational dependencies.
By bringing project management, reference management, and knowledge structuring into one connected workspace, ScholarDock eliminates the fragmentation that makes software citation so error-prone. You can organize references by project, by tool type, or by publication stage — and every reference stays linked to the research context where it matters.
Take control of your software citations
Citing software and code correctly is no longer optional — it is a professional expectation across disciplines. The FORCE11 principles, the Citation File Format, and the Zenodo-GitHub workflow have made it easier than ever to create, share, and cite research software with the same rigor you apply to journal articles. The key steps are straightforward: use a CITATION.cff file, mint a DOI through Zenodo, record version numbers, and format your references according to your target journal's style guide.
The real challenge is not formatting — it is keeping track of every tool, script, and package across multiple projects, collaborators, and papers. If your research team is tired of scattered software references, inconsistent version records, and last-minute citation scrambles before submission, ScholarDock brings your entire research workflow — sources, projects, code references, and collaborators — into one connected workspace where nothing gets lost.