Skip to content

Discussing The Research Software Ecosystem

The project enables discussion and commenting on a text that conceptualises the research software ecosystem.

Text Review

The aim of this discussion is to initiate a wide-ranging debate on the future research software ecosystem in Germany. The frameworks, concepts, and analogies presented here should not be regarded as a single vision that people should align with and advocate for. Rather, we would like them to be understood as an impetus for a discussion that will lead to a more concrete roadmap in the near future. We explicitly invite readers to reflect on the frameworks and ideas provided in the document.

Comment phase active
Post comments on the paragraphs of the text

Habitats and Species - Research Software Infrastructure and Tiers

RS Classification by Maturity

As we clarified in the previous section, the international definition of research software encompasses a wide range of software. This breadth necessitates further distinction of research software into types or categories. Several classifications have been proposed in the past, and an overview along with multiple dimensions for categorisation has been put forward by Hasselbring et al. [2025]. However, for the purpose of this paper, a maturity-based classification intended to clarify the level of responsibility and support required by institutions as well as the community to sustain a piece of software is more suitable, as it also guides the allocation of resources and facilitates decision-making regarding documentation, licensing, long-term stewardship, and ownership.

Three Tier Classification of RS

Therefore, we categorise research software into three tiers based on scope, potential for reuse, and social dependencies following the model introduced by the Australian Research Data Commons (ARDC) [Australian Research Data Commons, 2022] and adopted by the EVERSE project (https://everse.software/RSQKit/three_tier_view, last access 2026-03-10), which is also closely related to the application classes used by the DLR [Schlauch et al., 2018]. However, we are adapting the naming of the three tiers for reasons detailed further below. This categorisation should not be understood as a hierarchy of quality, but rather as a pragmatic framework designed to facilitate communication and collaboration across institutions and research communities. The tiers are also not mutually exclusive, meaning 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 dependencies by other researchers or projects.
  • Tier 2 includes software that is reused 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.

Based on these descriptions, we propose the following terms for these tiers:

  • Tier 1 - Personal or Project Software
  • Tier 2 - Community or Shared Software
  • Tier 3 - Critical / Foundational Software

We have split up the description and the terms because we see a potential for confusion with the widely used term "infrastructure": The third tier is referred to as "research software infrastructure" by ARDC and EVERSE. The common understanding of tier 3 describes software with a central role in the ecosystem, with broad adoption, critical in multiple research areas, and such with high social dependencies. The emphasis is on the software artefact itself and its structural importance.

Definition RS Infrastructure

On the other hand, in our opinion, "research software infrastructure" should be understood differently than tier 3 software. We define research software infrastructure as the shared technical and socio-organisational services and resources that enable the sustainable development, deployment, use, sharing, and maintenance of research software. These resources may include infrastructure software, such as code repositories, computing platforms, continuous integration systems, as well as licensing frameworks, and governance models. Though, 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 for development and long-term operation. A piece of tier 1/2/3 software lives within research software infrastructure, within the repositories, CI systems, and governance structures that host and sustain it. To stay within the analogy: Research software infrastructure is the habitat, and the software tiers are the different species.

adhocracy+ is funded by donations.
Donate now
Donate now to adhocracy+