Resources for making your research software FAIR
By Selina Aragon, SSI Communications Lead, and Steve Crouch, SSI Software Lead.
This blog post is part of the Research Software Camp: FAIR Software.
The FAIR Data principles originated from data management and were created to improve the infrastructure supporting the re-use of scholarly data. The FAIR acronym stands for Findable, Accessible, Interoperable and Reproducible. The recognition of research software as a digital object led the FAIR for Research Software (FAIR4RS) Working Group to adapt the FAIR Guiding Principles and create the FAIR Principles for Research Software.
In this post, we have collated resources for making software FAIR. Note that we haven’t included any FAIR data resources as the focus is specifically on research software.
General resources
As a quick overview, the Five Recommendations for FAIR software—a collaboration between the Netherlands e-Science Centre and DANS—provide a good starting point to understand and apply the FAIR principles to research software.
Read also about the advantages and the existing motivations and barriers around adopting the FAIR principles for research software.
Open source software
There are a few points to consider when choosing how to tackle a problem using software. Choosing the right open source software for your project covers topics from what questions you should ask yourself before embarking on your software journey to whether the software you’re planning to use potentially has a community around it and a future.
Readable code
When researchers write code, they often overlook its readability. In the SSI guide Writing readable source code, we go over why it’s important to write readable code, including enabling collaboration and reusability, and how to future-proof it.
If you’re not sure whether you’ve written readable code, you might want to Treat your research code with a code review. Start by reading our Top tips for better code review. Code review doesn't have to be onerous: it's been found that the first hour of the first code review goes a long way with your research software (see Best Kept Secrets of Code Review).
Nowadays, code management tools, such as GitHub, GitLab, and others, provide features to integrate code reviews with the overall development and deployment workflow. Learn how to use Github’s mechanism of 'pull requests' to start a code review with your peers in this Code For Thought episode.
Licensing
After you've written some software as part of your research, you want to encourage collaboration so that others can use and further develop it. It's a good idea to discuss and agree upon a suitable software licence for your software early on since how you license your software may influence how you provide it to others, as well as how you make use of other software that is licensed.
Once your code is ready for release, you’re ready to choose a license, and a few resources might come in handy then:
- Choosing an open source license
- Software Licenses in Plain English
- How to add a license to a GitHub repository
Enabling citation
Making your software citable through Citation File Formats (Citation.ff) or CodeMeta will help uniquely identify your software so that it can be cited correctly by others:
Persistent identifiers
When archiving your software, it’s important to use services that store their own copy of a snapshot of your software and create a persistent identifier (e.g. a Digital Object Identifier (DOI)) which points to a specific version of the software. For further information, the SSI’s Software Deposit Guides offer detailed explanations from what to deposit to why and where.
To get you started with persistent identifiers, this guide explains how to make your software citable with Zenodo and Github. However, there are other platforms, such as the Software Heritage Archive, which offer similar services.
We hope these resources provide a useful place to start. However, these are not comprehensive, so if you’ve come across other useful resources, get in touch with us to include them.