Research software fulfils important functions within digital research practice: it enables research and data utilisation as well as the reproducibility of scientific results. Publishing the source code of research software also ensures the visibility and availability of creative and scientific development. In this way, research software creates important impulses for advancing research and for strengthening scientific collaborations and networks. Against the background of the diverse possibilities in which research software can be used and developed in all areas of science and the growing need for funding in the areas of development, archiving, findability and reuse of research software, the DFG draws on these principles to point out key aspects that should be reflected upon and considered when planning research projects.

In principle, the use and (further) development of research software follows the DFG Guidelines for Safeguarding Good Research Practice and the DFG’s ethical, legal, ecological and structural standards. These must be taken into consideration in the (further) development of research software beyond the actual research tasks, for example in the responsible use of natural resources with regard to the utilisation of computing power and instrumentation procurement (further information: Sustainability Guide for Research Processes in the DFG context). In addition, when assembling project teams and establishing communities, measures can be taken and processes established that promote gender equality, create a diverse working environment and enable inclusion, e. g. with regard to inclusive community management or the composition of development teams (further information: Equity and Diversity in the DFG context). 

The following guiding principles additionally define key aspects that should be taken into consideration in the (further) development of research software as notes and guidelines in the research process. They are based on the observation that the (further) development of research software is subject to a trade-off between the diversity of use cases and research objectives on the one hand and standardisation in the software development process on the other. In particular, the orientation towards common, interdisciplinary standards in the (further) development of research software therefore enables the co-operative applicability and sustainable usability of research software. Accordingly, application of the guiding principles in practice should also be geared to the individual state or orientation of a research software.

(1) Software development and standards

The development and application of research software should follow best practice standards for software development. In the development process, these software development standards depend on the purpose of the software (e. g. simulation, control of instrumentation, data analysis, etc.). It is therefore an essential element of project planning to define all steps of software development in advance in accordance with disciplinary standards, e. g. for use cases, authorship, versioning, licensing, reuse, security, etc. Clear evaluation and development criteria should be defined in order to enable an agile development process.

(2) Software quality

Appropriate research software quality is an important basis for the development and use of research software in practice. In addition to general software quality criteria in the field of software engineering, the quality of research software should be defined on the basis of discipline-specific criteria. In addition to the FAIR4RS Principles tailored to research software, there are also frameworks from the field of software engineering that allow a description of the quality of (research) software (test coverage criteria, analytical quality assurance, interface and tutorial documentation). Quality standards for research software should therefore refer to these broader frameworks. Preference should be given to those frameworks that potentially allow development services to be appropriately rewarded.

(3) Accessibility and documentation

As the use and development of research software is part of the research process, accessibility and documentation should ensure the traceability of research results in the methodological sense. Making research software accessible is an important quality assurance element of the research process, as research methods can then be retraced and the verification of findings can be guaranteed. Source code, workflows and the functionality of research software should therefore be documented in a comprehensible manner and made available in order to ensure verifiability and reproducibility in the research process.

(4) Citability and reusability

In addition to its pursuit in the research process itself, the development of research software should enable utilisation in other research projects. Research projects should examine the extent to which (a) existing research software can be reused, (b) this software can be further developed and improved, or (c) the development of new software is necessary which is then made available to the research community for further use. When reusing existing research software, the rights of use should be checked (usually via the licence). In order to ensure the successful reuse of research software that is to be (further) developed in-house, care should be taken to ensure the greatest possible machine findability and openness of the licence for scientific use. 

(5) Software sustainability

The sustainability of research software should not only be ensured through its accessibility but also through plans for maintenance, further development, findability and interoperability. In order to ensure the long-term usability of research software, infrastructures and existing repositories should be used to secure research software in the long term, but structures should also be established to enable the active participation of the user and development community. In some cases, the creation of sunsetting concepts at the end of the development process can also be useful in order to transfer results to subsequent research software projects, e. g. individual software modules or active communities.