Most researchers assume the code attached to a paper is a courtesy. A link in the methods section, a nod to transparency, something a reviewer might skim. That assumption is out of date. A growing number of journals treat the repository as part of the submission itself, something an editor can require, a reviewer can run, and a reader can rebuild years later. The shift looks small on the page and lands as a lot more work in practice.
The old model and the new one still coexist, often inside the same publisher. It helps to hold them side by side and see where each one leaves the author, the reviewer, and the person who tries to reuse the code in 2032.
The Old Deal Asked for a Statement. The New One Asks for the Code
Through most of the last decade, the standard ask was a Code Availability Statement. One sentence telling readers where the code lives and under what license. That sentence is still the baseline, and major publishers' policies continue to require it in original research articles whose central claims rest on newly written code.
The newer ask goes further. At several journals the code itself comes in with the manuscript, and an editor can route it for review alongside the figures. A Nature Geoscience editorial walked through the Portfolio's trajectory on this, from a 2014 availability requirement to a 2018 policy under which papers with code central to the main claims undergo case-by-case code peer review, with the code supplied to editors and reviewers on request. The statement is the floor. The repository is the artifact.
A statement is cheap and scales to every submission; code review picks up the problems a statement will never surface. The second model is spreading because the first one, on its own, hasn't held up. Neliti coverage makes that point in its piece on why research software rots faster than the papers citing it, drawing on an analysis of tens of thousands of omics tools where a quarter of published URLs no longer resolved and roughly half of the installable tools were hard to install at all.
The Journal Side Has to Pay for This Too
Editors did not sign up to run containers. A Nature Human Behavior editorial announcing formal peer review of code behind computational models is candid about the cost: recruiting code reviewers, giving them time, and accepting that submissions move slower when the software is reviewed as a first-class object rather than a supplement.
The counterweight is what happens when nobody reviews it. Readers in year three try to rebuild the pipeline, fail, email the author, get a half-remembered answer, and give up. The method ends up uncited for computational work even as the paper keeps accumulating citations for the idea.
Habits That Keep the Repository Alive for a Decade
The paper is a frozen artifact. The code is a living dependency graph that tends to keep moving after publication. Unpinned libraries may resolve differently next quarter, GitHub URLs can point to repositories the author renamed, and a minor runtime upgrade can break an install on a machine the author will rarely see. The habits that matter are the ones that take the author's laptop out of the equation. None of them are heavy, and together they are what a reviewer, human or future, needs to actually run the thing:
- Lockfiles. Commit the exact resolved versions, not the loose ranges. A lockfile is the difference between "it installed" and "it installed the same way."
- Containers. A Dockerfile that pins the base image to a digest, not a tag, captures the OS and system libraries the lockfile cannot.
- Archived releases with DOIs. Push a tagged release to Zenodo or Software Heritage so the version cited in the paper has a persistent identifier that survives a GitHub rename.
- CI that rebuilds old versions. A scheduled job that rebuilds the container monthly will tell you the week something upstream broke, not the year a reader reports it.
- A one-command entry point. A single "make reproduce" or equivalent that goes from a clean checkout to the paper's figures. If it takes a reviewer an afternoon to figure out where to start, most reviewers will stop.
The direction of travel is clear enough. The repository is becoming part of the submission rather than an attachment to it, and the authors whose work survives the decade will be the ones who treated it that way on the day they hit submit.