In the course of digitalisation, research software has become a central element of scientific work. This includes the development and use of research software for simulation, generation, processing, analysis and visualisation of research data, and for control of research equipment and experiments. The essential importance of research software poses new challenges for good scientific practice with regards to transparency, traceability and reproducibility of research results. These standards are best met through open access to software according to the FAIR principles (Findability, Accessibility, Interoperability, Reusability).

Handreichung zum Umgang mit Forschungssoftware (translated quote)

Matthias Katerbow, Georg Feulner et al., 2018, page 1 (DOI 10.5281/zenodo.1172970)

More information

By archiving and making available software which you have developed yourself, you ensure that the functionality of your software can be verified and reproduced later and by others. The following tips may help you pursue this goal:

  • Archive your self-developed software in a dedicated software repository such as Software Heritage to give everyone access to your source code. To increase the visibility of your research, you can also use code repositories like GitHub or TU Wien's TUgitLab. If you develop workflows, repositories such as my experiment may be right for you.
  • Assign source codes you want to publish with a suitable and free (as possible) license, such as the GNU General Public License (GPL) or the Apache License 2.0. The tool Choose a License can help you choosing an open source license.
  • In addition to the code, provide a detailed description of your experiments and data sets which others can use to test your software. In Jupyter Notebooks, you can create code and describe your experiment in related documentation at the same time.
  • Additionally, help others reproduce your experiment with your specific configuration by providing Docker container. ReproZip is also a helpful tool, since it bundles all relevant files such as data, software, libraries and environmental variables.
  • You should always allocate a persistent identifier to your code (e.g. DOI through the GitHub integration in Zenodo; there will also be a corresponding link between the TUgitLab and the TU data repository in the future). If this is not possible, point out the exact date of change.
  • From the outset, specify in your data management plan which source codes and related information should ultimately be archived, as well as how and where (see example).
  • As a rule, follow the standards of your discipline and create good README files to inform others about your experiment and approach.
  • Adhere to naming and coding conventions of the language used. This improves readability and allows others to easily navigate the structure and process of your project.
  • Follow the FAIR principles when making your software available.

In this experiment (DOI: 10.5281/zenodo.1209833, opens an external URL in a new window), the association between alcohol consumed and UFOs sighted was investigated. The following two sets of data were used for this purpose:

1. Dataset: Alcohol Consumption
OECD (2018), Alcohol consumption (indicator).
DOI: 10.1787/e6895909-en, opens an external URL in a new window
File Location: data/raw/DP_LIVE_22032018202902423.csvFile Size: 112K

2. Dataset: Ufo Sightings
Sigmond Axel. (2014). ufo-reports, opens an external URL in a new window (Version commitc0915f18186e5e2227083702049a838258001a2a) [Data set]. Zenodo
File Location: data/raw/ufo-scrubbed-geocoded-time-standardized.csv
File Size: 13M

The following files should be archived as they are relevant to the reproducibility of the experiment:

  • README.md (text files with instructions for running the experiment)
  • both Jupyer Notebooks (experiment code and its documentation)
  • Dockerfile (Dockerfile, to create a Docker container)
  • requirements.txt (list of Python dependencies needed for the experiment)
  • documentation/architecture.png (diagram of the experiment architecture)
  • documentation/description.txt (text file which describes the correlation diagram)
  • documentation/metadata.xml (relevant metadata for the experiment)

Input data is not included in the archive, as it is already stored in other repositories and easily accessible.

In addition to selve-developed software, already available software is used in research.

These applications must also be documented in order to verify and reproduce research results, as should the following:

  • a detailed description and citation of the software version used and its configuration
  • a description of the parameters chosen and the software and hardware environment in which the software was used

The use of Docker containers, opens an external URL in a new window may also make sense here.

As early as software selection, you should consider potential usage limitations with regard to the reproducibility of your experiments and, if possible, exclude them. For example, consider the following points:

  • In the case of web applications, it is possible that the version you use will no longer be available later.
  • In the case of commercial off-the-shelf software, licensing costs and a dependence on the software provider, are factors which affect you and all other users.