4. Zenodo
Permanent archiving and citable DOIs for your research
5 min read
GitHub is great for version control and sharing code during a project — but it is not a permanent archive. Repositories can be deleted, renamed, or made private. Zenodo is a permanent, citable archive run by CERN that gives your research a DOI (Digital Object Identifier) that will work forever, even if the GitHub repository moves.
The key insight: reserve the DOI before you need it
Most researchers think about Zenodo only at the end, when they need to include a data availability statement. This creates a problem: you need the DOI before the paper is accepted (to put it in the manuscript), but you do not want to lock the version before you have made reviewer revisions.
The solution: Zenodo lets you reserve a DOI without publishing yet.
Reserve DOI now → put it in manuscript → submit → revise → accept → publish Zenodo record
↑ ↑
DOI exists DOI goes live
(not yet public) (permanently locked)Setting up the GitHub → Zenodo connection
One-time setup
Go to zenodo.org → log in with your GitHub account → Settings → GitHub → toggle your repository ON
Once connected, Zenodo watches your repository. Every time you create a GitHub release, Zenodo automatically archives a snapshot and assigns your DOI to it.
Before submission: reserve your DOI
Step 1
Go to zenodo.org → click New Upload
Step 2
Upload your derived data files (CSV, etc.) and fill in the metadata: title, authors, description
Step 3
Click “Reserve DOI” — you get a DOI immediately (e.g. 10.5281/zenodo.1234567)
Step 4
Do not click Publish yet — save as a draft. The record exists and has a DOI, but it is not yet public or locked.
Now put this DOI in your manuscript’s data availability statement:
Data and code supporting this study are available on Zenodo at
https://doi.org/10.5281/zenodo.1234567 (will be made publicly
available upon acceptance) and on GitHub at
https://github.com/yourusername/koura-habitat-mesocosmGitHub URLs can break — repositories get renamed, moved, or deleted. A Zenodo DOI is permanent and will always resolve, even decades from now. Journals and funders require a stable identifier, not a URL that might stop working.
Invite reviewers to check more than the PDF
Most journal submission systems only ask for a manuscript file — a reviewer can easily miss that there’s a live, working repository behind it unless you point them to it directly.
- Mention the GitHub and Zenodo links in your cover letter, not just buried in the data availability statement at the end of the PDF.
- If your journal has a dedicated code/data availability field or reviewer-notes box in its submission system, use it too, even if it repeats what’s already in the manuscript.
- For double-blind review, use the Anonymous GitHub mirror (see chapter 5) so you can still invite reviewers to check the code without revealing your identity.
A reviewer who only reads the PDF can only judge whether your results sound plausible. A reviewer who can open analysis.qmd can actually check your modelling decisions, catch an error before publication, or simply recommend acceptance with more confidence. Chapter 5 covers exactly what reviewers can see and how to give them access.
What to upload to Zenodo
Upload the things that are not in your GitHub repository (because they are too large or not code):
- Raw data files (CSV, Excel, shapefiles, images)
- Any data that cannot be publicly shared in full — describe it in the README and upload a sample or data dictionary instead
- The rendered PDF of your manuscript (after acceptance)
Your code does not need to be manually uploaded to Zenodo — when you create a GitHub release at acceptance, Zenodo archives the entire repository automatically.
Licensing
When creating your Zenodo record, you choose a license — this controls what others are allowed to do with your work once they have it. It’s a different question from who can access it in the first place, which is covered separately below.
Data: CC BY 4.0 · Code: MIT. These satisfy nearly every journal and funder requirement and are the most common choice in open research. Skip ahead unless you have a specific reason to choose differently.
Data licenses, in plain language
| License | What it means |
|---|---|
| CC0 | No rights reserved at all — public domain. Anyone can use it for anything, no attribution required. |
| CC BY 4.0 | Anyone can use, adapt, or even sell it — as long as they credit you. The standard choice for open research data. |
| CC BY-SA | Same as CC BY, but anything built on your data must be shared under the same license. |
| CC BY-NC | Same as CC BY, but blocks commercial use — others can’t sell products built on your data without asking you first. |
| CC BY-ND | Others can share your work as-is, but can’t adapt or modify it. Rarely used for research data since it blocks reuse. |
Code licenses, in plain language
| License | What it means |
|---|---|
| MIT | Do almost anything with it — use, modify, sell — just keep the attribution notice. Simplest and most common for research code. |
| Apache 2.0 | Like MIT, plus an explicit patent grant. Worth it if your method could be patentable. |
| GPL v3 | “Copyleft” — anyone who builds on your code must also release their version as open source. Protects against someone taking it closed-source. |
A restrictive license doesn’t stop your data from being visible to everyone. If you have data that genuinely can’t be public — Indigenous data sovereignty considerations, endangered species locations, participant privacy, commercially sensitive results — the license is the wrong tool. Use Zenodo’s access right setting instead:
- Open — anyone can view and download (the default, and what this guide assumes throughout)
- Embargoed — stays closed until a date you set, then automatically opens (useful when a patent filing or product launch needs to come first)
- Restricted — the record’s metadata is public, but the files themselves require a request, which you approve individually
- Closed — nothing is publicly accessible at all; only appropriate when nothing whatsoever can be shared, which most journals and funders won’t accept for a data availability statement
For genuinely sensitive data, the common pattern is: upload a sample or data dictionary as Open, and set the full dataset to Restricted with clear contact details in the README for legitimate access requests.