Publishing Code

Using GitHub releases and Zenodo DOIs
to create citable code snapshots

Stephen Formel

2026-01-29

Examples

Instrument: Low-Cost Water Sampler

Pipeline: eDNA analysis

Analysis: Biodiversity Indicators

Documentation: Workshop

Why publish code?

Better World

Better Future

make life easier!
reduce self-loathing!

Enable Science

drive reuse!
and extension!

Get Credit

credit is the currency of science!
mo’ money, less problems!

Timing: 2 min
Set expectations. This is about concepts first, mechanics second.
Emphasize that this mirrors data publishing practices participants may already know. 1. Increase FAIR-ness 2. Make life easier for future you 3. Enable reuse and extension 4. Get credit for software as a research output

The long view: a haiku.

science lives when tools

fade. Links rot but snapshots save

your work from the void

Whale Fall Actively Devoured by Scavengers at Davidson Seamount, Nautilus Live (2019) https://www.youtube.com/watch?v=CZzQhiNQXxU

Timing: 1 min Science outlives tools and platforms. Papers persist. Links rot. Without snapshots, methods cannot be verified.

GitHub is not an archive

• Excellent for collaboration
• No preservation guarantee
• Not designed for citation
• owned by private corporation (Microsoft)

Timing: 1 min
Be explicit that this is not anti-GitHub.
GitHub does its job very well. It just does not do this job.

What is a code archive?

Persistent and referenced via PID

Findable and citable

Immutable once published

Backed by long-term infrastructure

Timing: 1 min

(for code)

Generalist research repository

Free and widely used

Issues DOIs via DataCite

Integrates with GitHub releases

operated by CERN

Timing: 1 min
Do not go deep here. Zenodo is familiar enough.
We are focusing on the GitHub integration. CERN == European Organization for Nuclear Research, an intergovernmental organization funded by 23 member states

+ model

GitHub: active development | where code lives

Zenodo: frozen snapshots | where code is cited

Timing: 1 min

Where will you use this?

Instrument development

Pipeline development

Analysis iteration

Code-based documentation

Timing: 2 min
Ask students to come up with examples

Versioning and DOIs

Each GitHub release → new Zenodo version

Each version gets its own

One parent ‘concept’ always points to the latest version

Timing: 2 min
This mirrors the Zenodo versioning explanation from the dataset clinic.

Let’s Practice

Pre-work:

did you make a account?

If not, do it here

Timing: 3 min Set clear expectations: this is a hands-on exercise. Encourage participants to ask questions if stuck at any step. Put a thumbs up in shared notes for each step when you’re ready to move on

Step 1: Fork the Repository

1. Go to the example repo on GitHub (https://github.com/the-data-patch/do-watcha-wanna)
2. Click Fork (top right)
3. You now have your own copy under your account

Timing: 2 min Ask who are familiar with GitHub workflows? Explain that forking allows them to experiment without affecting the original repo.

Step 2: Make a Change

• Edit the rutgers.txt file
• Commit your changes with a meaningful message

Timing: 3 min Encourage small, safe changes to build confidence.

Step 3: Publish to Zenodo Sandbox

1. Log in to Zenodo sandbox
2. Activate the repository you forked
3. Create a GitHub release (tag your commit)
4. Zenodo generates a DOI for the release

Timing: 5 min Live demo, walk through it together. Release title is concatenated with github repo for Zenodo title Release notes become Zenodo description

Step 4: Make Additional Changes

• Update code or documentation
• Create a new release on GitHub
• Observe new DOI generated by Zenodo

Timing: 3 min Highlight that each release gets a unique DOI but all point back to the concept DOI. This one they do on their own.

Step 5: Explore Examples

Look at successful uses of this mechanism:

Instrument: Low-Cost IoT Water Sampler

Pipeline: Tourmaline for eDNA analysis

Analysis: Using H3 Grids for Biodiversity Indicators

Documentation: Marine Data Mobilization Workshop

Timing: 3 min Point out how each release has its own DOI, while the concept DOI points to all versions.

Step 6: Reflection

• Could you explain this to a collaborator?

Timing: 5 min Encourage participants to share experiences and ask clarifying questions. You will be asked to suggest and/or participate in mechanisms like this as a professional.