Making code available: lab websites vs GitHub vs Zenodo

Our 2007 CEGMA paper was received by the journal Bioinformatics on December 7, 2006. So this means it was about 9 years ago that we had to have the software on a website somewhere with a URL that we could use in a manuscript. This is what ended up in the paper:

Even though we don't want people to use CEGMA anymore, I'm at least happy that the link still works! I thought it would be prudent to make the paper link to a generic top-level page of our website (/Datasets) rather than to a specific page. This is because experience has taught me that websites often get reorganized, and pages can move.

If we were resubmitting the paper today and if we were still linking to our academic website, then I would probably suggest linking to the main website page ( and ensuring that the link to CEGMA (or 'Software') was easy to find. This would avoid any problems with moving/renaming pages.

However, even better would be to use a service like Zenodo to permanently archive the code; this would also give us a DOI for the software too. Posting code to repositories such as GitHub is (possibly) better than using your lab's website, but people can remove GitHub repositories! Zenodo can take a GitHub repository and make it (almost) permanent.

The Zenodo policies page makes it clear that even in the 'exceptional' event that a research object is removed, they still keep the DOI URL working and this page will state what happened to the code:

If the uploaded research object must later be withdrawn, the reason for the withdrawal will be indicated on a tombstone page, which will henceforth be served in its place. Withdrawal is considered an exceptional action, which normally should be requested and fully justified by the original uploader. In any other circumstance reasonable attempts will be made to contact the original uploader to obtain consent. The DOI and the URL of the original object are retained.

There is a great guide on GitHub for how you can make your code citable and archive a repository with Zenodo.

Question: when is a GitHub repository not a GitHub repository?

Answer: when it doesn't contain any useful code.

Update 2015-10-02 08.58: this post was updated to reflect the addition of code the metaPORE repository.

A discussion on twitter today revealed something which I find very disappointing:

A new paper by Greninger et al. (Rapid metagenomic identification of viral pathogens in clinical samples by real-time nanopore sequencing analysis) has been published in the journal Genome Medicine. The Methods contains the following line:

We developed a custom bioinformatics pipeline for real-time pathogen identification and visualization from nanopore sequencing data (MetaPORE) (Fig. 1b), available under license from UCSF at [23].

Reference #23 takes you to the metaPORE GitHub repository. At the time I initially wrote this post — and as the screen grab below shows — it contained zero code. Thankfully this has been changed and a set of Python and shell scripts are now available.

Maybe this was just some sort of error in scheduling the release of the paper and the code. However, journals and authors should understand that if a paper (or a pre-print) appears online and points to a code repository (or any other website), the expectation is that people should be able to visit the site in question and download code.