Pattern
A private repository lets a reviewer rerun code that can't be public
Code that can't be public, because of a patent plan, a contract or commercial value, can still be checked. Keep the companion repository private and invite the editor, the reviewers or the funder you choose. Software companies protect their code this way every day.
Available to a reviewer doesn't have to mean visible to everyone
Claim: recommendation
GitHub, GitLab and similar services let the owner of a private repository invite named people, give them read-only access and take it away later. An author can give a journal editor or a set of reviewers that access for the length of a review, and a funder or a licensee access under an agreement. They can rerun the analysis and compare the numbers, and the code stays as confidential as the owner needs.
This answers the most common objection to sharing code: "we can't make it public". The point of a companion repository is that the right people can rerun it, not that everyone can.
What would show this claim is wrong
- Reviewers invited into private repositories rerun the code no more often than reviewers of public ones.
- Journals or funders won't accept a private repository as meeting a code-sharing request.
The release a paper cites still needs a permanent record
Claim: recommendation
A private repository can change or vanish. So the release the paper cites should still be archived, privately if need be, with a fingerprint of its contents recorded where the paper can name it, so anyone given access later can confirm it's the same code the reviewers saw. Related records on private repositories are in Private repositories.
What would show this claim is wrong
- Archives can't hold a private release with a verifiable fingerprint at a cost research groups will pay.
Related
- Companion Executable Code Repositories
- Eidolons: working digital reflections
- Patient data stays governed and the code goes beside the paper