Overview: FAIR4RS principles & best practices for FOSS development

Below you can find an overview of the FAIR4RS principles alongside best practices in research software development. We present four tables corresponding to each of the FAIR principles -- Findable, Accessible, Interoperable, and Reusable. In these tables, the columns list the relevant FAIR4RS sub-principles, and the rows list best practices for free and open-source software (FOSS) development. A checkmark in the intersecting cells indicates alignment between a best practice and a FAIR4RS principle. While ideally, both the FAIR4RS principles and FOSS best practices should be integrated into research software development, the extent of their application may vary based on the software's complexity and other factors.

FAIR4RS principles have predefined identifiers prefixed with F, A, I, and R, respectively, followed by a number. There are no predefined identifiers for the best practices, so we have used a similar prefixing scheme to FAIR4RS principles, with prefixes BF, BA, BI, and BR, respectively, followed by a number.

The FAIR4RS principles have been proposed by the FAIR4RS working group (Chue Hong et al. 2022) and described by Barker et al., 2022. The best practices for FOSS development have been assembled from various sources, including Good Practices, Research Software Support, eScience center; Good practices in research software development, eScience center; Lesson Development for Open Source Software Best Practices Adoption; Starting an Open Source Project, Open Source Guide; and Overview of recommended FAIR practices for research data and software by Niehues et al..

---

Findable

	[F1] Software is assigned a globally unique and persistent identifier.	[F1.1] Components of the software representing levels of granularity are assigned distinct identifiers.	[F1.2] Different versions of the software are assigned distinct identifiers.	[F2] Software is described with rich metadata.	[F3] Metadata clearly and explicitly include the identifier of the software they describe.	[F4] Metadata are FAIR, searchable and indexable.
[BF1] Employ software version control systems like Git and platforms like GitHub for collaborative code development.			✅
[BF2] Make your software easy to discover by providing metadata through popular community registries.				✅

Accessible

	[A1] Software is retrievable by its identifier using a standardised communications protocol.	[A1.1] The protocol is open, free, and universally implementable.	[A1.2] The protocol allows for an authentication and authorization procedure, where necessary.	[A2] Metadata are accessible, even when the software is no longer available.
[BA1] Make the source code publicly accessible from day one to encourage transparency and collaboration.	✅	✅		✅

Interoperable

	[I1] Software reads, writes and exchanges data in a way that meets domain-relevant community standards.	[I2] Software includes qualified references to other objects.
[BI1] Use existing libraries and frameworks to avoid reinventing the wheel; any reinvention should be justified and documented.		✅
[BI2] Ensure proper distribution by isolating code or clearly specifying dependencies.		✅
[BI3] Comply with community standards, maintain consistent code conventions, and use clear names for functions, methods, and variables.	✅

Reusable

	[R1] Software is described with a plurality of accurate and relevant attributes.	[R1.1] Software is given a clear and accessible license.	[R1.2] Software is associated with detailed provenance.	[R2] Software includes qualified references to other software.	[R3] Software meets domain-relevant community standards.
[BR1] Develop modular code to enhance reusability and maintainability.	✅				✅
[BR2] Provide comprehensive documentation for your research software, including a README file, user guides, developer guides, deployment instructions, technical documentation, tutorials, and API references.	✅		✅	✅
[BR3] Implement (automated) testing (smoke tests, unit tests, integration tests, system tests, and regression tests) and utilize continuous integration tools (e.g., GitHub Actions) to automate code checks with each repository change.
[BR4] Adopt an appropriate license and comply with the licenses of third-party dependencies.		✅		✅
[BR5] Define clear and transparent contribution, governance, and communication processes, including a code of conduct.			✅		✅
[BR6] Establish support mechanisms such as issue tracking systems, governance structures, mailing lists, and regular release schedules.			✅		✅