# CODE beyond FAIR: a roadmap for reusable research software

Roberto Di Cosmo, Sabrina Granger, Konrad Hinsen, Nicolas Jullien, Daniel Le Berre, Violaine Louvet, Camille Maumet, Clémentine Maurice, Raphaël Monat, Nicolas P. Rougier

<figure><img src="image_1.png" /></figure>

## To cite this version:

Roberto Di Cosmo, Sabrina Granger, Konrad Hinsen, Nicolas Jullien, Daniel Le Berre, et al., CODE beyond FAIR: a roadmap for reusable research software. 2025. hal-04930405v2

HAL Id: hal-04930405

https://inria.hal.science/hal-04930405v2

Preprint submitted on 19 Dec 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# CODE beyond FAIR:
a roadmap for reusable research software

Roberto Di Cosmo<sup>1,2</sup>, Sabrina Granger<sup>6</sup>, Konrad Hinsen<sup>3,4</sup>, Nicolas Jullien<sup>5</sup>,
Daniel Le Berre<sup>7</sup>, Violaine Louvet<sup>8</sup>, Camille Maumet<sup>9</sup>,
Clémentine Maurice<sup>10</sup>, Raphaël Monat<sup>10</sup> & Nicolas P. Rougier<sup>11</sup>

<sup>1</sup>Inria Paris, Paris, France

<sup>2</sup>Université Paris Cité, Paris, France

<sup>3</sup>Centre de Biophysique Moléculaire (CNRS), Orléans, France

<sup>4</sup>Synchrotron SOLEIL, Saint Aubin, France

<sup>5</sup>IMT Atlantique, Brest, France

<sup>6</sup>Inria Lyon, Lyon, France

<sup>7</sup>CRIL, Université d'Artois, Lens, France

<sup>8</sup>Laboratoire Jean Kuntzmann, Grenoble, France

<sup>9</sup>Inria, Univ Rennes, CNRS, Inserm, Rennes, France

<sup>10</sup>Univ. Lille, CNRS, Inria, UMR 9189 CRISTAL, Lille, France

<sup>11</sup>Centre Inria de l'université de Bordeaux, Bordeaux, France

Corresponding Author: raphael.monat@inria.fr

## Abstract

FAIR principles are a set of guidelines aiming at simplifying the distribution of scientific *data* to enhance reuse and reproducibility. This article focuses on *research software*, which significantly differs from *data* in its living nature, and its relationship with free and open-source software. We provide a tiered roadmap to improve the state of research software, which takes into account the full range of stakeholders in the research software ecosystem: all scientific staff – regardless of prior software engineering training – but also institutions, funders, libraries and publishers.

## Introduction

**Open research software as a pillar of research.** Research software has now become essential in all areas of scientific research, both as a research tool, as a research product, and as a research object. In the biology literature, Howison et al. [1] established in 2014 that more than a third of research articles cited software. In the largest case study we are aware of, Bassinet et al. [2] automatically processed over 908,000 research articles, and found that the percentage of articles mentioning the use of software rose from 33% in 2013 to 48% in 2021. A follow-up analysis showed that only 10% of research software developed in France uses proprietary licenses [3]. Research software has emerged as a scientific output of equal importance to publications and data in the open science perspective [4].

**Research software diversity.** Research software plays both a central and critical role in almost every aspect of modern science. Its usage varies heavily [5]: it can be used to process data, perform analyses, model complex phenomena, drive various apparatus, design surveys, setup
experiments, write documents, and it can itself be a topic of research. This list has dramatically
expanded during the last few decades, to the point that it would be now extremely difficult or
impossible to conduct research without proper software. These pieces of software can take many
different forms, ranging from a short script to a binary executable created from millions of lines
of source code. If we were to scrutinize more closely all this software, we would discover an ever
greater variety. According to the historical encyclopaedia of programming languages, there exist
approximately 9,000 programming languages [6]. Most of them are hardly used outside specific
niches, whereas a few languages are dominant. To name just a few, we mention C/C++, Fortran,
Matlab, Python, Julia and R that seem to dominate the contemporary scientific landscape. If we
now consider the cross product of language, form, usage and epistemic diversity, we get a small
glimpse of the many forms of scientific software and their immense diversity.

**Research software: a living nature.** This diversity is comparable to some extent to research diversity. However, unlike many other scientific objects (research papers & data), software packages can be complex living entities that are continuously evolving under the direct action of core developers and various contributors [7]. This means that there does not exist something like a single final state that could be considered the *version of record* to be archived once and for all for later reuse. It is actually not rare to have many versions of the same software (e.g. stable, unstable, latest, deprecated, etc.) that co-exist for some specific reasons. Software evolves and continues to do so as long as there is one person willing to contribute some code, tests, documentation, bug reports or even simple ideas. This mutable nature makes it a quite singular object in the research landscape, requiring a *record of versions* rather than the *version of record* which is central for journal articles. Furthermore, software cannot be easily separated from its biotope, which corresponds to the operating systems it runs on, taking advantage of the huge stack of software libraries that possess their very own lives. No environment is like another, such that the smallest change can have dramatic effects on the re-usability, or worse, on the correctness of a piece of software [8]. This makes preserving software while maintaining its functionalities quite a tricky operation.

**A porous frontier.** Software development is less than a century old, but it has already undergone a series of dramatic changes. One of them is the explosive growth of *open source*, which has taken by storm the software industry that was traditionally based on *closed source*. Open source means that the source code of a piece of software is made freely available for possible modification and redistribution. This is not the case of closed source software, which is generally distributed as non-modifiable binary executables. The actual term "open source" has been popularized by Eric S. Raymond and Bruce Perrens at the end of the 1990s [9], even though the free software movement founded by Richard Stallman is more than a decade older [10]. The Free/Libre Open-Source Software (FLOSS) community had to develop from the start good practices on how to find, access, evolve and re-use software, and has faced for decades issues like governance, recognition and sustainability [11]. FLOSS has a global scope, with academia having been only a small part of it since the beginning.

**Open Science to the rescue, but.** In 2016, Wilkinson *et al*. [12] published the article "The FAIR Guiding Principles for scientific data management and stewardship" that encouraged academia, industry, funding agencies, and scholarly publishers to endorse a set of principles to promote the reuse of scholarly data. These FAIR principles (for Findability, Accessibility, Interoperability, and Reusability) have since then become highly popular in academia. A majority of stakeholders have adopted these principles at various levels. The FAIR principles were clearly designed for research
data, where the term *data* was intended to denote *inputs or outputs of a processing*, that may or
may not be automated depending on the scientific domains. As a consequence, FAIR principles
have a strong focus on metadata. In principle, anything can be seen as data for a particular kind
of processing: articles are data for Text and Data Mining, DNA strands are data for sequencing,
software source code are data for vulnerability scanning tools, personal entertainment habits are
data for recommendation algorithms. But if we look closer, it is easy to see that many of these
objects are not *just data*, and most of them are *mainly not data*, in the sense that their intended
use is not to serve as input for a processing pipeline. Looking at these objects as *just data* is
therefore unsatisfactory, as it misses the key issues at stake. Software and source code are a clear
example of this phenomenon, leading to several efforts to get the focus back on software as *not
just data*. Following several years of work and discussion [13, 14], Barker *et al.* [15] introduced
FAIR principles for research software (FAIR4RS). More recently, the Research Data Alliance (RDA)
published a similar set of principles [16] advocating for the improvement of sharing and reuse of
research software, recently extended by Sonabend *et al.* [17]. All these efforts are laudable and
will definitely help to make software a first class citizen in research. However, we believe that
additional efforts can build upon the experience of FLOSS, taking into account the core problems
of software complexity, but also the specificities of organization and purpose in scientific research.
For example, the idea that “software reads, writes and exchanges data in a way that meets
domain-relevant community standards” [15] cannot be enforced when your work depends on
closed-source software whose data formats cannot be easily changed. Actually, in some dramatic
cases, this works the other way around: the “domain-relevant community standard” for human
gene nomenclature underwent renaming of some core concepts to avoid issues with spreadsheet
applications [18]. Similarly, the website fair-software.eu recommends registering code on a
software registry in order to make it findable. Findability is an important problem, but we believe
that equally important issues need to be addressed as well, namely being able to execute research
software and collaborate on research software development.

**A tentative roadmap.** To this end, we propose a comprehensive roadmap that takes into account all stakeholders in the research software ecosystem. While authors and contributors of research software remain pivotal, it is imperative to recognize the significant roles played by funders, research institutions, publishers, libraries, and policymakers: they have the means to make these new practices easier to apply and normative. Building on the guidelines of the Journal of Open Source Software, this roadmap is progressive, enabling its gradual adoption. This tiered approach is adopted for several reasons:

1. An overly stringent prescription can deter from engagement. The first tiers have the role of moving forward while not discouraging participants who might feel overwhelmed by seemingly unreachable goals.

2. The approach acknowledges the diverse backgrounds of scientist-developers, many of whom may not have formal training in software engineering but are deeply committed to scientific software development [19].

3. It is difficult to impose stringent rules without appropriate recognition of the effort that they require: in the current landscape, with software development still underrated, this can be counterproductive.

4. The level of maturity with software practices in research vary significantly across disciplines
125
126

and from country to country: a gradual roadmap seems the best way to bring everybody up to speed over time.

127
128
129
130
131
132
133

We detail the proposed roadmap that can be summarized as Open, Document, Execute, Collaborate, each element representing a key pillar for maximizing the value of research software in the realm of open science (see Figure 1). Even though we do not necessarily aim to promote a specific acronym that may obscure the actual philosophy, it is to be noticed that CODE summarizes the key points of the roadmap quite well. This roadmap is then extended to propose a call for action from the main stakeholders, i.e., institutions, funders, libraries and publishers (see Figure 2). A summarized version of this roadmap is also available as a commentary [20].

134

# Results

135

## The CODE gradual roadmap for scholars who develop software

136
137

Figure 1 summarizes the CODE gradual roadmap, which is split into four categories, each containing four recommendations. We now expand on those recommendations.

138

## Open

139

For the sake of reproducibility and progress in science, software will greatly benefit from being opened up to the research community, which may need to study and verify it, and mat wish to modify and reuse it. There are two very different sides to opening research code: one is the technical aspect of making the software accessible to the research community, ensuring this access will stand the test of time; the other is the legal question of choosing a license that supports the appropriate level of sharing and reuse and attributing authors and rightsholders.

* **Publish your source code on a public forge** mandatory

* **Save your repository in dedicated archive** mandatory

* **License your code with an open license** strongly recommended

* **Declare authorship and rightsholders** recommended

140
141
142
143
144
145
146
147
148
149
150

**Publish.** There are many options for making software accessible to the community, but only a few of them are recommended and an even smaller number will pass the test of time. Distributing software upon request is not a good practice. It is very fragile since researchers can move from one lab to another, invalidating both their email and website. Additionally, Collberg *et al.* [21] and Stodden *et al.* [22] found that email requests for software were not honored in the majority of cases. A safer option are forges: dedicated websites whose goal is precisely to facilitate the dissemination and collaboration around source code development, using version control tools such as git. At the time of writing, popular forge systems include Forgejo, Gitlab and the GitHub website. Version control represents a barrier for researchers not yet familiar with these tools, but this barrier is worth overcoming because forges provide some guarantee of durability and offer additional services, such as the preservation of the software's development history, support for
<table><caption>**Figure 1:** Summary of the CODE gradual road map organized in four categories: Open, Document, Execute and Collaborate.</caption><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>OPEN</strong></td><td></td></tr><tr><td><ul><li>Publish your source code on a public forge</li><li>Save your repository in a dedicated archive</li><li>License your code with an open license</li><li>Declare authorship and rightsholders</li></ul></td><td><table><tbody><tr><td><strong>mandatory</strong></td></tr><tr><td><strong>mandatory</strong></td></tr><tr><td><strong>strongly recommended</strong></td></tr><tr><td><strong>recommended</strong></td></tr></tbody></table></td></tr><tr><td><strong>DOCUMENT</strong></td><td></td></tr><tr><td><ul><li>Choose meaningful names</li><li>Comment code</li><li>Provide examples, notebooks and/or tutorials</li><li>Document the API</li></ul></td><td><table><tbody><tr><td><strong>recommended</strong></td></tr><tr><td><strong>recommended</strong></td></tr><tr><td><strong>recommended</strong></td></tr><tr><td><strong>optional</strong></td></tr></tbody></table></td></tr><tr><td><strong>EXECUTE</strong></td><td></td></tr><tr><td><ul><li>List software and hardware dependencies</li><li>Provide a computational environment</li><li>Implement a test suite</li><li>Show real-life usage example with expected results</li></ul></td><td><table><tbody><tr><td><strong>recommended</strong></td></tr><tr><td><strong>optional</strong></td></tr><tr><td><strong>optional</strong></td></tr><tr><td><strong>optional</strong></td></tr></tbody></table></td></tr><tr><td><strong>COLLABORATE</strong></td><td></td></tr><tr><td><ul><li>Respond to issues</li><li>Explain whether contributions are accepted and how to contribute</li><li>Describe maintenance, features and support limits</li><li>Build and animate a community</li></ul></td><td><table><tbody><tr><td><strong>recommended</strong></td></tr><tr><td><strong>recommended</strong></td></tr><tr><td><strong>recommended</strong></td></tr><tr><td><strong>optional</strong></td></tr></tbody></table></td></tr></tbody></table>

151 collaboration among developers, and interaction between developers and users.

152 **Archive.** Forges have become essential collaborative development platforms, but they are not archives. On the one hand, the owner of a project hosted on a forge may *alter, move or remove it at any time*. Document archives like Zenodo or Figshare are being used by researchers to store copies of specific versions of their own source code, but these archives are not software oriented: the version control history is lost, there is no control of granularity, and no intrinsic identifiers. On the other hand, and most importantly, *forges make no commitment to long-term maintenance*, independently of the financial clout of their owners: as a reminder of this fact, two popular forges were closed in 2015 (Gitorious) and 2016 (Google code), making all projects unreachable (over 1.4 million according to Software Heritage archive ⚙️). The shutdown of such popular and well funded
161 forges was a shock to many, and made clear the need for a long term archive specifically designed for software that addresses all the above issues, leading to the creation of Software Heritage ⚙️, a
162 non profit international multi-stakeholder initiative started in 2016 in partnership with UNESCO,
163 which is today the state of the art solution to address the long-term availability of all software source
164 code together with its full development history [23, 24]. Software Heritage proactively harvests code
165 hosting and distribution platforms, and provides mechanisms to trigger archival on demand. As
166 of 2024, its archive contains over 22 billion unique source files collected from over 340 million
167 projects ⚙️, with all their version history, including full copies of the projects that were removed
168 from Gitorious and Google Code. These copies can be used to repair the broken links in the web
169 of academic knowledge. Software Heritage also provides a Software Hash persistent intrinsic
170 identifier (SWHID) ⚙️ for all archived software artifacts. A SWHID allows to precisely pinpoint
171 a version of source code at all levels of granularity [25]. Software Heritage provides the core
172 infrastructural layer that links the academic ecosystem [26] with the many other ecosystems that
173 rely on software, such as industry and public administration [27, 28].
174

175 **License.** While most research software is shared publicly with the intention to make it accessible
176 and reusable for all, following the principles of Open Science, very often this intention is not
177 formalised by the explicit addition of a licence to the code or the repository. If the rightsholder
178 wants to make possible the use of their software, a license that explicit the terms and conditions to
179 this use is mandatory. Indeed, in the absence of a license, the rightsholder keeps exclusive rights
180 (see Choose a license ⚙️): even if the rightsholder has no intention to exercise them exclusively,
181 everyone else will be legally forbidden from (re)using it, reducing its usefulness. Thus, we strongly
182 recommend to provide a license, and preferably an open-source one for the sake of Open Science.
183 The choice of licence should be made in consultation with affiliated institutions and project
184 funders, ensuring at the same time compliance with institutional policies and with the principles
185 of open science.

186 **Authorship.** The identification of authors and copyright holders is an essential part of opening
187 software, both for its legal aspects and for citing software in journal articles. Authors and copyright
188 holders may be individuals, groups of individuals, a collective entity (development team), an
189 institution, etc. Ultimately, authors and copyright holders are the only ones who can define the
190 conditions of reuse for a software, via a license, so it is important that they can be identified.

191 **Document**

Documentation is important for software in general, but even more so for research software, because it often implements highly specialized methods that readers might not be very familiar with. Good documentation of software is every bit as important as good explanations in a scientific paper.

* Choose meaningful names recommended

* Comment code recommended

* Provide examples, notebooks and/or tutorials recommended

* Document the API optional

192

193 The audience for software documentation is diverse. It includes users, who need to understand
194 what the software does exactly and how it is used correctly. It also includes current and prospective
195 developers who wish to modify the software for different applications, and who need to be aware
in particular of any assumptions built into the software that may not be valid for the application they have in mind. For larger and long-lived software packages, the audience for documentation includes current and future contributors and maintainers. And in preparation for a hopefully near future in which scientific software will be peer reviewed, the audience for documentation includes reviewers, who need to be convinced that the software is appropriate for the use case they are reviewing.

**Choose meaningful names.** Documenting code starts with naming variables and functions. When done wisely, these names convey a lot of information to the reader (including the author herself when she looks at her own code some months or years later). For example, naming a function `da vs discrete-analysis` makes a real difference in terms of understanding and re-usability. For short scripts, good names can be sufficient to make the code understandable.

**Comment code.** When names are no longer sufficient, comments added to the code become important. Their goal is not to rephrase the code, but to explain the reasoning that lead to the code. For example, if the code computes the square root of a number, that number must be positive, and a comment may be required to explain why the number is always positive in this specific context. Moreover, non-trivial algorithms require comments that provide a higher-level view of what is going on, to help the reader who might otherwise be lost in the technical details. The description of the parameters that have to be provided to a function, with their type and the reason for this type, is another example of a necessary comment.

**Provide examples.** Application Programming Interface (API) documentation is necessary for precision, but not always sufficient to help new users get started, in particular for large APIs. Learning how to use a complex software package from its API documentation is like learning a foreign language from a dictionary and a grammar. Beginners need pedagogical documentation, such as tutorials and documented usage examples.

**Document the API.** For larger software packages, users cannot be expected to read the code in order to understand what it does and how to use it. Code readability and good comments still matter, for the benefit of contributors, but users require a separate document that focuses on the API that they interact with. API documentation lists and describes the functions, classes, shell commands, and other entities in the software that users refer to in their own code that orchestrates the computation at a higher level.

The transition from commented code to a software package with an API documentation is a major one. Users of commented code have to read and understand the code, and adapt it to their own needs by modifying it. Users of a software package with an API expect to learn everything they need to know from the documentation, and don't even attempt to read the code. Much scientific software is in a dangerous intermediate state: there is an API documentation, but it may not be up to date, differ from the actual behavior of the code, or be incomplete, leaving out details that can be crucial for some applications.
One of the core principles of science is reproducibility, meaning that results can be checked by others. In particular, reproducibility is required for others to build upon previous research. As software can be used to produce research results, it is important to allow other teams to execute it in order to make the results reproducible.

* List software and hardware dependencies recommended

* Provide a computational environment optional

* Implement a test suite optional

* Show real-life usage example with expected results optional

234

**List software and hardware dependencies to avoid dependency hell.** Running software requires a computational environment, which consists of a hardware (the computer) and other software items, called the software's dependencies. If you wish to run a piece of software published by someone else, you must figure out how to construct a suitable environment, by starting with a compatible computer system and installing all the software's dependencies. Unless an explicit list of dependencies is supplied, this task may turn out to be prohibitively difficult or time consuming. This is why we strongly recommend authors to provide a complete and precise description of the dependencies with each published piece of software. Unfortunately, providing such a description is not always easy. You may be able to figure out the components of the environment that you use yourself, although even that can be a difficult task. But not all the components of your environment are actually required. If you run a piece of software on a desktop computer, there is a good chance that it has a Web browser installed, but it is unlikely that this Web browser is required to run the software under question. It is also likely that the software will work equally well in an environment that has somewhat different versions of the dependencies. These uncertainties make it difficult for software authors to describe the environmental requirements, and even more difficult for software users to set up an environment that conforms to these requirements. In the worst case, users succeed in constructing an environment in which the software works without obvious problems, but produces different results than in its original environment. For example, Bhandari Neupane et al. [8] found a portability bug in a previous work, where a research software provides incorrect results in some operating systems. We also refer the reader to a recent initiative to list errors due to research software [29]. Dependency issues and uncertainties are one of the root causes of computational irreproducibility [30].

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

**Provide a computational environment.** One way to help users set up a suitable environment is to provide either an archived environment in the form of a container image (using Docker or virtual machines), or a recipe for constructing an identical environment for a reproducible software manager, such as Guix or Nix. Both approaches require technical expertise that many researchers do not have, which is why we consider this step optional within the current state of the art. A good overview to get started writing Guix recipes is given in the document *A guide to reproducible research papers*¹. Such recipes are the technically best way to provide the description of a computational environment: they are small text files that are easy to publish and archive, and they can be easily modified to explore alternative computational environments for the software. In contrast, container images, created and run using container management software such as Docker or Apptainer, are large files that can be used as-is, but not easily modified. rworkflows [31] is an example for providing both an easy and an advanced solution, for statistical and social sciences and related fields.
**Implement a test suite.** Given the inevitable variability of computational environments, another helpful step is to provide a test suite for the software. A test suite consists of simple example use cases for the software for which the correct results are known and recorded. Executing the test suite verifies that the results are indeed the expected ones, providing the user with reassurance, though not proof, that the software works correctly in its current environment. These test suites are also highly helpful for the original software developers, in order to detect breaking changes early in their development process.

**Real use cases.** A final optional step for helping users to get started with running the software is a collection of usage examples from real-life applications, with the expected results. We have already mentioned examples as documentation, but examples become much more valuable if they are executable. Such examples differ from tests in two ways: first, they are meant to be studied and modified by the user, whereas a test suite is typically executed blindly. Second, they illustrate common usage scenarios of the software, whereas tests tend to focus on simple scenarios and on edge cases that are important for correctness even though they rarely occur in practice.

## 284 Collaborate

We focus on open collaboration, as it has been practiced in FLOSS communities for decades: a long-term collaboration that anyone interested can join, and which nobody owns in any legal or moral sense. We believe that this form of collaboration is what Open Science should aim for more generally.

* Respond to issues recommended

* Explain whether contributions are accepted and how to contribute recommended

* Describe maintenance, features and support limits recommended

* Build and animate a community optional

Traditionally, collaboration in research means that a group of researchers works together on a research project and in the end publishes a joint paper, of which everyone who contributed is a co-author. Such collaborative research can include the production of software, usually in the form of scripts and notebooks that are specific to a project. That is not the kind of collaboration we are discussing in this section. We focus on *open* collaboration that anyone interested can participate in. Open collaborations are typically long-lived and broad-spectrum efforts, which in the realm of software means tools of interest to entire communities. However, not all research code is expected to build and sustain collaborative environments. In practice, collaboration starts by being explicit about what can or cannot be expected in terms of support and maintenance, and whether contributions to the code are welcome.

**Respond to issues and/or feature requests.** The first level of open collaboration on a software package is inviting feedback. Are there any problems with the software? Does it behave incorrectly, or is it too difficult to use? Is there functionality that could be usefully added to it? Issue trackers in software forges were designed to collect such feedback and support open discussions about them.

**Explain whether contributions are accepted and how to contribute.** The second level of open collaboration is permitting and soliciting not only feedback, but also contributions, be it to the
303 code itself or to its documentation, or to the governance structure of the project. This requires
304 careful thought. Contributions need to be reviewed, which takes time. Contributions that make the
305 code larger or more complex increase the maintenance effort in the future. It is therefore necessary
306 to decide on a policy for handling contributions, define a workflow, and document it publicly.
307 Furthermore, it is good practice to think about onboarding, i.e. integrating new contributors into
308 the collaboration. For example, many projects maintain a list of easy problems ("good first issue")
309 that are suitable as entry points to become familiar with the code and with the culture of its
310 community.

311 **Describe maintenance, features and support limits.** The experience with FLOSS projects has
312 shown that when a piece of software attracts a critical mass of users, such feedback can easily
313 overwhelm the development team. After all, criticism (even when fully justified) is easy, whereas
314 dealing with it is a lot of work. An important step for open collaboration is thus defining limits and
315 stating them clearly. What level of maintenance and support are the developers able and willing
316 to provide? Which kind of feature requests will be considered, and which will be considered out
317 of scope?

318 **Build and animate a community.** The third level of open collaboration is to build a community
319 around the software. This involves organizing tutorials, workshops, and hackathons, and mentor-
320 ing new contributors. For very large projects, it can also involve communicating to a wider public,
321 and establishing relations with decision makers in industry or society. The goal of community
322 building is not growth for growth's sake. Success of a community should rather be evaluated by
323 the satisfaction of its members, its willingness to welcome everyone who wishes to participate,
324 and its integration into a wider scientific ecosystem that ensures epistemic diversity and critical
325 evaluation of each other's work.

326 **A call to action for all research software stakeholders**

327 Besides researchers and engineers, there are several stakeholders that have prominent roles to play
328 in supporting scientific software in all its dimensions. Researchers and engineers are the main
329 actors, but they require support and recognition for their work, both of which are still lacking in a
330 large number of countries and institutions. Knowles et al. [32] further discuss this issue. Their
331 dramatic example concerns the ehtim software, which contributed to making headlines through
332 the first image rendering of a black hole in 2019, while the authors were at the same time denied
333 funding to maintain it. The fragility of software dependencies and maintenance is also masterfully
334 captured by XKCD #2347.
<table><caption>Figure 2: Summary of guidelines for the different stakeholders.</caption><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>INSTITUTIONS</strong></td><td></td></tr><tr><td><ul><li>Support development</li><li>Promote software</li><li>Build and maintain institutional forges</li></ul></td><td><strong>mandatory</strong><br>recommended<br>optional</td></tr><tr><td><strong>FUNDERS</strong></td><td></td></tr><tr><td><ul><li>Provide grants for long-term support</li><li>Promote reproducibility</li><li>Facilitate collaborations</li></ul></td><td><strong>mandatory</strong><br>recommended<br>optional</td></tr><tr><td><strong>LIBRARIES</strong></td><td></td></tr><tr><td><ul><li>Prepare software archival plans</li><li>Create and curate software metadata</li><li>Catalog software</li></ul></td><td><strong>mandatory</strong><br><strong>mandatory</strong><br>recommended</td></tr><tr><td><strong>PUBLISHERS</strong></td><td></td></tr><tr><td><ul><li>Enforce open source</li><li>Link publications and codes</li><li>Review software</li></ul></td><td><strong>mandatory</strong><br>recommended<br>optional</td></tr></tbody></table>
The role of institutions for supporting and promoting software is critical and they can act on several different levels.

* **Support development** mandatory

* Promote software recommended

* Build institutional forges optional

336

**Support development by investing in the required human resources.** Nowadays, software development is a prevalent part of scientific work. As such, we advocate for first-class recognition and support of software development activities by institutions. This support is provided by various means. The primary mean is to hire research software engineers, who bring the necessary expertise to develop, maintain and deploy research software. This need is not new: in many countries research engineers working on software have been around for decades, well before the recent grassroot effort that led to the creation of research software engineer societies 🌐, but it is important to recognise them as a specific body, with skills and requirements of their own. These research software engineers are the backbone of the software development process and can help raise awareness of basic software development practices among research staff [33].

337

338

339

340

341

342

343

344

345

346

347

**Support development by creating legal frameworks that scientists and engineers can find their way around.** A team wishing to publish a piece of software must be able to find out easily who the rightsholders are and which person to contact for inevitable legal arrangements such as choosing a licence. Ideally, institutions should make it possible for scientists and engineers to publish research software under an Open Source license without imposing a lengthy bureaucratic procedure for obtaining permission.

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

**Promote software.** Institutions can help promote software by acknowledging software creation and development as contributions that can be taken into account when hiring or promoting scientific and engineering staff [34, 35]. The creation of software-related awards can create visibility and awareness on the importance of software development within institutions. To the best of our knowledge, France has led the way by creating a national Open Science Research Software Award [36] in 2022. These prizes reward projects and teams working to develop and disseminate open source research software, and are presented by the Ministry of Higher Education and Research in a high-profile annual ceremony. The award has several categories aimed at showcasing projects according to their scientific and technical dimensions, their capacity to train and lead a community and the quality of their documentation. A full description of the goals, difficulties, approach and lessons learned has been published by Catala et al. [37], providing actionable blueprints for a broader adoption of the concept. New research software awards have been recently created, for example with the South African National Science and Technology Forum [38]. This process https://nstf.org.za/research-software-awards/

367

368

369

370

371

**Build and maintain institutional forges.** Software forges were created some 25 years ago as a means to facilitate collaboration within developer teams. With the fast growth of Open Source, and the advent of modern version control tools, some of them have progressively become large scale social networks, with the associate network effects that lead to concentration into a handful of big players. Research software developers face a difficult decision about which forge to choose,
based on the target audience and network. The options range from institutional forges (i.e. hosted on institutional servers) to publicly available, general purposes commercial ones (i.e. GitHub, GitLab, BitBucket), with open-source community forges as an alternative if the software fits the requirements of such a community. Le Berre *et al.* [39] present a comprehensive description of the issues at stake when building institutional forges, based on a broad analysis of over 70 such forges used in French Higher Education and Research. One key issue is the tension between the need to maintain control over the use of the resources, and the desire to enable contributions with minimal friction from unknown individuals worldwide. Currently, access to most of the analyzed forges is available only to the institution's own members, which drastically limits external contributions, and even becomes an obstacle for the automated workflow of journals dedicated to software, such as JOSS, which requires submissions to be available on a forge which is open to anybody (without registration approval). It seems that this is the reason why so much software is currently developed on commercial forges. This situation may change if a coordinated effort is put in place to remove the technical and administrative obstacles that make it currently difficult to accept external contributions on institutional forges (e.g. via federation of identities and appropriate access control to the different resources).

## 388 Funders

* Provide grants for long-term support

mandatory

* Promote reproducibility

recommended

* Facilitate collaborations

optional

389

**Provide grants for long-term support of valuable software.** As recently reiterated by Coelho [40], *most [research] software is designed and built by research groups funded by short-term research grants*. These short-term grants are both beneficial and detrimental to a software project. They are beneficial for seeding new software through temporary hirings, and sometimes start building a community. They are detrimental because once the grant is finished, researchers are on their own to maintain the software to the best of their skills. Maintaining software is difficult and requires advanced skills in software development to deal with software collapse [41]. Thus, we believe that public research funders should additionally offer grants to support long-term maintenance of software with a proven value (e.g, used and cited by the scientific community), and not only development of new tools and systems. This issue has been acknowledged by the Research Software Alliance Funders Forum ⌄ recently. Pioneering public research agencies have recently proposed the first software maintenance grants, see for example the UK's Software Sustainability Institute ⌄ or the German Research Foundation ⌄. The private Chan Zuckerberg Initiative has shown one way to do this with its *Essential Open Source Software for Science* program: we believe more research should go into exploring the different mechanisms that can be put into play to balance between funding innovation and supporting maintenance with the necessarily limited resources that are available [42].

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

**Promote reproducibility.** Being able to reproduce and replicate results is a cornerstone of the scientific approach. However, the scientific community is facing a reproducibility crisis [43–46]. Funders should ensure that by default, research software is licensed and distributed under free and open-source licences. Limited exceptions can then be introduced when closed source code is
necessary, e.g. for security concerns, confidentiality, or in some industrial collaborations. This continues a tradition where important funders, such as the European Research Council, have successfully been promoting key open science practices (e.g., open access publication and open data).

**Facilitate collaborations.** We have explained previously that scientific software depends on a software stack whose components have very diverse origins. These components can be themselves highly specialized scientific software, but they can be also much more generic and serve broader goals. To name but one example, the ubiquitous NumPy library [47] is the primary array programming library for the Python language and has an essential role in research analysis pipelines in fields as diverse as physics, chemistry, astronomy, geoscience, biology, psychology, materials science, engineering, finance and economics. This library is community driven and its development still depends heavily on contributions made by graduate students and researchers in their free time. This situation is problematic because it means a large part of science depends on the free time of a few people. This is the reason why funders need to consider alternative funding models, where, for example, a subset of a grant could be dedicated to the support of a core library or a core developer could be supported through the grant even though her work would be only indirectly linked to the grant. Research funders could copy recent initiatives applied to FLOSS, such as the publicly-funded German Sovereign Tech Fund ⚙️.

## Libraries

Since research software is becoming an important research output, libraries can pivot and apply their expertise to the case of software, ensuring proper metadata definition and archival.

* Prepare software archival plans mandatory

* Create and curate software metadata mandatory

* Catalog software recommended

**Prepare software archival plans.** As we have explained before ("Archive" recommendation for scholars who develop software), while forges are great tools fostering collaborations, they are not suitable for archiving software. Libraries are dedicated to archiving scientific work, and have recently engaged in promoting open science practices [48]. We suggest that libraries should go one step further and create software archival plans, ensuring that local scientists properly archive their research software hosted on forges (be it local or global ones).

**Create and curate software metadata.** Libraries have historically created and handled metadata and citation systems for books and articles; we argue they should develop similar processes for software. Software is a very complex and fragile object and therefore, metadata is needed for providing provenance information as well as to properly credit authors. One first kind of metadata is persistent identifiers. For example, Software Hash Identifiers (SWHID) are permanent identifiers that allow to reference a specific version of the source code of a project, at different levels of granularity. A second kind of metadata can be required to cite software, for example using CodeMeta ⚙️, Bioschemas ComputationalTool ⚙️ or the Automated Software Metadata Publication ⚙️. Indeed, citing the article mentioning a software package is common practice among researchers but is not compatible with the software lifecycle, which makes this citation eventually inaccurate.
This is the reason why Chue Hong et al. [49] highlighted the need to cite the software itself, acknowledging is as a legitimate product of research. It is to be noted that referencing and citing are related to distinct needs. Citing software refers to the authorship: the purpose is to attribute credits.

**Catalog software.** Once software is well-described through appropriate, potentially curated metadata, we can implement the Findable principle of FAIR by creating software catalogs. These catalogs can be handled by libraries at an institutional level to showcase contributions and productions (NASA's Software Catalog ⚙️, French Catalog for Research Software ⚙️), or for specific scientific communities (swMATH ⚙️, bio.tools ⚙️).

## Publishers

Publishers have a role to play in order to guarantee that code is shared at the time of publication. We cannot be satisfied anymore with current recommendations according to which *availability upon request* is still an option.

* **Enforce open source** mandatory

* Link publications and codes recommended

* Review software optional

**Enforce open source.** Following the wide adoption of open science practices scientists and publishers, we propose to tackle the reproducibility crisis by enforcing the open-source publication of code alongside papers. *Ugly code* is always better than no code [50]. Sharing code has been made extremely easy with Zenodo or Software Heritage, even though it still requires a minimal experience with version control tools. In that context, publishers have a role to play in order to guarantee that code is not only promised, but actually shared at the time of publication. We cannot be satisfied anymore with the current recommendations according to which *availability upon request* is still an option. Case in point, the Nature journal received severe criticism [51] from the machine learning community, following the publication of "International evaluation of an AI system for breast cancer screening" [52]. Haibe-Kains et al. explains that the lack of details of the methods and algorithm code undermines its scientific value. This criticism lead to a policy change for the given journal.

**Link publications and codes (and data).** In order to make research more transparent, accessible and inclusive, it is essential to have access not only to publications but also to all scientific inputs used to create them, and in particular code and data. Publishers have a significant responsibility for ensuring that all these scientific objects are linked together. The publication ecosystem must now integrate sources code. Some editors have already started this process. For example, Dagstuhl Artifact Series (DARTS) [53] and IACR's Artifact Archive [54] enable publication of peer-reviewed software artifacts (cf. next paragraph) alongside papers that have been accepted in a conference or journal from the same editor. Long-term archiving of source code can be obtained by interoperating with code archives such as Software Heritage.

**Review Software.** As described in detail by Di Cosmo et al. [28] and Informatics Europe et al. [55], various communities have over time put in place mechanisms for reviewing software associated to publications, ranging from a simple check of existence, to quality of metadata, to quality
of software and adequacy with respect to what is stated in the publications. As an example,
some computer science communities – including the formal methods, software engineering,
systems, security, and architecture communities – have put in place an *artifact evaluation* process,
with a dedicated program committee, which started in 2011. In these communities, authors are
encouraged to submit a software artifact in addition to their paper. Artifacts are built and evaluated
to ensure that all the software-related experimental claims of the paper can be reproduced by
anyone. An artifact consists of a snapshot of the computational environment and the software
used for the experimental evaluation of the paper – distributed for example as a docker container
or an image of a virtual machine. Reviewers may grant different badges to an artifact, depending
on its various qualities [56]. Publishers should consider getting together to identify the various
levels of review that have been field-tested, and propose a unified approach to enable the various
research communities to adopt the one most appropriate to them.

Discussion
=========

Not all scientific software is created equal. Some is meant to be widely disseminated in the scientific community, to grow and to be maintained in the long term, while other software serves solely as a one-shot illustration of a concept or an idea. But both are important for science. Independently of the goal, the size, or the form of the software, we advocate first and foremost to share the code and archive it permanently, even if authors may think it is not worth being shared. Then, and only then, more can be asked from the authors. Practices currently vary widely across the scientific community. Much research software is still not published at all, but some well-established open-source research software projects already follow all our recommended steps.

In their FAIR4RS principles, Barker *et al.* [15] extend the FAIR principles to the case of software, in order to improve how to find it, how to access it, how to interoperate software, and how to reuse software. Only two years after its publication, it has been adopted internationally by various communities. FAIR4RS includes recommendations “R1.1. Software is given a clear and accessible license.” and “R3. Software meets domain-relevant community standards.”, which are related to some of our CODE principles for software developers. The goal of CODE is to provide additional guidance to improve research software distribution and reuse. In addition, scientists cannot bear these new aspects of scientific research alone: CODE also includes a call to action for other research software stakeholders to appreciate and fund software. Contrary to some communities who adopted FAIR4RS, we believe in particular that the long-term sustainability of software should *not* be the sole responsibility of scientists.

Alves *et al.* [57] introduce Software Management Plans, providing a methodology for expert computer scientists to gradually improve their software. Alves *et al.* [57] mention that “there are a few SMPs already available, most of them require significant technical knowledge to be effectively used”, although recent advances aim at making them more accessible [58, 59]. Our aim in this work is to provide a tiered roadmap to ensure minimal good practices will be followed by non-expert scientists. In addition, our work advocates for actions put in place by all stakeholders of the scientific process.
Institutional support and explicit open-source policies are gaining traction. Some of these recommendations have already been put into practice. To name a few, several countries now regularly award outstanding research software [60]. Leading institutions, including NASA through its Open Science Program and Open Source Funding Program (2024) and the international Coalition for Advancing Research Assessment ⚙️, recognize the value of software engineering in research. Research institutes like France's National Institute for Research in Digital Science and Technology (INRIA) consider software development, in addition to as other markers of achievements such as publications and community service, when hiring [34]. At both the European and international levels, a number of actors are also present and work similarly for the recognition of scientific software in science. To name just a few, we can cite the Research Data Alliance, UNESCO, Software Heritage, the Research Software Alliance, the European Open Science Cloud, Knowledge Exchange and Zenodo. Members of the EVERSE project have recently surveyed the "rewards and mechanisms for research software and training activities" [35]. Private foundations, such as the Sloan Foundation and the Chan Zuckerberg Initiative in the USA, have been engaged with the recognition, support and promotion of scientific software for a few years already, with policies that start to have long lasting impacts along several dimensions.

We are happy to see these improvements, but there is still a long way to go. First, we think that what is holding researchers and engineers back is mainly a lack of support from institutions, funders, libraries and publishers. Good open-source software requires long term resources: good infrastructure, secured funding and training. Second, it is time to recognize research software as a valuable scientific contribution in itself, beyond a tool – and to support it. It is important to re-assess that research software is special: it has become over the years a critical ingredient of science and yet, it is still not recognized widely enough as a valuable scientific contribution [61]. It cannot be reduced to "just data", and imposing some high-level principles that ignore this fact might be counter-productive: FLOSS developers and researchers have created and shared code for many decades and their experience and practice, formed well before the term Open Science became popular, must be properly taken into account.

The CODE gradual roadmap for scholars who develop software shares some goals with the process of "Artifact evaluation" started by some computer science communities in 2011 [62] – although artifacts and research software are not equivalent. After a few years, a group of academics related to the Association for Computer Machinery (ACM) standardized artifact evaluation criteria through a badging system [56]. Note that other associations such as EAPLS ⚙️ use similar systems, and that non-ACM publisher such as Dagstuhl's DARTS/LIPIcs ⚙️ use it. The "Artifact Available" badge mandates that the artifact is publicly accessible and archived (usually on Zenodo). The "Artifact Evaluated: Functional badge" mandates that the artifact is documented and exercisable with included scripts to generate the results in the paper, which is similar to some of the recommended points of the Document and Execute blocks. The "Artifact Evaluated: Reusable" badge mandates that the quality of the artifact significantly exceeds minimal functionality, which is close to some points of the Document and Execute blocks.
561

**Methods**

562

563

564

565

566

567

568

We gathered as a diverse group of experts in Scientific Data and Research Software, sharing an interest in Open Science and Reproducible Research. We started this work by studying the specificity of research software (compared to research data), and the consequences of this specificity on research software. We made sure our discussion group was interdisciplinary in order to propose principles that would apply broadly and be understandable to every scientist, not only specialized computer scientists. This work is the culmination of three years of discussion within this group.

569

570

571

572

573

**Conclusion.** Research software is now a foundation of most scientific research. This article presents the CODE gradual roadmap for scholars who want to improve their research software, thus contributing to improving scientific reproducibility. This roadmap is complemented by a call to action for research software stakeholders to truly make research software a pillar of the scientific process.

574

**Data Availability.** No data is shared in this paper.

575

**Code Availability.** No code is shared in this paper.

576

**References**

577

578

579

1. Howison, J. & Bullard, J. Software in the scientific literature: Problems with seeing, finding, and using software mentioned in the biology literature. *Journal of the Association for Information Science and Technology* **67**, 2137-2155 (2016).

580

581

582

2. Bassinet, A., Bracco, L., L'Hôte, A., Jeangirard, E., Lopez, P. & Romary, L. *Large-scale Machine-Learning analysis of scientific PDF for monitoring the production and the openness of research data and software in France* working paper or preprint. 2023. https://hal.science/hal-04121339.

583

584

585

3. Catala, I., Boulet, P., Courbebaisse, G., Daydé, M., Gérard, S., Guerry, B., Muller, P.-A., Tonda-Goldstein, S., Louvet, V. & Moreau, P. *Production et valorisation des logiciels issus de la recherche publique française* tech. rep. (Comité pour la science ouverte, Nov. 2024). doi:10.5294/47.

586

587

4. Jay, C., Haines, R. & Katz, D. S. Software Must be Recognised as an Important Output of Scholarly Research. *International Journal of Digital Curation* **16**, doi:10.2218/ijdc.v16i1.745 (2021).

588

589

5. Gruenpeter, M. et al. *Defining Research Software: a controversial discussion* version 1. Sept. 2021. doi:10.5281/zenodo.5504016.

590

591

6. Pigott, D. J. & Axtens, B. M. *Online Historical Encyclopaedia of Programming Languages* http://hopl.info/ (2023).

592

593

7. Courbebaisse, G., Flemisch, B., Graf, K., Konrad, U., Maassen, J. & Ritz, R. Research Software Lifecycle. en. doi:10.5281/ZENODO.8324827 (2023).

594

595

596

597

8. Bhandari Neupane, J., Neupane, R. P., Luo, Y., Yoshida, W. Y., Sun, R. & Williams, P. G. Characterization of Leptazolines A-D, Polar Oxazolines from the Cyanobacterium Leptolyngbya sp., Reveals a Glitch with the "Willoughby-Hoye" Scripts for Calculating NMR Chemical Shifts. *Organic Letters* **21**, 8449-8453. doi:10.1021/acs.orglett.9b03216 (2019).
598

599

600

601

9. Raymond, E. S. *The cathedral and the bazaar: musings on Linux and open source by an accidental revolutionary* 2., überarb. und erw. A. eng. With a foreword by Bob Young, 241. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ (O'Reilly Media, Beijing; Cambridge; Farnham; Köln; Paris; Sebastopol; Taip, 2001).

602

603

10. Stallman, R. M. & Gay, J. *Free Software, Free Society: Selected Essays of Richard M. Stallman* (CreateSpace, Scotts Valley, CA, 2009).

604

605

606

11. Jullien, N., Viseur, R. & Zimmermann, J.-B. A theory of FLOSS projects and Open Source business models dynamics. *Journal of Systems and Software* **224**, 112383. doi:https://doi.org/10.1016/j.jss.2025.112383 (2025).

607

608

12. Wilkinson, M. D. et al. The FAIR Guiding Principles for scientific data management and stewardship. *Scientific Data* **3**, doi:10.1038/sdata.2016.18 (Mar. 2016).

609

610

13. Lamprecht, A.-L. et al. Towards FAIR principles for research software. *Data Science* **3**, 37–59. doi:10.3233/DS-190026 (2020).

611

612

613

14. Gruenpeter, M., Di Cosmo, R., Koers, H., Herterich, P., Hooft, R., Parland-von Essen, J., Tana, J., Aalto, T. & Jones, S. M2.15 Assessment report on ‘FAIRness of software’. en. doi:10.5281/ZENODO.5472911 (2020).

614

615

616

15. Barker, M., Chue Hong, N. P., Katz, D. S., Lamprecht, A.-L., Martinez-Ortiz, C., Psomopoulos, F., Harrow, J., Castro, L. J., Gruenpeter, M., Martinez, P. A., *et al*. Introducing the FAIR Principles for research software. *Scientific Data* **9**, 622 (2022).

617

618

16. Chue Hong, N. P. et al. FAIR Principles for Research Software (FAIR4RS Principles). en. doi:10.15497/RDA00068 (2021).

619

620

621

17. Sonabend, R., Gruson, H., Wolansky, L., Kiragga, A. & Katz, D. S. FAIR-USE4OS: Guidelines for creating impactful open-source software. *PLOS Computational Biology* **20** (ed Papin, J. A.) e1012045. doi:10.1371/journal.pcbi.1012045 (May 2024).

622

623

18. Bruford, E. A., Braschi, B., Denny, P., Jones, T. E. M., Seal, R. L. & Tweedie, S. Guidelines for human gene nomenclature. *Nature Genetics* **52**, 754–758. doi:10.1038/s41588-020-0669-3 (Aug. 2020).

624

625

626

19. Carver, J. C., Weber, N., Ram, K., Gesing, S. & Katz, D. S. A survey of the state of the practice for research software in the United States. *PeerJ Computer Science* **8**, e963. doi:10.7717/peerj-cs.963 (May 2022).

627

628

629

20. Di Cosmo, R., Granger, S., Hinsen, K., Jullien, N., Le Berre, D., Louvet, V., Maumet, C., Maurice, C., Monat, R. & Rougier, N. Stop treating code like an afterthought: record, share and value it. *Nature* **646**, 284–286. doi:10.1038/d41586-025-03196-0 (Oct. 2025).

630

631

21. Collberg, C. & Proebsting, T. A. Repeatability in computer systems research. *Communications of the ACM* **59**, 62–69 (2016).

632

633

22. Stodden, V., Seiler, J. & Ma, Z. An empirical analysis of journal policy effectiveness for computational reproducibility. *Proceedings of the National Academy of Sciences* **115**, 2584–2589 (2018).

634

635

636

23. Di Cosmo, R. & Zacchiroli, S. *Software Heritage: Why and How to Preserve Software Source Code* in *iPRES 2017 - 14th International Conference on Digital Preservation* (Kyoto, Japan, Sept. 2017), 1–10. https://hal.science/hal-01590958.

637

638

24. Abramatic, J.-F., Cosmo, R. D. & Zacchiroli, S. Building the Universal Archive of Source Code. *Communications of the ACM* **61** (ed ACM) 29–31. doi:10.1145/3183558 (Oct. 1, 2018). published.

639

640

641

25. Cosmo, R. D., Gruenpeter, M. & Zacchiroli, S. *Identifiers for Digital Objects: the Case of Software Source Code Preservation* in *iPRES 2018 - 15th International Conference on Digital Preservation* (Sept. 1, 2018). doi:10.17605/OSF.IO/KDE56 (published).

642

643

644

26. Of Higher Education, M. & Research. *French National Strategy on Research Infrastructures* 2021 https://www.enseignementsup-recherche.gouv.fr/sites/default/files/2023-02/french-national-strategy-on-research-infrastructures---2021-26489.pdf (2023).
645

646

647

27. Cosmo, R. D., Gruenpeter, M., Marmol, B., Monteil, A., Romary, L. & Sadowska, J. Curated Archiving of Research Software Artifacts: Lessons Learned from the French Open Archive (HAL). *International Journal of Digital Curation* **15**, 16. doi:10.2218/ijdc.v15i1.698 (Jan. 1, 2020). published.

648

649

650

28. Di Cosmo, R. et al. *Scholarly Infrastructures for Research Software. Report from the EOSC Executive Board Working Group (WG) Architecture Task Force (TF) SIRS*. doi:10.2777/28598 (European Commission. Directorate General for Research and Innovation., 2020).

651

652

29. Katz, D. S. et al. *Errors due to research software*. https://github.com/danielskatz/errors-due-to-research-software/ (2025).

653

654

30. Hinsen, K. in *Computation in Science (Second Edition)* 6-1 to 6–20 (IOP Publishing, 2020). doi:10.1088/978-0-7503-3287-3ch6 (2020).

655

656

31. Schilder, B. M., Murphy, A. E. & Skene, N. G. rworkflows: automating reproducible practices for the R community. *Nature Communications* **15**, doi:10.1038/s41467-023-44484-5 (Jan. 2024).

657

658

32. Knowles, R., Mateen, B. A. & Yehudi, Y. We need to talk about the lack of investment in digital research infrastructure. *Nature Computational Science* **1**, 169–171 (2021).

659

660

33. Heroux, M. A. Research Software Science: Expanding the Impact of Research Software Engineering. *Computing in Science & Engineering* **24**, 22–27. doi:10.1109/MCSE.2023.3260475 (Nov. 2022).

661

662

34. Canteaut, A., Fernández, M. A., Maranget, L., Perin, S., Ricchiuto, M., Serrano, M. & Thomé, E. *Software Evaluation* Research Report (Inria, Jan. 2021). https://inria.hal.science/hal-03110728.

663

664

35. Vergoulis, T. et al. *D5.1 Landscape analysis of existing rewards and mechanisms for research software and training activities*. Mar. 2025. doi:10.5281/zenodo.14978474 (2020).

665

666

36. French Committee for Open Science. *The 2023 Open Science Free Research Software Awards*. https://www.ouvrirlascience.fr/the-2023-open-science-free-research-software-awards/ (2024).

667

668

669

37. Catala, I. B., Di Cosmo, R., Giraud, M., Le Berre, D., Louvet, V. & Renaudin, S. Establishing a national research software award. *Open Research Europe* **3**, 185. doi:10.12688/openreseurope.16069.1 (Oct. 2023).

670

671

38. South African National Science and Technology Forum. *Research Software Awards*. https://nstf.org.za/research-software-awards/ (2025).

672

673

674

39. Le Berre, D., Jeannas, J.-Y., Di Cosmo, R. & Pellegrini, F. *Higher Education and Research Forges in France - Definition, uses, limitations encountered and needs analysis* tech. rep. (Comité pour la science ouverte, Nov. 2023). doi:10.52949/37 (2023).

675

676

40. Coelho, L. P. For long-term sustainable software in bioinformatics. *PLOS Computational Biology* **20** (ed Papin, J. A.) e1011920. doi:10.1371/journal.pcbi.1011920 (Mar. 2024).

677

678

41. Hinsen, K. Dealing With Software Collapse. *Computing in Science & Engineering* **21**, 104–108. doi:10.1109/mcse.2019.2900945 (May 2019).

679

680

681

42. Blanc, I., Di Cosmo, R., Giraud, M., Le Berre, D., Louvet, V., Rougier, N. P., Granger, S. & Pellegrini, F. *Highlights of the "Software Pillar of Open Science" workshop* tech. rep. (Comité pour la Science Ouverte, June 2024). doi:10.52949/53 (2024).

682

683

43. Prinz, F., Schlange, T. & Asadullah, K. Believe it or not: how much can we rely on published data on potential drug targets? *Nature reviews Drug discovery* **10**, 712–712 (2011).

684

685

686

44. Button, K. S., Ioannidis, J. P., Mokrysz, C., Nosek, B. A., Flint, J., Robinson, E. S. & Munafò, M. R. Power failure: why small sample size undermines the reliability of neuroscience. *Nature reviews neuroscience* **14**, 365–376 (2013).

687

688

689

45. Camerer, C. F., Dreber, A., Forsell, E., Ho, T.-H., Huber, J., Johannesson, M., Kirchler, M., Almenberg, J., Altmejd, A., Chan, T., et al. Evaluating replicability of laboratory experiments in economics. *Science* **351**, 1433–1436 (2016).

690

46. Baker, M. Reproducibility crisis. *nature* **533**, 353–66 (2016).
691

692

47. Harris, C. R. et al. Array programming with NumPy. *Nature* **585**, 357–362.
doi:10.1038/s41586-020-2649-2 (Sept. 2020).

693

694

48. Liu, L. & Liu, W. The engagement of academic libraries in open science: A systematic review. *The Journal of Academic Librarianship* **49**, 102711 (2023).

695

696

49. Chue Hong, N., Allen, A., Gonzalez-Beltran, A., de Waard, A., Smith, A., Robinson, C. & Pollard, T. Software Citation Checklist for Authors (Version 0.9. 0). *Zenodo*. doi **10** (2019).

697

698

50. Leveque, R. J. *SIAM News* **46**. https://sinews.siam.org/Details-Page/top-ten-reasons-to-not-share-your-code-and-why-you-should-anyway (Apr. 2013).

699

700

51. Haibe-Kains, B. et al. Transparency and reproducibility in artificial intelligence. *Nature* **586**, E14–E16.
doi:10.1038/s41586-020-2766-y (Oct. 2020).

701

702

52. McKinney, S. M. et al. International evaluation of an AI system for breast cancer screening. *Nature* **577**,
89–94. doi:10.1038/s41586-019-1799-6 (Jan. 2020).

703

704

53. Dagstuhl. *Dagstuhl Artifact Series* https://drops.dagstuhl.de/entities/journal/DARTS (2024).

54. IACR. *IACR Artifact Archive* https://artifacts.iacr.org/ (2024).

705

706

55. Informatics Europe et al. *Informatics Research Evaluation, 2025 Revised Report* Mar. 2025.
doi:10.5281/zenodo.15834583.

707

708

56. ACM. *Artifact Review and Badging*
https://www.acm.org/publications/policies/artifact-review-and-badging-current (2023).

709

710

57. Alves, R., Bampalikis, D., Castro, L. J., Fernández, J. M., Harrow, J., Kuzak, M., Martin, E.,
Psomopoulos, F. E. & Via, A. ELIXIR Software Management Plan for life sciences. *BioHackrXiv* (2021).

711

712

713

58. Santangelo, M. G., Jacquemot, M.-C., Sadowska, J., Medves, M., Chachay, S., Warth, V. & Louvet, V. *Advancing FAIR Principles for Research Software: Implementing a Machine Actionable Software Management Plan into DMP OPIDoR* https://indico.cern.ch/event/1484392/contributions/6542372/ (2025).

714

715

59. Martinez-Ortiz, C., Martinez Lavanchy, P., Sesink, L., Olivier, B. G., Meakin, J., de Jong, M. & Cruz, M. *Practical guide to Software Management Plans* version 1.1. Jan. 2023. doi:10.5281/zenodo.7589725.

716

717

60. Catala, I., Di Cosmo, R., Giraud, M., Le Berre, D., Louvet, V. & Renaudin, S. *Establishing a national research software award* working paper or preprint. 2023. doi:10.12688/openreseurope.16069.1.

718

719

61. Hocquet, A. et al. Software in science is ubiquitous yet overlooked. *Nature Computational Science*.
doi:10.1038/s43588-024-00651-2 (July 2024).

720

721

722

723

724

62. Winter, S., Timperley, C. S., Hermann, B., Cito, J., Bell, J., Hilton, M. & Beyer, D. *A Retrospective Study of one Decade of Artifact Evaluations in Software Engineering 2024, Fachtagung des GI-Fachbereichs Softwaretechnik, Linz, Austria, February 26 - March 1, 2024* (eds Rabiser, R., Wimmer, M., Groher, I., Wortmann, A. & Wiesmayr, B.) **P-343** (Gesellschaft für Informatik e.V., 2024), 95–96.
doi:10.18420/SW2024_28.

725

726

727

728

729

**Author Contributions.** All authors contributed to the discussions designing our CODE roadmap. We unanimously chose an alphabetical author order to reflect the group work. Nicolas P. Rougier drafted the base text of the initial manuscript, which has been refined and edited by the remaining authors. Raphaël Monat is the corresponding author and handled the bulk of the submission and revision process to Scientific Data.

730

731

732

733

**Competing Interests.** Camille Maumet is an Editorial Board Member for Scientific Data, handling manuscripts for the journal and advising on its policy and operations. Roberto Di Cosmo is the director of Software Heritage. The authors declare no other competing interests.