The manifesto. Seven principles for research code.

Much of science now runs on software. Results are computed, simulated, filtered and plotted by code that researchers write themselves. Science depends on peer review, and software contains errors. It follows that errors in code are errors in science. These seven principles describe how we think research code should be written, shared, reviewed and credited. They are not rules handed down by an institution. They are commitments any researcher can make, starting with their next paper.

7 principles

openpublic repoon request

Open over closed.

Research code should be open by default. When the code behind a result is closed, readers have to take the result on trust, and trust is not how science is supposed to work. Openness lets others check the method, reuse it and build on it. There are real reasons to restrict code: patient privacy, security, legal limits, third-party licenses. Those reasons should be stated, not assumed. Where code cannot be fully open, share what you can, describe what you cannot, and explain why. Closed should be a decision with a reason, never the default that nobody questioned.

I release the code behind my results under an open license, and I explain any exception.

cff-version: 1.2.0
title: soil-flux
doi: 10.5281/zenodo.x
type: software

Code is a research output.

Writing research software is research work. It takes design, judgment and domain knowledge, and it often takes longer than writing the paper. Yet code is still treated as a byproduct, hidden in supplements and left out of CVs and hiring decisions. That has to change. Code that supports a result deserves a persistent identifier, a citation and a clear list of contributors. When you use someone else's software, cite it the way you would cite a paper. When you write it, make it easy to cite. Credit is how good work gets noticed and how careers that build it survive.

I cite the software I use, and I make my own code citable.

42rate = c / t * 86400

42rate = c / t * 3600

Incorrect code means incorrect science.

Every nontrivial program contains bugs. In most software, a bug causes a crash or a wrong button. In research code, a bug can quietly change a number, a figure or a conclusion, with no visible sign that anything went wrong. This is not about blame. It is about accepting that code is part of the method, and that a flaw in the method is a flaw in the result. Tests, sanity checks and independent reruns are not optional extras. They are the experimental controls of computational work.

I test the code that produces my results and treat its errors as errors in my findings.

runs
matches paper
reusable

Code should be reviewed.

Peer review is how science checks itself, and code deserves the same scrutiny as the text that describes it. Review does not have to mean a line-by-line audit. It can mean a colleague running the analysis from scratch, a reviewer checking that the code matches the methods section, or a lab habit of reading each other's pull requests. Any review is better than none. Authors can help by making code easy to run and easy to read. Editors and journals can help by asking for code early, not after acceptance.

I ask for my code to be reviewed, and I offer to review the code of others.

v1.0.1DOI

v1.0.0DOI

mainlive

Code should be available and archived.

A link to a personal repository is not an archive. Accounts get deleted, services shut down, branches get rewritten and links rot. Code that supports a published result should be deposited as a fixed release in a long-term archive with a persistent identifier, so readers can retrieve the exact version used in the paper years later. Availability also means findable and accessible: a clear README, a stated license, listed dependencies and metadata that lets search tools find it. The goal is code that someone can locate and run long after the grant has ended.

I archive the exact version of code behind each publication with a persistent identifier.

README.md
## Reproduce Figure 3
make figure3
~ 4 minutes

Code for the future.

The most important future user of your code is often you, six months from now, with no memory of why it works. Write for that person. Document what the code does, how to install it, how to run it and what it expects as input. Record the versions of the language and libraries you used. Prefer clear structure over clever tricks. Maintainable code does not need to be perfect code, but it should be understandable by a competent stranger. That is what makes reuse possible, and reuse is where research software creates most of its value.

I document my code so that a competent stranger could install, run and understand it.

teachreviewmentor

Help others do the same.

Open, reviewed research code is a shared habit, not a solo achievement. Many researchers never received training in software practice, and many labs still have no norms for sharing code. If you have learned something, pass it on. Share your templates, review a colleague's repository, mentor a student through their first release, and ask journals and funders to set clear expectations. Be patient with people who are just starting. The aim is not to shame messy code but to make good practice ordinary, one lab and one paper at a time.

I help colleagues and students open, review and archive their code.