The findable, accessible, interoperable and reusable (FAIR) principles were published in 2016 aiming to be applicable to all sorts of digital objects but with a particular focus on research data. In recent years, communities working on adaptation and adoption of the FAIR principles for research objects other than data have emerged, e.g. FAIR for training materials or FAIR for research software. There are different aspects around FAIR for research software, for instance how the original principles could be adapted for the software case, how to promote and measure the adoption, how to support the implementation, among others.
Here we report on a discussion session that took place during the Collaborations Workshop 2021, organised by the Software Sustainability Institute from 30 March - 1 April. Software developers and researchers gathered together to discuss different topics around software, including FAIR principles; equality, diversity and inclusion; and software sustainability. In our session, we discussed attitudes, advantages and challenges around the adoption/implementation of the FAIR principles for research software. By research software we mean mostly those pieces of software created to support a research project, e.g. to process and transform data or to support experiments.
Our discussion was led by four questions on (i) the advantages of adopting FAIR for research software, (ii) the current adoption practices of software across organizations, (iii) the attitudes towards adoption, and (iv) the motivations and barriers for adoption. In the following sections, we present the discussion points for each of the posed questions.
Advantages of adopting the FAIR principles for research software
We initially discussed advantages and disadvantages observed by the participants regarding the adoption of the FAIR principles for research software. We summarise our observations in Table 1. Some of the perceived disadvantages could be reduced or even removed by improving information on topics around FAIR. For instance, openness is out of the scope of the FAIR principles but some people mistakenly think that FAIR implies open. Licensing is another topic where confusion commonly arises; some people see adding a license as a barrier to later commercialising the software which is not necessarily true, e.g. Apache, a license commonly used for open projects is also successfully used for commercial projects.
Another common perceived disadvantage is the extra work required to make software FAIR, however, in the long run the benefits will justify the new skills to be learned. In addition to researchers, Research Software Engineers (RSEs) are also in charge of research software. One of the issues with FAIR is that RSEs might perceive them as something exclusively academic, important for those who want academic recognition for their work, e.g. citations, while some RSEs prefer to keep things quietly in their code repositories. However, recruiters increasingly visit code repositories making findability, recognition and citation important for RSEs as well.
Table 1. Advantages and disadvantages to adopting FAIR principles for research software.
Cost effectiveness / sustainability
Lower cost for long-term maintenance
More costly to develop FAIR software.
Perceived to make it harder to commercialise software.
Increases the threshold for researchers because they need to do extra work which will not yet affect their academic career.
Smaller institutions may not have a team of RSEs to make their software FAIR.
Similar metadata across software allows researchers to easily compare and find relevant software.
Makes curation and archiving easier.
Reliability & scientific verifiability
FAIR software tends to be more reliable as it will be more transparent and its output can be verified more easily by the research community.
FAIR software increases the rate of software reuse.
FAIR principles make software usage and contribution easier.
Preparing research-specific software for reuse can require additional refactoring.
FAIR software ensures that RSEs are acknowledged for their work.
RSEs may not want to “stick their head out” as they are not traditional academics.
FAIR software might divert citations from a paper to software.
Absence of incentives to adopt FAIR principles, little recognition for software in the scientific publication process.
Interoperability between software packages, allows users to combine functionality from different packages in a single workflow.
Connecting to other research objects becomes easier via metadata.
Elements to take into account when implementing FAIR for software
RSEs, the developers of the research-specific code, are best placed for making their software FAIR. However these RSEs are often the ones with the least awareness and training in principles like FAIR, Open Research and Software Citation, although they often have rich experience with Open Source principles, platforms (e.g. GitHub) and licenses (e.g. BSD, GPL).
An important aspect for implementing FAIR for Software is therefore to provide sufficient training for RSEs, to help convince the academics leading their projects that it is worthwhile the extra effort of making their software available and citable, with sufficient metadata and ideally archived in a public repository.
One challenge here is how to convey the benefits of FAIR Software to developers, funded projects and the wider research community, especially as RSEs themselves are frequently not following the traditional academic career route, and are not overly concerned with traditional metrics like citations or attributions. RSEs and postgraduate software developers, frequently on short-term contracts or working for a separate organisational unit, may likewise not feel comfortable in challenging their PIs with introducing the additional “burden” of making their software FAIR, when the research projects primarily care about the outputs of that software.
In many cases research groups are isolated and any attempt to make institutional outputs FAIR is initiated by individual groups. Their institutions do not centrally require efforts towards producing FAIR research outputs. However, institutions can play a key role in providing appropriate reward incentives and support networks, e.g. through RSE groups or library training, but also by providing appropriate infrastructure for recording software as research outputs, e.g. as part of the Research Data Platform or through collaborations with public repositories like the HAL platform and Software Heritage.
Support networks for RSEs, such as the Society of Research Software Engineers and the Software Sustainability Institute can play an important part as cross-institutional exchanges of practical knowledge for making software FAIR, through events such as the Collaborations Workshop and informal support channels between peers, such as Slack chats. Although these only reach RSEs, best practice guides and motivational literature can be used as motivation for convincing academic PIs of the FAIR benefits.