Software citation

Questions

• Is putting software on GitHub/GitLab/… publishing?

• Where to publish software?

• How can software be cited?

• How can I make my software citeable?

Is putting software on GitHub/GitLab/… publishing?

FAIR principles. (c) Scriberia for The Turing Way, CC-BY.

Is it enough to make the code public for the code to remain findable and accessible?

• No. Because nothing prevents me from deleting my GitHub repository or rewriting the Git history and we have no guarantee that GitHub will still be around in 10 years.

• Make your code citable and persistent: Get a persistent identifier (PID) such as DOI in addition to sharing the code publicly, by using services like Zenodo or similar services.

How to make your software citable

Discussion (Citation-1): Explain how you currently cite software

• Do you cite software that you use? How?

• If I wanted to cite your code/scripts, what would I need to do?

Checklist for making a release of your software citable:

• Assigned an appropriate license

• Described the software using an appropriate metadata format

• Clear version number

• Authors credited

• Procured a persistent identifier

• Added a recommended citation to the software documentation

This checklist is adapted from: N. P. Chue Hong, A. Allen, A. Gonzalez-Beltran, et al., Software Citation Checklist for Developers (Version 0.9.0). Zenodo. 2019b. (DOI)

Our practical recommendations:

• Add a file called CITATION.cff (example).

• Get a digital object identifier (DOI) for your code on Zenodo (example).

• Step-by-step recipe for how to make your GitHub project citable using Zenodo.

• Make it as easy as possible: clearly say what you want cited.

This is an example of a simple CITATION.cff file:

cff-version: 1.2.0
message: "If you use this software, please cite it as below."
authors:
  - family-names: Doe
    given-names: Jane
    orcid: https://orcid.org/1234-5678-9101-1121
title: "My Research Software"
version: 2.0.4
doi: 10.5281/zenodo.1234
date-released: 2021-08-11

More about CITATION.cff files:

• GitHub now supports CITATION.cff files

• Web form to create, edit, and validate CITATION.cff files

• Video: “How to create a CITATION.cff using cffinit”

Papers with focus on scientific software

Where can I publish papers which are primarily focused on my scientific software? Great list/summary is provided in this blog post: “In which journals should I publish my software?” (Neil P. Chue Hong)

How to cite software

Great resources

• A. M. Smith, D. S. Katz, K. E. Niemeyer, and FORCE11 Software Citation Working Group, “Software citation principles,” PeerJ Comput. Sci., vol. 2, no. e86, 2016 (DOI)

• D. S. Katz, N. P. Chue Hong, T. Clark, et al., Recognizing the value of software: a software citation guide [version 2; peer review: 2 approved]. F1000Research 2021, 9:1257 (DOI)

• N. P. Chue Hong, A. Allen, A. Gonzalez-Beltran, et al., Software Citation Checklist for Authors (Version 0.9.0). Zenodo. 2019a. (DOI)

• N. P. Chue Hong, A. Allen, A. Gonzalez-Beltran, et al., Software Citation Checklist for Developers (Version 0.9.0). Zenodo. 2019b. (DOI)

Recommended format for software citation is to ensure the following information is provided as part of the reference (from Katz, Chue Hong, Clark, 2021 which also contains software citation examples):

• Creator

• Title

• Publication venue

• Date

• Identifier

• Version

• Type

FAIR for Research Software (FAIR4RS)

The FAIR4RS Principles adapt the original FAIR data principles to improve the Findability, Accessibility, Interoperability, and Reusability of research software. They provide guidelines to make research software more open, discoverable, citable, and reusable, which supports reproducibility and open science. The summary of the FAIR4RS below is a compressed version of the principles listed in Barker, Michelle, et al. “Introducing the FAIR Principles for research software.” Scientific Data 9.1 (2022): 622.

• Findable: Software should have a globally unique and persistent identifier
  (e.g. clear versioning of releases, DOI from Zenodo when depositing a software release, software metadata in citation file).

• Accessible: Software and metadata should be retrievable using open protocols
  (e.g. downloading from GitHub or Zenodo).

• Interoperable: Software should use open formats and standards to work with other tools
  (e.g. input/output files in CSV, dependencies listed in requirements.txt or environment.yml, configuration files in yaml).

• Reusable: Software should have clear licensing, documentation, and provenance
  (e.g. a standard license and a README with usage instructions, authors listed with ORCIDs).

There are great resources to self-evaluate the FAIRness of your research software:

• FAIR Software Checklist which provides a questionnaire and even a badge of how FAIR the software is

• FAIR Software NL highlights with nice visuals the five most important elemnts of FAIR4RS (1. Public accessible repository with version control; 2. License; 3. Software registry; 4. Software citation file; 5. Software quality checklist)