We are currently finishing the implementation of a scientific software library. It's the first project of this type for me and I'm curious, how to make the software citable in a similar way to Molpro or R?

I was thinking about writing a short paper introducing the library, which could be subsequently cited. But I'm not sure, how to deal with the different versions? I don't think it's possible to write just some "changelog" paper once a year to summarize new released version.

  • 5
    I don't understand the question. Your software is already citable, by listing your name, the name of the library, and the URL.
    – JeffE
    Mar 29, 2019 at 7:18
  • @JeffE That's the truth, but it's not going to be indexed anywhere, not even Google Scholar, if I'll have just the name and URL...
    – Eenoku
    Mar 29, 2019 at 8:16
  • 2
    @Eenoku Are you sure that Google Scholar won't index? If your software is consistently cited---e.g., Eenoku (2019) Library, http://url.com---then surely Google will index that.
    – user2768
    Mar 29, 2019 at 9:05
  • 1
    You may be wrong. Google Scholar reports that a subset of my lecture notes, which is only published as PDFs on my web page, has 5 citations.
    – JeffE
    Mar 29, 2019 at 11:11

4 Answers 4


There are about as many approaches to citing software (and making software citable) as there are software packages.

One way is to create a DOI for your software via Zenodo. This DOI can then be updated for each version of the software. Another way is to write a paper about the design and features of your software and see that it gets published somewhere. There are numerous journals for this -- for example, SoftwareX or, for mathematical software, the ACM Transactions on Mathematical Software. (Disclaimer: I'm a co-Editor-in-Chief of the latter.)

There are numerous other projects that have guidelines of how to best do this. You may want to take a look at the Force11 project, for example, as well as the outcomes of the WSSSPE series of workshops.

  • 1
    You will probably want to take a look here: toms.acm.org/authors.cfm Mar 28, 2019 at 15:42
  • 1
    Another important consideration is that the approach to use will also be influenced by the field the software is intended for. Conventions and details on how authors and journals like to handle software citations in field with heavy software usage (like statistics) are going to be different than a primarily non-computational field (like biochemistry).
    – R.M.
    Mar 28, 2019 at 17:21
  • 4
    Neither a DOI nor an explanatory research paper is actually necessary for something to be citable.
    – JeffE
    Mar 29, 2019 at 7:20
  • 1
    @JeffE: That might be true in a literal sense, but if you want to encourage people to actually cite you, it's useful to have a thing that follows the scheme people are used to. If you need to explain to people how to cite your software, you've already lost 3/4 of those who would otherwise be willing to do so. Mar 30, 2019 at 1:08
  • 1
    @WolfgangBangerth It's not only true in a literal sense; it's true in a practical sense; the pattern "Author, title, year, URL" is pretty versatile. (I have lecture notes, blog posts, and even StackExchange questions with multiple citations.) But fair point about meeting community expectations. If your audience believes a DOI is necessary for citation, then you need a DOI to be cited; whether your audience's belief is correct is irrelevant.
    – JeffE
    Mar 30, 2019 at 8:38

Write a manual and release it as a technical report.

how to deal with the different versions?

Put the version number in the manual's title and have a different version of the manual for every release. (Alternatively, revise the manual every major release or ...)

I don't think it's possible to write just some "changelog"

You could have a CHANGELOG in the manual, which summarises what's new in the current version. Alternatively, a CHANGELOG could be distributed with the software.

  • Ok, I suppose, that this it the case for Molpro software... But where do you officially publish a technical report? Otherwise yes, I know, that you can have a CHANGELOG in your repository, but that's not the place to be cited from :-)
    – Eenoku
    Mar 28, 2019 at 14:37
  • Just publish the manual alongside the software. You could publish on arXiv, but that's not strictly necessary and adds an additional burden. Regarding the CHANGELOG, I'm not sure whether it needs to be cited, perhaps it suffices to just have different versions of the manual, one for each release.
    – user2768
    Mar 28, 2019 at 15:21

In addition to the above answers, you can publish a short article about the software at the Journal of open Source Software (JOSS). How this journal differs from other journals is described in its announcement post.

Your submitted article and the associated software are thoroughly peer reviewed. If the article is accepted, it will be assigned a volume number, official DOI, etc. In effect, you have a "real" article that can be cited just like a "regular" journal article. This is separate from obtaining a DOI just for your software through services such as Zenodo and figshare, which are mainly intended for archival storage of software and datasets.

  • Having published in JOSS, their review process is very interesting (based almost solely around the software itself, done publicly on github, meant to improve the software and ensure its ready for production with adequate documentation) and leads to very quick turnaround times depending on how quickly you address reviewer concerns. Submission to publication took 10 days for me. Their requirements for the manuscript itself are minimal. Mar 29, 2019 at 13:42
  • Having published in JOSS myself, I'd like to upvote this, but I note that OP didn't actually mention that his/her software was open-source. OP? Sep 4, 2020 at 16:05
  • BTW, as part of the submission and review process, JOSS will ask you to obtain a Zenodo DOI for (one particular release of) the software, so you'll end up with two DOIs, one for the software and one for the paper describing it. Sep 4, 2020 at 16:06

Concerning the DOI / citable discussion, see DOI != citable

And if your using Zenodo to create a DOI, as @Wolfgang Bangerth mentioned, see Making Your Code Citable. Basically here you have to decide how you will make your library publicly available. There are different ways to do it but the links describes how to connect Zenodo with GitHub. This may also depend on whether you want to allow citing different versions of your library or just "link to releases" on you institute's webpage.

Here you will find more input for the discussion How to cite and describe software. They're showing recommendations from software providers, which is as simple as creating your own BibTeX entry with an url. However, the next section shows different positions of "Software is not a citable output". Keep that in mind when providing a special way to cite your library.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .