Publishing Code

Using GitHub releases and Zenodo DOIs
to create citable code snapshots

Stephen Formel

The Data Patch

2025-01-29

Why publish code?

• Increase reproducibility and FAIR-ness
• Make life easier for future you
• Enable reuse and extension
• Get credit for software as a research output

Timing: 2 min
Set expectations. This is about concepts first, mechanics second.
Emphasize that this mirrors data publishing practices participants may already know.

The long view

• Science outlives tools and platforms
• Papers persist; links rot
• Without snapshots, methods cannot be verified

Timing: 1 min

GitHub is not an archive

• Excellent for collaboration
• Moving target
• 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?

A code archive is:

• Persistent with PID
• Findable and citable
• Immutable once published
• Backed by long-term infrastructure

Timing: 1 min

Zenodo (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

GitHub + Zenodo model

• GitHub: active development
• Zenodo: frozen snapshots

GitHub is where code lives
Zenodo is where code is cited

Timing: 1 min

Where will you use this?

• Instrument development
  
• Pipeline development
  
• Analysis iteration

Timing: 2 min
Ask students to come up with examples

Versioning and DOIs

• Each GitHub release creates a new Zenodo version
• Each version gets its own DOI
• One concept DOI always points to the latest version

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

Let’s Practice

Pre-work

• Make a GitHub account

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
2. Click Fork (top right)
3. You now have your own copy under your account

Timing: 2 min Explain that forking allows them to experiment without affecting the original repo.

Step 2: Make a Change

• Edit the README
• Commit your changes with a meaningful message
• Push to your fork

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.

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:

• Zenodo record 18087438
• Zenodo record 5708827
• Zenodo record 5708345

Note to Steve - add screenshots of examples and reference at the beginning too. Maybe find examples of instruments, pipelines and analysis. Parallel slide ‘where wil you use this?’

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.