arxiv: 2604.17506 · v1 · submitted 2026-04-19 · 💻 cs.SE

Recognition: unknown

Technology Research Software: An Often Overlooked Category of Research Software

Wilhelm Hasselbring , Daniel S. Katz , Rob van Nieuwpoort

Authors on Pith no claims yet

Pith reviewed 2026-05-10 05:28 UTC · model grok-4.3

classification 💻 cs.SE

keywords research softwaretechnology research softwareresearch software engineeringtechnology readiness levelssoftware categorizationsoftware rolessoftware maturity

0 comments

The pith

Technology research software is a distinct category of research software that has been overlooked in the research software engineering community.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper defines technology research software as research software developed in the context of technology research. It introduces primary subroles that describe how this software functions in the research process and secondary subroles based on technology readiness levels to gauge maturity. Concrete examples illustrate software that can serve as technology research software or shift to another research software category depending on whether it is used inside or outside research. Recognizing this category addresses its prior neglect and supports more appropriate handling within the research software engineering community.

Core claim

Technology research software covers research software developed in technology research. Its primary subroles describe its specific functions in the research process. Technology readiness levels provide secondary subroles by estimating the maturity of these software systems. Concrete examples show software taking on this role alongside others based on context.

What carries the argument

Role-based categorization of research software with technology research software as a primary role category, further divided into subroles using technology readiness levels.

Load-bearing premise

That explicitly naming and subdividing technology research software will produce meaningful improvements in recognition, support, or practice within the research software engineering community.

What would settle it

Continued uniform treatment of all research software without separate acknowledgment of technology research software in community guidelines, funding, or development practices after this categorization is published.

read the original abstract

Research software has been categorized for various goals. One fundamental dimension of such categorizations is the role that the software plays in the research process. Recently, a new role category has emerged: technology research software, which covers research software developed in technology research. Until now, this category of technology research software has often been overlooked and neglected within the research software engineering community. In this article, we explain technology research software and its primary subroles. Technology readiness levels are an established method of estimating the maturity of technologies, including software systems. For technology research software, these readiness levels define secondary subroles. To illustrate the concept of technology research software and to make it more tangible, we present examples of research software that, depending on its specific use within or outside of research, take on the role of technology research software as well as that of another research software category.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

The paper clarifies 'technology research software' as a distinct role using technology readiness levels for subroles and dual-use examples, but its claim that the category has been overlooked rests on assertion rather than a literature check.

read the letter

This paper mainly clarifies technology research software as software developed in technology research projects, splits its subroles by technology readiness levels, and shows cases where the same code can serve as technology research software or another category depending on whether it's used inside or outside research. The examples make the distinction practical and easy to picture, which is the most useful part of the work. They ground the idea without needing new data or formal proofs. The motivation section states that this category has often been overlooked and neglected in the research software engineering community. That claim is not supported by any review of prior papers, conference proceedings, or citation counts, so it functions as an opinion rather than a demonstrated gap. The rest of the paper stays definitional and illustrative rather than testing whether naming the category would change funding, recognition, or practice. Readers already working on research software categorization or policy will find the TRL mapping and dual-role cases worth a quick look. It is not a major advance, but the core proposal is coherent and stays within existing concepts. A serious referee could usefully ask for evidence on the neglect claim and check whether the examples cover enough variety. I would send it to review rather than desk reject.

Referee Report

1 major / 2 minor

Summary. The paper proposes 'technology research software' as a distinct role-based category of research software developed within technology research projects. It defines primary subroles for this category and applies technology readiness levels (TRLs) to specify secondary subroles according to technological maturity. The manuscript illustrates the concept with examples of software that can simultaneously occupy the technology research software role and another research software category, depending on whether its use occurs inside or outside a research context.

Significance. If adopted, the categorization could help the RSE community better recognize and support software whose primary purpose is advancing technology research, potentially improving resource allocation and career recognition for developers in this space. The manuscript earns credit for grounding the secondary subroles in the established TRL framework and for supplying concrete dual-role examples that make the abstract distinction tangible.

major comments (1)

[Abstract and Introduction] Abstract and opening paragraphs: the claim that technology research software 'has often been overlooked and neglected within the research software engineering community' is asserted without supporting evidence such as a review of prior role-based categorizations, citation counts from RSE journals or conference proceedings, or a gap analysis. Because this premise supplies the motivation for introducing the new category, its lack of substantiation is load-bearing for the paper's positioning and should be addressed by either adding a brief related-work section or softening the language to 'has received less explicit attention.'

minor comments (2)

[Subroles and TRL discussion] The distinction between primary subroles (tied to the technology-research context) and secondary subroles (derived from TRLs) is conceptually useful but would be clearer if a short table or diagram mapped the two layers for a single example.
[TRL section] A reference to the original NASA or EU TRL definitions and any existing adaptations of TRLs to software would help readers assess the appropriateness of the secondary-subrole mapping.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for their constructive feedback and positive evaluation of the manuscript's potential impact. We address the single major comment below.

read point-by-point responses

Referee: [Abstract and Introduction] Abstract and opening paragraphs: the claim that technology research software 'has often been overlooked and neglected within the research software engineering community' is asserted without supporting evidence such as a review of prior role-based categorizations, citation counts from RSE journals or conference proceedings, or a gap analysis. Because this premise supplies the motivation for introducing the new category, its lack of substantiation is load-bearing for the paper's positioning and should be addressed by either adding a brief related-work section or softening the language to 'has received less explicit attention.'

Authors: We agree that the original wording asserts the category 'has often been overlooked and neglected' without citations to prior role-based categorizations, citation counts, or an explicit gap analysis. This phrasing was based on the authors' observation that existing RSE literature on role categories does not isolate technology research software, but we recognize it lacks formal substantiation in the manuscript. To address the concern directly, we will revise the abstract and introduction to state that the category 'has received less explicit attention' within the research software engineering community. This softening preserves the motivation for defining the category and its subroles while remaining accurate to the evidence presented. We do not intend to add a related-work section, as the paper's scope is to introduce and illustrate the new category rather than conduct a full survey of prior classifications. revision: yes

Circularity Check

0 steps flagged

No circularity: definitional categorization with independent examples

full rationale

The manuscript proposes a role-based category (technology research software) and its subroles via technology readiness levels, supported by concrete examples of dual-role software. No equations, fitted parameters, predictions, or derivations appear. The premise that the category has been overlooked is stated as motivation rather than derived from any self-referential construction or self-citation chain. The contribution remains self-contained as an organizational proposal without reducing any claim to its own inputs by definition.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the domain assumption that role-based categorization is a useful fundamental dimension and introduces the entity of technology research software without independent empirical validation beyond illustrative examples.

axioms (1)

domain assumption Research software can be usefully categorized by the role it plays in the research process.
Presented as one fundamental dimension of existing categorizations.

invented entities (1)

technology research software no independent evidence
purpose: Category covering research software developed in technology research, with secondary subroles from technology readiness levels.
Described as an emerged but overlooked category illustrated through examples of dual-role software.

pith-pipeline@v0.9.0 · 5445 in / 1077 out tokens · 42043 ms · 2026-05-10T05:28:55.850514+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

13 extracted references · 10 canonical work pages

[1]

Multidimensional research software categorization,

W. Hasselbring, S. Druskat, J. Bernoth, P . Betker, M. Felderer, S. Ferenz, B. Hermann, A.-L. Lamprecht, J. Linxweiler, A. Prat, B. Rumpe, K. Schoening-Stierand, and S. Y ang, “Multidimensional research software categorization,” Computing in Science & Engineering, vol. 27, no. 2, pp. 59–68, 2025. doi: 10.1109/mcse.2025.3555023

work page doi:10.1109/mcse.2025.3555023 2025
[2]

H. A. Simon,The sciences of the artificial, 3rd ed. The MIT Press, 1996

1996
[3]

Digitaliza- tion of the natural sciences: Design science re- search and computational science,

V. C. Storey and R. L. Baskerville, “Digitaliza- tion of the natural sciences: Design science re- search and computational science,”Decision Sup- port Systems, vol. 189, p. 114368, Feb. 2025. doi: 10.1016/j.dss.2024.114368

work page doi:10.1016/j.dss.2024.114368 2025
[4]

Defining the roles of research software (Version 2),

R. V. van Nieuwpoort and D. S. Katz, “Defining the roles of research software (Version 2),”Upstream, Jul. 2024. doi: 10.54900/xdh2x-kj281

work page doi:10.54900/xdh2x-kj281 2024
[5]

The use of technology readiness levels for software development,

J. Niemela and M. Fisher, “The use of technology readiness levels for software development,”ARMY AL&T Magazine, pp. 10–14, May – June 2004. [Online]. Available: https://asc.army.mil/web/magaz ine/alt-magazine-archive/#04

2004
[6]

The Kieker Observability Frame- work Version 2,

S. Y ang, D. G. Reichelt, R. Jung, M. Hansson, and W. Hasselbring, “The Kieker Observability Frame- work Version 2,” inICPE ’25 Companion, 2025, pp. 11–15. doi: 10.1145/3680256.3721972

work page doi:10.1145/3680256.3721972 2025
[7]

Kieker: A moni- toring framework for software engineering research,

W. Hasselbring and A. van Hoorn, “Kieker: A moni- toring framework for software engineering research,” Software Impacts, vol. 5, p. 100019, Aug. 2020. doi: 10.1016/j.simpa.2020.100019

work page doi:10.1016/j.simpa.2020.100019 2020
[8]

Peißker, M

M. Mesarcik, A. J. Boonstra, M. Iacobelli, E. Ranguelova, C. T. A. M. d. Laat, and R. V. v. Nieuwpoort, “The ROAD to discovery: Machine- learning-driven anomaly detection in radio astronomy spectrograms,”Astronomy & Astrophysics, vol. 680, p. A74, Dec. 2023. doi: 10.1051/0004- 6361/202347182

work page doi:10.1051/0004- 2023
[9]

ARCHES PiCar-X: Software for Digital Twin Research,

A. Barbie and W. Hasselbring, “ARCHES PiCar-X: Software for Digital Twin Research,”Journal of Open Source Software, vol. 9, no. 102, Oct. 2024. doi: 10.21105/joss.07179

work page doi:10.21105/joss.07179 2024
[10]

Devel- oping an Underwater Network of Ocean Obser- vation Systems with Digital Twin Prototypes – A Field Report from the Baltic Sea,

A. Barbie, N. Pech, W. Hasselbring, S. Flögel, F . Wenzhöfer, M. Walter, E. Shchekinova, M. Busse, M. Türk, M. Hofbauer, and S. Sommer, “Devel- oping an Underwater Network of Ocean Obser- vation Systems with Digital Twin Prototypes – A Field Report from the Baltic Sea,”IEEE Internet Computing, vol. 26, no. 3, pp. 33–42, 2022. doi: 10.1109/mic.2021.3065245

work page doi:10.1109/mic.2021.3065245 2022
[11]

GI- und DE- RSE Muster-Leitlinie zur effizienten Entwicklung von Forschungssoftware,

A. Czerniak, A. Ehrenhofer, B. Fritzsch, M. Funk, F . Goth, R. Hähnle, C. Haupt, M. Konersmann, J. Linxweiler, F . Löffler, A. Lüpges, B. Rumpe, I. Schieferdecker, T. Schlauch, R. Speck, A. Struck, J. P . Thiele, M. Tichy, and I. Ulusoy, “GI- und DE- RSE Muster-Leitlinie zur effizienten Entwicklung von Forschungssoftware,”Gesellschaft für Informatik e.V.,
[12]

doi: 10.18420/2025-GI_DE-RSE

work page doi:10.18420/2025-gi_de-rse 2025
[13]

Investigat- ing research software engineering: Toward RSE Re- search,

M. Felderer, M. Goedicke, L. Grunske, W. Hassel- bring, A.-L. Lamprecht, and B. Rumpe, “Investigat- ing research software engineering: Toward RSE Re- search,”Communications of the ACM, vol. 68, no. 2, Feb. 2025. doi: 10.1145/3685265 6 Technology Research Software 2026 Research Software Engineering Department Wilhelm Hasselbringis a professor of software e...

work page doi:10.1145/3685265 2025