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 part one of two. See part two 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.

Introduction

The findable, accessible, interoperable and reusable (FAIR) principles [1] 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 [2] or FAIR for research software [3]. 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. 

This session was mainly proposed by the FAIR for Research Software (FAIR4RS) Working Group (WG), jointly convened by Research Software Alliance (ReSA), FORCE11 and the Research Data Alliance (RDA), aiming to create community-endorsed FAIR principles for research software by mid-2021. FAIR4RS WG is recognised in the EOSC FAIR Working Group’s Six Recommendations for Implementation of FAIR Practice (2020) as the primary community forum for this work.

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.

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. 

This is part one of two, see part two here.

References

1. Wilkinson MD, Dumontier M, Aalbersberg IjJ, Appleton G, Axton M, Baak A, et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data. 2016;3: 1–9. doi:10.1038/sdata.2016.18

2. Garcia L, Batut B, Burke ML, Kuzak M, Psomopoulos F, Arcila R, et al. Ten simple rules for making training materials FAIR. PLOS Comput Biol. 2020;16: e1007854. doi:10.1371/journal.pcbi.1007854

3. Lamprecht A-L, Garcia L, Kuzak M, Martinez C, Arcila R, Martin Del Pico E, et al. Towards FAIR principles for research software. Data Sci. 2020;3: 37–59. doi:10.3233/DS-19002