The quietest policy change in research output may be the one that turns code from a methods footnote into a retrievable object. Across funding agencies, journal offices, university research information systems, and disciplinary registries, researchers are being asked for a persistent identifier — a DOI, a Software Heritage identifier, a Research Resource Identifier, or an ASCL ID — for the software they wrote, not merely a GitHub link that can change or disappear. The distinction sounds technical. It is not. A URL says where a repository was; a persistent identifier says which version of the software was analysed, and where the archived copy lives.
The pattern should not surprise anyone who has watched data citation mandates spread through journals over the last decade. Software persistent identifier mandates are following the same path, only faster, because reproducibility checks now fail on missing code as often as on missing data. The consequence for working academics is that software is no longer a by-product of a grant. It is a research output with the same evidentiary weight as a dataset, and it will increasingly need the same identifying machinery.
A DOI is not a promise; it is a retrieval mechanism
The most common persistent identifier for research software is the digital object identifier, or DOI, minted through DataCite and registered by repositories such as Zenodo, figshare, an institutional repository, or a national data centre. A DOI points to metadata and a landing page; it does not by itself guarantee that the software is open, reviewed, or reusable. That gap matters because a DOI can attach to a private deposit with no public files and still satisfy a compliance box. Funders and journals are therefore layering two requirements: a persistent identifier plus a deposit in an archive that can actually retrieve the version.
Software Heritage works differently. It assigns intrinsic identifiers, called SWHIDs, from the content of the source code itself. A file, directory, commit, release, or full repository gets an identifier computed from its hash, which means the identifier can be verified against the object and does not depend on a single provider staying online. For biomedical research, the Research Resource Identifier, or RRID, has been used since 2014 to identify software, antibodies, cell lines, and other tools; many journals in the life sciences require RRIDs in methods sections. Astronomers have a similar discipline-specific identifier through the Astrophysics Source Code Library.
Where the requirements are appearing
Publishers moved first. The FORCE11 Software Citation Principles, published in 2016, asked authors to cite the specific version of software used and to include a persistent identifier when one exists. Nearly a decade later, journal policy has hardened from suggestion to condition. Nature Portfolio journals ask authors to provide code availability statements and, where a public repository exists, a DOI or other persistent identifier. PLOS and PeerJ use RRIDs in resource identification guidelines for tools and biological materials, and the American Astronomical Society journals long ago made software citations through the Astrophysics Source Code Library part of their standard reference practice.
Funders are following. The US Department of Energy's Office of Scientific and Technical Information runs DOE CODE, a software registration service that issues DOIs for packages developed with federal funding. Research councils in Europe have begun asking grant holders to include software in data management plans with appropriate identifiers, and the FAIR principles for research software (FAIR4RS), published in 2022, made identifiers a first-level requirement: to be findable and reusable, software must be uniquely and persistently identified.
The template was established by data citation mandates, which journals adopted before funders forced the issue; this site tracked that shift in an earlier report on data citation mandates. ORCID mandates for reviewers and editors anticipated the current move by attaching identifiers to people rather than objects. Both patterns make the software identifier expansion feel less like a novelty and more like the continuation of a decade-long effort to make research objects addressable.
Photo by Peaky Frames on Unsplash
Metadata without a fixed version is still a moving target
Most software in a lab is not a release; it is a branch. The identifier that matters is tied to a version, a snapshot, a release, or a specific commit, not to the repository's default view. Zenodo's GitHub integration illustrates how this works in practice: a researcher connects a repository, triggers a release, and Zenodo archives the exact state of the code and mints a DOI for that release. The GitHub URL remains convenient, but the DOI becomes the citation anchor. The DataCite guidance for software DOIs spells out that the object being registered should be a discrete version, not a fluid project.
Historians already know the lesson: a citation without an edition is a rumour. Software has no title page until somebody mints one.
There is a second, less obvious requirement. A persistent identifier needs metadata attached to be useful: title, authors, version, license, and a text file that tells users how to cite. The Citation File Format and codemeta.json are becoming the standard ways to carry that metadata inside a repository. Without them, a DOI can resolve to a landing page that lists no author names, which helps no one. Repository deposit workflows already handle this at scale, as institutional repositories have seen deposits surge; this site covered the pattern in an earlier report on repository deposits.
What this means for a faculty CV and a research lab
For an early-career researcher, software with a DOI is citable in the same places as a paper: ORCID, institutional repositories, annual activity reports, and promotion files. An assistant professor whose analysis code has a DataCite DOI has added a publication without adding a journal article; promotion committees are slowly learning to read those entries as first-class outputs rather than as technical appendices. The bar is low, which is why the policy change matters more in hiring and review than in compliance offices.
For a lab leader, the operational fix is small. Deposit the version, attach the citation file, register the identifier in progress reports. The strategic shift is larger: research groups that treat software as a product get reproducible results, cleaner handovers, and a visible output stream when grants close. This is not a compliance cost. It is a version-management habit with a persistent identifier attached to it.
The archive problem: a PID is not the same as preservation
A persistent identifier is only as durable as the archive behind it. Zenodo and institutional repositories are not immortal, and a DOI can outlive the hosting service that once resolved it. Software Heritage lowers that dependence because its identifiers and archive are tied to the content itself, but even that archive must be funded. The useful distinction is between identifier persistence and content preservation. A DOI promises stable resolution; it does not promise the files will remain accessible if the repository hosting the landing page closes.
That is the same problem that has stalked data citation mandates. A persistent identifier without a preservation guarantee is a promise written in metadata. The difference with software is that the source code is often the only complete record of the method. When the code disappears and the identifier remains, the citation points at a memory, not a method.
A short compliance checklist for research groups
- Deposit a released version, not a moving branch; tag a release in the repository first.
- Add a CITATION.cff or codemeta.json file with title, authors, version, license, and description.
- Use a repository that can mint a DOI or SWHID: Zenodo, figshare, an institutional repository, or Software Heritage.
- Record the persistent identifier in the funding agency's project reporting system, not only in the final paper.
- Check a journal's software citation policy before submission; include an RRID where the field uses RRIDs.
Software was long treated as the one thing science did not have to name, because code was assumed to be replaceable and private. The expansion of persistent identifier mandates changes that assumption. Naming the version is not the end of reproducibility. It is the point at which methods become addressable, and science becomes capable of arguing with its own code.