Software Heritage, the non-profit archive unveiled by Inria in 2016 with UNESCO backing, does something university repositories were never built to do: it stores source code as code, version by version, and hands out a persistent identifier for each snapshot. The SWHID resembles a DOI but hashes the file tree itself. That difference decides whether a reader in 2035 can rerun your analysis or only read the paper describing it.

Two Archives, One Citation Crisis

University repositories were designed around manuscripts. An institutional repository at a typical campus accepts PDFs, assigns a handle or DOI, and stores supplementary files as attachments. Code, if deposited at all, sits in a zip file with no version history. That works for a thesis and fails for a solver that has been patched forty times.

Software Heritage takes the opposite approach. It crawls public source repositories, ingests the full commit history, and preserves every revision it can reach. The archive's stated goal is to collect, preserve, and share the entire body of publicly available source code. Papers describe one moment; the code that produced them keeps moving.

Citation tools have not caught up. Reference managers store fields for author, journal, volume, and DOI. Fewer have native fields for software version, commit hash, or SWHID. A researcher citing a package ends up reaching for the paper DOI because that is the field the tool offers, and the code citation quietly disappears. This site has covered a related failure mode, where reproducibility checks stall when repositories stop accepting deposits.

How Software Heritage Indexes Code

The SWHID is a hash-based identifier, similar in spirit to a git commit hash but standardized and archive-independent. It can point to a directory, a file, a revision, or a release. Because the identifier is derived from content, two archives holding identical code produce the same SWHID. That property lets a citation survive the disappearance of the platform that hosted the code.

The project is structured as a non-profit multi-stakeholder initiative, governed rather than owned by a single company or ministry. Its crawler reaches public repositories on major hosting platforms and mirrors what it finds. It does not ingest private repositories, and it does not accept code that was never publicly reachable. Those limits matter for anyone assuming the archive is a universal backstop.

Coverage is broad but not exhaustive. Hosting platforms change their terms, rate limits throttle crawls, and some research groups keep code behind institutional login. A 2023 analysis of archived repositories found that a substantial share of links cited in papers pointed to code that had moved or vanished, though estimates of the exact proportion vary with the sampling method. The archive reduces that loss where it has crawled; it cannot recover what was never public.

University Repositories Fall Short

Institutional storage is tied to a single campus and a single administrative lifetime. When a faculty member retires, the local copy of their simulation code often retires with their account. A repository can hold the PDF of the resulting paper indefinitely. It rarely holds the twenty-year-old build scripts that made the figures.

Embargoes and login walls compound the problem. Many repositories restrict supplementary files to authenticated users, which blocks automated verification and blocks readers at institutions without a subscription. A DOI that resolves to a paywall is a citation that cannot be checked. Code archives sidestep this by design, since public code is public.

Version control is the deepest gap. Repositories treat a deposit as a fixed object, so a corrected release requires a new record with a new identifier and no formal link to the old one. Git-based archives keep the lineage. A related piece on this site describes what happens when that lineage is lost, in a Fortran solver whose unit tests outlived its physics.

Citation Divergence in Practice

Journals increasingly request a code availability statement, and some ask for a persistent identifier rather than a URL. The request is easy to satisfy in principle and awkward in practice. Authors who cite a GitHub URL give readers a moving target, because the default branch changes with every merge.

Adoption is uneven across fields. Computational statistics and numerical methods groups have pushed code citation norms for years, partly because their results depend on exact reruns. Other disciplines treat software as infrastructure and cite it in prose, if at all. The divergence is not a moral failing; it tracks how much a field's claims depend on the specific binary that produced them.

Reference managers remain the bottleneck. Adding a software entry often means typing the version and identifier into a free-text field, which then renders inconsistently in the bibliography. Until SWHID becomes a first-class field alongside DOI, the path of least resistance runs back to the paper citation.

What Reproducibility Requires

A reproducibility claim requires version-pinned code, not a link to a repository's front page. The distinction is concrete: a link to a project's homepage resolves to whatever the maintainers last pushed, while an SWHID resolves to the exact tree that generated the published figure. Only the second supports a rerun years later.

Computational statistics makes the requirement sharpest. A Monte Carlo estimate depends on the random seed, the library version, and the compiler. Change any one and the numbers shift. Effect sizes from simulation studies can move by amounts that matter for a conclusion, though the magnitude depends on the estimator and the problem.

Consider a common scenario: a researcher publishes a paper using a popular Python library for optimization. The paper reports a convergence rate. Two years later, the library updates its default solver parameters, and a reader trying to reproduce the result gets a different rate. The researcher had cited the library's DOI, which points to the latest version, not the one they used. Had they included an SWHID for the exact commit, the reader could check out that version and see the original behavior. This is not an isolated incident; it reflects a systemic gap in how we cite software.

The trade-off is real. Pinning every dependency produces an environment that is hard to rebuild on new hardware, and some maintainers argue that strict pinning discourages the updates that fix security flaws. The objection is fair. The practical compromise is to archive the exact version used while also recording the dependency constraints, so a future reader can choose between fidelity and repair.

Beyond SWHID: Other Persistent Identifiers

SWHID is not the only option. Some researchers use DOIs minted through services like Zenodo or Figshare, which can also version deposits. These services integrate with GitHub and can mint a DOI for each release. However, they often require manual synchronization and may not capture the full commit history unless the entire repository is archived as a snapshot. SWHID's content-based approach means that even if the original repository disappears, the identifier remains valid as long as the content exists in any SWHID-compatible archive. This resilience is particularly valuable for long-term preservation.

Another approach is to use git tags and record the commit hash in the paper. This is lightweight but relies on the repository remaining accessible. If the repository is deleted or made private, the hash becomes useless. SWHID, by contrast, is designed to be independent of any single hosting platform. The trade-off is that SWHID adoption requires tooling and awareness that many researchers lack. As a result, DOIs from general-purpose repositories remain more common, despite their limitations for code.

Practical Steps for Researchers

Deposit code in Software Heritage before the paper goes to press, and confirm the archive has crawled the relevant repository and revision. A deposit made after publication is better than none, but the version that produced the figures is the one worth pinning.

Mint an SWHID alongside the paper DOI and place both in the data availability statement, with the identifier pointing to the specific revision rather than a branch name. Reviewers can then check the exact tree.

Read the target journal's code-citation policy early, since some require a persistent identifier and some accept a URL, and the requirement shapes how much archiving work is needed.

Add a software entry type to your reference manager and store the version, the SWHID, and the access date in dedicated fields rather than a notes field. Check the rendered bibliography once, because software entries frequently drop the version number.

Finally, educate collaborators. A single missing SWHID in a multi-author paper can break the chain. When drafting the data availability statement, verify that every software component has a persistent identifier, not just a URL. This small step can save future researchers hours of guesswork.