Getting a DOI for your code

Academics have published work for centuries. Over the past couple of decades the type of work academics do has been changing. Our output is no longer constrained to peer reviewed articles, but includes reports, data, code, infographics, book chapters and many more. Some of these outputs are easy to share, but we also need to be able to demonstrate where they’ve come from: to help science be reproducible and as a measure of our own work.

This blog article is an explanation of sharing research code. It focuses on using the version control website Github and academic repository Zenodo. Github uses Git to help manage your code development and collaborate with others, you can learn more about using it in this article from Jenny Bryan. Zenodo is a repository hosted at Cern, it is a way of getting a digital object identifier (DOI) for your work. A DOI is a persistent handle standardised by the ISO, in short it is a link which will always end up in the right place.

Once you have code in Github (help yourself and attend a software/data carpentry course), then you are ready to link Zenodo to Github.

  1. Sign into Zenodo, you can use your Github credentials.
  2. In your account settings you can link Github to Zenodo.
  3. Choose the Github repository you want to link and follow the instructions at the top of the Zenodo page about Github releases.
  4. Fill in your metadata on Zenodo – remember to cite the software of others you’ve used!

You can add a json file to your Github repo which Zenodo will use to populate metadata, if you don’t do this Zenodo will overwrite your metadata each time your make a new release. Thankfully you have made a template of this json file.

  1. Back in your Zenodo Github settings click on the enabled repository.
  2. Click on a release (green text)
  3. Copy json metadata into a .zenodo.json file in your Github repo, this will be used to populate metadata on your next release.

You can view the output of this process here, which includes the metadata json: Michael Spencer. (2019, September 3). Hill farming study – analysis code (Version v1.02). Zenodo. The eagle-eyed of you may notice that the json metadata on Github has less information than that generated by Zenodo. I’m happy for Zenodo to handle linked DOIs and information like that, so I removed it from the json file.

The Software Sustainability Institute have some great guides on using research software.


  1. Have you worked out how to get Zenodo to reserve a DOI for a GitHub repo? Doing that would allow the repo release snapshot to contain it’s own DOI (say, in the README). Zenodo allows you to reserve a DOI for other research outputs, like papers, but I can’t see how to do it foir a GitHub repo.

    1. I know what you mean. Adding the doi badge after the release seems strange. Same with the JSON. I don’t know a work around. Zenodo help are responsive, so you could ask…

      1. In case you are interested – can dockerise git repositories with Jupyter or R notebooks and spin them up in the cloud for free so readers can run the notebooks without installing any software. It can even do this for Figshare and Zenodo snapshots of repositories. I have added this to the Zenod snapshot of the GitHub repo for the R notebook that generates a conference presentation for me:

  2. I sent a query to Zenodo and here is there reply:

    > Thanks for your message. Unfortunately, it’s not possible to reserve a DOI for a GitHub
    > repository using the automatic archiving. It’s possible to grab the DOI badge from the
    > Zenodo GitHub pages, which will give you a badge that auto-updates with the new DOI.
    > It’s a problem that we’re aware of, but we have not yet found a nice user-friendly way to deal
    > with. We’ve done some research on citations to research software in Zenodo, and found that
    > many of the citation recommendations that software developers put on there pages are in a
    > pretty bad shape (from a citation tracking point of view), so automatically getting in the
    > correct DOI (in a citation recommendation) in the source code is something that we do care
    > about.

    FWIW I suggested a mechanism that parallels the way DOIs are reserved for all other uploads. Fingers crossed, we might see a means to reserve a DOI for a GitHub repository before *too* long. Given the sentiment expressed in the response, the fact that they undoubtedly have competing priorities, and the fact that they already have code for reserving DOIs for other outputs, I would hope they could implement a mechanism in under a year.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s