Part of open science is not only making research data but also research software and code FAIR: Findable, Accessible, Interoperable and Reusable. But how to do this - and why is this important anyway?

We talked about this to Burcu Beygu, who is a research software specialist at the UG DCC and supports the Engineering and Technology Institute Groningen (ENTEG) of the Faculty of Science and Engineering (FSE). 

What is research software?

Research software constitutes any piece of executable code that contributes to collecting, analyzing or in any way modifying the data attached to your research. It actually comes in many forms and applications and includes source code files, algorithms, scripts, computational workflows and executables that were created during the research process or for a research purpose. Software components (e.g., operating systems, libraries, dependencies, etc.) that are used for research but were not created during or with a clear research intent should be considered ‘software in research’ and not research software. Various studies indicate that researchers increasingly rely on software for their research. Research software is also increasingly recognized as an important form of scholarly output.

Why does research software need to be open?

In order to reproduce research results we need to provide access to the underlying research data, but also to the software used to achieve these results. For this reason both the research data and software need to be made as open and accessible as possible. Another good reason is to get credit for the time and effort you put into developing your software. Researchers often do not receive the recognition that they deserve for this. By making your research software openly available, you increase its findability and the chance of getting cited. This helps you expand your network and reach potential collaborators.

What can researchers do to make their research software FAIR (Findable, Accessible, Interoperable and Reusable)? Why is this important?

In order to make your research software FAIR there are a number of best practices that you could follow:

• Plan for it early on. You could do this by drafting a Software Management Plan (SMP) at the start of your project. The SMP-template helps you to reflect on important questions about what the research software will do, who it is for and how to ensure long-term sustainability, accessibility and reusability.

• Keep your data in a code repository such as GitHub or GitLab and provide good documentation. You should at least include a README file explaining what the software does and how it can be used and installed. If the software requires additional libraries or dependencies, these should be clearly explained as well.  

• Only making your software openly available in GitHub or GitLab does not imply that you give consent for its reuse. It is important to include a software license as well. This states under which conditions your software may be reused by others. 

• Do not forget to also include a citation.cff file. This contains information about the author(s), title, license, version, etc. If someone wants to cite your research software, this file lets them know how to properly do this. 

• Another important practice is to comply with the clean code best practices of the language  used to create the software. This allows other people to easily read and understand your code and work with it. 

• The last step is to submit your research software to a public database such as Zenodo. Each version of your software will be assigned a unique Digital Object Identifier (DOI) and this will also help to increase its visibility, accessibility and findability. Zenodo is especially practical since it has a GitHub integration.

Some researchers may be hesitant to share their code or software, for instance because they are afraid of scooping. What would be your advice?

This is a very valid concern; as a researcher you of course want to avoid getting scooped. A guiding principle for dealing with research data as well as software is to be ‘as open as possible and as closed as necessary’. Once you publish your code with a license in a public repository such as Zenodo, your software receives a DOI that confirms your authorship at the time of publication, while the license determines the conditions for reuse. As is the case with research data, you will need to make your software available eventually. By adopting the best practices mentioned above you establish authorship of the products that you published. 

What kind of support for research software management do you as DCC offer?

One of the things me and colleagues of the UG’s Digital Competence Centre (DCC) do is provide training. In our workshops we help researchers to build skills and apply best practices for creating reproducible and reusable software. We address topics such as how to use Git, creating citation files, licenses, using environment managers and how to draw up an SMP. Please check out our training calendar if you would like to learn more. We also do our best to reach out to researchers and are available to give a presentation on request. We, for instance, participate as DCC in the PhD Intro Days for starting PhDs. On the DCC-website you can find an informative section dedicated to Research Software Management and you can already find some e-learning material here as well. And researchers are of course invited to get in touch with us if they have questions or would like to schedule a meeting!