Vahtian

Learn · Methods, in the open

Make your analysis code citable

GitHub is where code lives. A DOI is how someone cites the version you actually used. Here is the route from scripts to a licensed repository, a frozen Zenodo release, and a code-availability statement, with an optional R package at the end.

By Heidi Andersén, MD, PhD. Updated .8 minute read

After this guide you will be able to:

  • Put your analysis scripts in a public repository with a licence, in about 15 minutes.
  • Get a free Zenodo DOI for a frozen release.
  • Write a code-availability statement that answers the main questions.
  • Optionally wrap your R scripts as a package others install with one line.

I put it on GitHub.Which version did the paper use?

your scripts .R / .py public repo + licence + CITATION tagged release v1.0.0, frozen version DOI cite this release

Why a DOI, not just a GitHub link

A GitHub link points at whatever the code looks like today. It can move or change, and a reviewer three years from now may find something different from what you ran. A DOI (digital object identifier) can point to the archived snapshot of a specific release. Zenodo, run by CERN, mints the DOI and keeps that release available. That is the difference between “here is my code, probably” and a version someone can cite.

There is a second, quieter payoff. Every time someone cites your code DOI, that is a citation with your name on it — for the method you actually built, separate from the paper.

A worked example you can inspect. The analysis scripts behind our own QualiVahti Local vault are public under an open licence, with a Zenodo DOI (10.5281/zenodo.21274892) and an installable R package. Everything below is exactly how they were published — you can open the repository and copy the structure.

Step 1 — a public repository with a licence · about 15 minutes

Put your scripts in a folder, add two small files, and push it to GitHub. The two files do the heavy lifting:

Show a copyable CITATION.cff 
cff-version: 1.2.0
message: "If you use these scripts, please cite them as below."
title: "My analysis scripts"
type: software
version: 1.0.0
date-released: 2026-07-09
license: Apache-2.0
authors:
  - family-names: "Surname"
    given-names: "First"
    orcid: "https://orcid.org/0000-0000-0000-0000"
abstract: >-
  One or two sentences on what the scripts do.

Step 2 — connect Zenodo and make a release · about 10 minutes

  1. Sign in to zenodo.org with your GitHub account.
  2. In Zenodo's GitHub settings, find your repository and switch it on. Do this before the next step — Zenodo only archives releases created after the switch is flipped.
  3. On GitHub, create a release: Releases → Draft a new release. Give it a tag such as v1.0.0, a title, and a short note. Publish it.

Within a few minutes Zenodo archives that release and mints a DOI. You actually get two: a version DOI for this exact release, and a concept DOI that always points to the latest version. In a paper, cite the version DOI for the release you actually ran — that is what makes the analysis reproducible. The concept DOI is for pointing at the project in general.

Step 3 — write the availability statement

Now the sentence the reviewer is looking for. Adapt it:

Code availability. The analysis code is openly available under the Apache-2.0 licence at [GitHub URL] and archived at [DOI]. Interview recordings and transcripts are not shared, as audio is directly identifying and participants did not consent to data sharing.

That paragraph answers the three questions a reviewer is likely to ask: is the code available, is the cited version stable, and why is the raw data not attached? A clear data sentence is not a weakness. Explaining why identifying data stays private is part of a complete availability statement.

Optional — make it installable as an R package · about 30 minutes

Scripts in a repo are enough for citation. But if you want other researchers to run your analysis with one line, wrap the R side as a package. The minimum is a folder with a DESCRIPTION file (name, version, author, licence), your functions in R/, and a NAMESPACE listing what is exported. Then R CMD check tells you what is missing.

To let people install it without CRAN's review queue, register the repository with R-universe — a free build service. Once registered, anyone runs:

install.packages("yourpackage",
  repos = "https://youruser.r-universe.dev")
The smallest DESCRIPTION file that works 
Package: yourpackage
Type: Package
Title: What It Does In A Line
Version: 1.0.0
Authors@R: person("First", "Surname",
    email = "you@example.org", role = c("aut", "cre"),
    comment = c(ORCID = "0000-0000-0000-0000"))
Description: A sentence or two, ending with a full stop.
License: Apache License (>= 2)
Encoding: UTF-8

Our own qualitative-analysis package is published this way — a citable DOI for the archive, and install.packages("qualivahti", repos = "https://heidihelena.r-universe.dev") for anyone who wants to run it. The Python side sits on PyPI by the same logic.

What a DOI does not fix

Publishing code is not the same as documenting it. A DOI on an unreadable script is still a step forward, but the value shows when someone can actually follow it. Spend the extra hour on a README that says what each script does and what it expects as input. Check the scripts for anything private — file paths with names, a stray data sample, an API key — before the repository goes public. An archived release is meant to remain part of the scholarly record.

You do not need our tools to do any of this. The steps above work for any analysis code, in any field.

If you work with interviews and want the whole local workflow — transcription, AI-assisted coding under human review, an audit trail, and analysis scripts already published with a DOI — QualiVahti Local packages it, and ships the exact citation guide its buyers put in their methods sections.

See the citable, DOI-ready vault — €49

Related guides

Start upstream with transcribing interviews offline with Whisper. More local-first research guides are on the Learn page.