Sharing academic credit in an open source project

We live in truly wonderful times to develop software. Thanks to the growth of the Open Source movement and emergence of platforms such as GitHub, coding became something more than just an engineering task. Social interactions, bonds between developers, and guiding new contributors are sometimes as important as sheer technical acumen.

A strong and healthy developer community revolving around a software tool or library is very important. It makes the tool more robust (tested in many more environments), sustainable (the progress does not depend on a single person), and feature rich (more developers == more features). Even though there exist some excellent guides on how to build a welcoming and thriving community they miss out on one aspect that is specific to software development performed by academics — academic credit.

For those not familiar with how things run in academia a quick refresher: the main currency of science is papers (manuscripts) and the number of times they are referenced (cited) by other papers. It’s a little bit like the the PageRank algorithm — more cited papers are more important and help academics in their careers. Papers could be describing many things: a new discovery, new algorithm, dataset, and — yes — a piece of software. In fact some of the most cited papers are indeed linked to a piece of software.

Many open source software projects have papers linked to them — such as this Frontiers in Neuroinformatics paper we published about a framework for neuroimaging data processing called Nipype. At the time of writing we invited everyone involved to co author the paper, but the developer community was relatively small and hence the paper has only 7 authors. If you go to Nipype GitHub page you will notice that now the project has over 100 contributors. Once a paper is published it is very hard to change it (and unheard of to modify the list of authors). Thus unfortunately everyone who joined the project after the paper was published is not on the paper. So how can they receive academically meaningful credit for their work? How to reward academics in long running collaborative software projects?

Solution — new “paper” for every release

Ideally one would be able to version the paper — primary citation for your software tool — and add new contributors/authors for every new release. Unfortunately this is not possible with any publisher I know of. However, there is something very similar — enter the wonderful world of Zenodo.

Zenodo is a free repository for research products (papers, data, software etc.) supported by OpenAIRE (a European Union project) and CERN (you know — the birthplace of the Internet). Zenodo allows you to deposit your software and get a Digital Object Identifier (DOI) for it making it citable in the literature the same way as any other paper. What is more Zenodo recently introduced a feature allowing to group DOIs of different versions of the same piece of software. The most fantastic aspect of the system is that it could be fully automated. This is how you do it:

1. In your repository create a .zenodo.json file with all of the authors, their affiliations and ORCIDs. You can find an example here.
2. Add information to your CONTRIBUTING.md file (the one that is linked to each time someone opens a Pull Request) asking new contributors to add their names to .zenodo.json.
3. Login to Zenodo.org with your GitHub account, go to your profile, click GitHub and enable integration for your repository.
4. Create a new release on GitHub — a new DOI will be automatically created on Zenodo.

Finally you should instruct users to cite the Zenodo handle instead or in addition to your paper (this is how we did this in Nipype). This way the new publication will start accruing citation. By setting up this system you will give all of your contributors academic credit for their work and build up a sense of common ownership of the tool you all create together. There is one more bonus side effect: your project will be now backed up in on Zenodo in case GitHub disappears.

Originally published at blog.chrisgorgolewski.org.