Frequently Asked Questions (FAQ)

Core Concepts

What is research software?

Research software is software created during the research process or for a specific research purpose. It encompasses source code, scripts, computational workflows, executables and related artefacts. It is used to collect, analyse, simulate, process, visualise or manage research data, including text, images, audio, sensor data and other digital resources, and to generate scientific models, control research instruments or optimise research procedures.

This definition encompasses a wide range of software projects, from a few lines of code to large research platforms. Research software often includes aspects that play a role in its development, such as technical documentation, user manuals, metadata, parameterisation, management plans, and digital notebooks.

References:
[1] Gruenpeter, M., Katz, D. S., Lamprecht, A.-L., et al. (2021): Defining Research Software: a controversial discussion. Zenodo. https://doi.org/10.5281/zenodo.5504016
[2] Deutsche Forschungsgemeinschaft (2024): Umgang mit Forschungssoftware im Förderhandeln der DFG. Zenodo. https://doi.org/10.5281/zenodo.13919790

What functions does research software serve?

Research software has three interconnected functions:

It provides use functions by acting as a means for research tasks such as data analysis, simulation and modelling, instrument control, and workflow management.
It delivers archive functions by preserving the intellectual work behind research and ensuring that it is findable, accessible, interoperable and reusable (FAIR), and thus reproducible.
It enables community functions by fostering collaboration, learning or training, advancing research through iterative development, and building reputation.

What do we mean by “research software ecosystem”?

Research software ecosystem refers to the dynamic, complex, interconnected and interdependent network of people, communities, institutions, software, infrastructure, practices and activities, as well as policies and resources that collectively support the sustainable development, deployment, use, sharing and maintenance of research software.

What is research software infrastructure?

Research software infrastructure comprises the shared technical and organisational services and resources that enable the sustainable development, deployment, use, sharing and maintenance of research software. These resources can include code repositories, computing platforms, continuous integration systems, licensing frameworks and governance models. Rather than being a single digital artefact or service, research software infrastructure is a structural element for which research institutions and individuals share responsibility and ownership of development and long-term operation.

What do we mean by “governance” in the research software ecosystem?

Governance refers to the collective processes, structures and practices through which research institutions can develop a shared vision and sense of accountability for the sustainable development, deployment, use, sharing and maintenance of research software. Rather than involving top-down control or enforcement, governance enables, coordinates and empowers institutions to manage research software responsibly as a critical part of their research outputs. Importantly, governance is not about regulating individual software projects; rather, it is about fostering an environment in which research software can flourish through trust, transparency, shared ownership, and institutional commitment.

What is a “service”, an “offering”, an “activity”, and a “resource”?

A service is an intangible asset: a task performed at the client’s request to deliver added value and help them achieve their goals, without requiring them to own or execute the task themselves.
An offering is a specific package of services provided to meet the needs of customers or markets. It comprises a combination of services, processes, tools and values that together generate a uniform benefit.
An activity is a purpose-driven effort or initiative undertaken within a network or organisation to achieve strategic objectives. Unlike formal offerings, activities tend to be collaborative and process-oriented, focusing on building capacity.
A resource is a tangible or digital material that has been developed or curated to support understanding, implementation, or decision-making, including guidelines, templates, and standards.

What is a “service catalogue”, and a “service portfolio”?

A service catalogue is a curated, publicly accessible inventory of all the services, offerings, resources and support activities provided by an institution or collaborative network. It serves as a central point of discovery for researchers, developers and support staff seeking to engage with the available capabilities.
The service portfolio refers to the broader strategic set of services that an institution commits to offering over time. This includes current offerings, as well as planned or aspirational services.

Research Software Distinctions

Why distinguish between software tiers?

We categorise research software into three tiers based on scope, reuse potential, and social dependencies rather than technical complexity or lines of code. This categorisation is not a hierarchy of quality, but a pragmatic framework to facilitate communication and support across institutions and research communities.

The rationale of this distinction is to clarify the level of institutional and community responsibility and support needs required to sustain a piece of software, to guide the allocation of resources, and to facilitate decision-making regarding documentation, licensing, and long-term stewardship and ownership.

What tiers of research software do we distinguish?

We distinguish research software into three tiers based on scope, reuse potential, and social dependencies. The tiers are not mutually exclusive, which means that software can evolve from tier 1 to tier 2 to tier 3 over time depending on its adoption and use within the research community.

Tier 1 refers to software that is developed primarily for personal use or an individual project, with limited external adoption and minimal dependency on other researchers or projects.
Tier 2 includes software designed for reuse across multiple research initiatives, indicating growing community interest and reliance.
Tier 3 encompasses software that has become a shared resource relied upon by multiple institutions or disciplines. This software requires sustained investment, governance and community stewardship.

References:
[1] Hasselbring, W., Druskat, S., Bernoth, J. et al. (2025): Multidimensional Research Software Categorization. Computing in Science & Engineering, no. 2, vol. 27. https://doi.org/10.1109/MCSE.2025.3555023
[2] RSQKit Community (2026): Three-Tier Model of Research Software. Website. URL: https://everse.software/RSQKit/three_tier_view (last access: 2026-01-22)

Footnote: It may be helpful to consider the analogy of physical laboratory experiments, in which three tiers can also be distinguished:

Tier 1: a small laboratory experiment designed specifically for a research group, primarily serving as a proof-of-concept facility.
Tier 2: a medium-sized installation (e.g. a building designed for a specific purpose) used by one institution or research project for a particular research context.
Tier 3: a large-scale research facility used by an entire community, where the hosting entity provides most of the research time to external users.

People in the Research Software Ecosystem

What is a Research Software Engineer?

We use the term “Research Software Engineer” (RSE) as a label rather than a job title or identity description. In essence, RSEs combine expertise in software development and methodology with knowledge of one or more specific research domains. Depending on their roles in the ecosystem, the RSE label can be fulfilled by individuals from either the academic or research support staff. Often, individuals self-identify as an RSE; however, we also explicitly include other labels or job titles, such as “computational scientist”, “researcher who codes”, “software engineer in a research environment”, etc. What unites these individuals is their commitment to supporting the sustainable development, deployment, use, sharing and maintenance of research software.

References:
[1] Netherlands eScience Center (2023): What is a Research Software Engineer? A definition by the Netherlands eScience Center. Zenodo. https://doi.org/10.5281/zenodo.7994286

What roles exist for individuals in the research software ecosystem?

Individuals can take on a variety of specialised roles that support the sustainable development, deployment, use, sharing and maintenance of research software. These roles reflect the many ways in which individuals contribute to the research software ecosystem.

Developers design and develop research software, collaborate with groups on software development, and provide long-term software development capacity for comprehensive research software engineering projects lasting more than three months.
Maintainers take on the long-term maintenance of research software at the institution, assessing software quality, and analysing software needs and performance.
Administrators manage research software infrastructure by hosting pilot instances of new services, integrating them into software stacks, providing local instances of established infrastructures like GitLab, and collaborating with central IT, scientific library, research data management, and high-performance computing departments.
Researcher roles involve conducting general research in the field of research software engineering and participating in the development of standards.
Modellers design, implement, and validate computational models that underpin research simulations, integrating domain-specific knowledge with robust software engineering practices.
Users use research software to conduct their work, provide feedback, influence software design through use cases, and drive demand for functional updates, documentation, and usability.
Educators teach research software practices, develop and adapt training materials, provide self-study resources, deliver regular general training sessions, and contribute to institutional study programmes.
Community Managers represent a specific research software community by organizing talks, seminars, workshops, and hackathons, offering online exchange channels, and managing onboarding and offboarding for new and departing RSEs at institutions.
Consultants advise on aspects of research software development, including software licensing and publication, offer long-term mentoring, assist with the creation of software management plans, collaborate with funding and technology transfer offices, and manage resource planning for research software projects.
Advocates promote the value and impact of research software, act as a link between local institutions and broader communities, shape public and institutional narratives by presenting at events, contributing to policy discussions and position papers, and participating in public outreach initiatives.
Group Leads provide strategic direction and coordination for a team of RSEs, managing workloads, fostering collaboration, supporting professional development, and ensuring alignment with institutional goals and research priorities.

What are research software guilds?

A research software guild is a structured grouping of Research Software Engineers (RSEs), hypothesis-driven domain researchers and/or support professionals, who come together to provide coordinated support for the sustainable development, deployment, use, sharing and maintenance of research software within a research institution or across multiple institutions. In practice, a single institution may host multiple guilds, such as:

dedicated research software departments or centres
embedded research software teams within research institutes
distributed networks of RSEs across different units
Open Source Program Offices (OSPOs)
semi-stable working groups
time-limited project-based initiatives
virtual, cross-institutional collectives

Guilds may focus on different roles in the research software ecosystem, such as software development, infrastructure administration, training, community management or advocacy. The defining features of a research software guild is its shared mission to strengthen a specific research software or research software in general as a core research asset.

References:
[1] Kempf, D., Caspart, R., Flemisch, B. et al. (2025): Establishing central research software engineering units in german research institutions. Position paper 4. https://de-rse.org/2023_paper-RSE-groups/paper.pdf