Implementing FAIR for research software: attitudes, advantages and challenges (part two)
Implementing FAIR for research software: attitudes, advantages and challenges (part two)
The FAIR principles
By Leyla Jael Castro, Diego Alonso Álvarez, Stian Soiland-Reyes, Markus Löning, Sam Harrison, Faruk Diblen, Abhishek Dasgupta, Morane Gruenpeter and Paula Andrea Martinez.
This is the second part of this blog post, see the first part here.
This blog post is part of our Collaborations Workshop 2021 speed blog series. Also available at https://doi.org/10.6084/m9.figshare.14453031.
Support required to fully implement FAIR for software
Although there is no clarity on how to implement the FAIR principles for the case of research software, there are already some efforts in that regard. However, the supporting tools that we have at present are not enough for a full implementation. In this section we summarised current practices and future needed support.
Current practices
Currently, researchers and RSEs rely on existing components and infrastructures, which can be helpful when they are known and used. These include archives (e.g., Software Heritage, Zenodo, institutional repositories), publishers (e.g IPOL, eLife, JOSS), catalogs/registries (e.g, swMath, ASCL, OpenAire, ScanR, CRAN, PyPi). Note that there are existing components and solutions which are good practices to improve the FAIRness of software, such as including metadata files in the source code (e.g CodeMeta, CFF), software development best practices (e.g. versioned releases, git), and adding a registered license (e.g SPDX, REUSE project). Information about these existing solutions and infrastructures can be shared through word-of-mouth (e.g. CW21), training (internal and through RSE networks) and Google search. Having infrastructures that communicate and support software’s dissemination, will provide better possibilities for researchers and institutions to curate and share software.
Future elements
There is still a long way to go to get full support to implement FAIR principles in general and for software in particular. As FAIR heavily relies on metadata describing the research objects at hand, there is a need for (semi)automatic processes extracting metadata from the software itself, e.g. from the repository and later exporting such metadata to specialised registries or repositories for this sort of metadata. Common standards regarding what should be included in the metadata are also needed, including some criteria on what is minimum, recommended and optional. For instance, the lack of license means reusability is not possible while copyright authorship might be more important when software is created by multiple research groups or a large community. In addition, the implementation of FAIR should be supported by training so people understand not only how to do it but also the importance of doing it. Finally, it is necessary that all involved stakeholders recognise the investment required to FAIRify software; no research object will magically become FAIR, someone has to do it and it requires time, support and resources.
Motivations and barriers
Some of the motivations and barriers to make FAIR for research software a reality:
Motivations
- Findability means developers get more credit for the software they write.
- Interoperable and Reusable means that their software will be used by their research community which will result in higher impact (e.g. through citations).
- Increases trust and reputation of the research group due to transparent, well-tested code.
- Necessity: some journals/reviewers will ask for software deposition/archiving and a Permanent Identifier (PID) for it as part of the publication process for the research results. This isn’t entirely sufficient for FAIR but is a step in the right direction, especially with regards to Findability.
Barriers
- Worry about additional support requests; this is more of an issue if publishing to code forges such as GitHub. Having a well-documented README file which explains the policy on accepting contributions, bug requests and support requests would be useful.
- In smaller institutions or small research groups with no access to RSEs, there may not be enough people with time and expertise to make a software FAIR.
- Perceived loss of reputation when bugs are found [see Imperial College COVID-19 modelling]
- Intellectual property challenges. This can happen if someone inadvertently reused code from a source which is not compatible with the license, such as using GPL code in a BSD licensed project.
- Making a software FAIR may limit commercialisation potential. This is more of a misconception than an actual disadvantage. Similar to profitable open source businesses, FAIR can be commercialised, however, it may not be as easy to do so when compared to a traditional closed-source proprietary software business model.
- Concerns about how FAIR software is updated after it has been versioned/released. Needs knowledge to implement best practices, e.g. Zenodo DOIs for the latest tag of the software.
- Lack of knowledge. Some topics are particularly complex, e.g. licensing and choosing appropriate metadata. Useful tooling or websites such as choosealicense.com can be helpful.
Final words
Implementing FAIR for software is an ongoing journey with a long way ahead. There are concerns regarding the new skills to be learned, the effort it requires and the extra work it implies. In addition, it is not clear who should be responsible for implementing and making software FAIR. Is it the researcher producing software to support their research? Should it be left in RSEs hands? Do we need FAIR stewardships? Should it be a shared responsibility where everybody contributes bit by bit?
Although it might look like we have more questions than answers, the important thing to highlight is that the community recognises the value of FAIR for research software and is moving together to make it a reality. This means that more clarity and more support will become available in the future so the benefits overcome the disadvantages and the motivation is greater than the barriers. We look forward to a FAIRer world.