Project Results: Financing Sustainable Research Software

Financing Sustainable Research Software TDCC-NES Bottleneck Project Burcu Beygu Koopmans National Research SoftwareDay 25 November 2025 Outline ●Project ○Background ●Survey ○Data Collection ○Structure & Question Categories ●Results ●Conclusions ●Advice ●Future ○Audience input | 2 Thanks to: Joanne Yeomans Lena Karvovskaya Errol Neo Mira Stanic Jacquelijn Ringersma TDCCNES community managers and community coordinators | 3 Financing Sustainable Research Software Burcu Beygu Koopmans, RUG Rolf Hut, TU Delft Jurgen Vinju, CWI Rees Williams, RUG Koen Vree Egberts, RUG Rieke Lahrsen, RUG Project Members & Contributors | 4 Reinder Radersma, CWI,NWO Sekan Girgin , University of Twente Carlos Martinez Ortiz, eScience Center Gijs Verdoes Kleijn, RUG Financing Sustainable Research Software Duration : January 2024 to April 2025 Work Packages: 1) Domain Analysis and Methodology 2) Data Collection and Analysis 3) Results and Advice 4) Dissemination Project output: https://zenodo.org/records/15079243 Project | 5 Background 1. Community building and establishing online presence 2. Creating a Training Hub 3. Facilitating long-term software preservation and sustainability 4. Increasing interoperability and integrating tools and workflows for FAIR *TDCC-NES Roadmap v1.0 TDCC-NES Bottleneck Projects - Roadmap v1.0 * | 6 Background Facilitating long-term software preservation and sustainability Training Financial aspects TDCC-NES Bottleneck Projects - Roadmap v1.0 | 7 Background Facilitating long-term software preservation and sustainability Software is developed and maintained by humans Financial aspect TDCC-NES Bottleneck Projects - Roadmap v1.0 | 8 Motivation ●Developing research software is a fundamental aspect of research in the NES domain. Such software ranges from tools developed during PhD projects, to infrastructure services that support novel data processing pipelines, to software used in experimental setups for instrument control and data collection. ●These tools often play a critical role in advancing scientific discovery and can have long-term impact well beyond the lifespan of the original project. ●Despite their importance, however, research software frequently faces sustainability challenges, especially once project funding ends. ● Sustaining research software requires continuous human effort and dedicated financial resources | 9 Survey Structure ●The survey consisted of 27 substantive questions in a variety of formats, including multiple-choice (with some allowing multiple selections), free-text responses, rating scales, and percentage-based distributions . ●Participants could choose more than one option where applicable and were also able to provide their own answers in free-text form. If none of the listed options fit their situation, they could use the Other option to write a custom response. ●Conditional branching logic was used to tailor the questionnaire based on respondents' answers (e.g., only those involved in funded projects were shown financial-related questions), ensuring relevance and reducing survey fatigue. | 16 Survey Structure ●As a result, not all participants will answer every question. ●Certain questions are only seen by participants based on previous responses. ●Funding-related questions are only shown to those working on funded projects. ●The survey may end early for some participants based on their responses.For example, participants who indicated no involvement in research software were automatically redirected to the end of the survey. | 17 Survey Structure ●As a result, not all 197 participants answered all 27 questions. ●Each response was anonymized, with a unique RecordID assigned to allow consistent linking across questions for each participant. ●No personal data—such as names, addresses, email addresses, or the names of participants’ organizations—was collected. At the beginning of the survey, participants were asked to give informed consent before proceeding. | 18 Thematic Grouping of Survey Questions Based on the intent and the context, survey questions are grouped into 6 categories | 19 Conclusions drawn from each question categories | 20 Results Participants profiles & rolesType of institutes | 21 Results Participants profiles & roles - Research field | 22 Results Participants profiles & roles - Job titles | 23 Results Participants profiles & roles - Job titles | 24 Instrument Scientist”, “Programme Manager”, “Department Head”,“Group Leader”, “Senior Research Software Engineer”, “Data Steward”, “Lecturer”, “Product Owner”, and “Head of Technical Operations Results Participants profiles & roles - Roles and time spent on activity | 25 Average percentage of work time by activity Results Project & funding awareness - If the research know how the project is funded | 32 Conclusions ●Software development is mostly embedded in funded research projects, but many respondents are unaware of how this funding is structured. ●Maintenance is often not taken into account. ●Funding sources are diverse, often described as “patchwork,” and lack consistent categories. ●A portion of respondents report no funding at all or contribute in their spare time. ●Grants named suggest dependence on NWO, EU, and eScience Center, but transparency and clarity are lacking. Project & funding awareness | 33 Results | 34 Budget allocation & financial sustainability - Budget for maintenance during the project Results | 35 Budget allocation & financial sustainabilityBudget for maintenance after the project Results | 36 Budget allocation & financial sustainabilityIf there is budget dedicated for maintenance in the institution Conclusions ●Maintenance is rarely budgeted for—either during or after the project ends. ●Only a minority of respondents report having specific maintenance budgets, and even fewer indicate organizational-level funding. ●When funds are available, they are mostly used to reassign existing personnel rather than hiring new staff. ●Participants often do not know why maintenance is unfunded, reflecting both structural and communication issues. This finding reinforces the hidden nature of maintenance costs and the vulnerability of software after the end of a project. Budget allocation & financial sustainability | 37 Results Human resources and maintenance responsibilities - If maintenance is part of participants’ formal job descriptions | 38 Results Human resources and maintenance responsibilities - Career stages of individuals responsible for software maintenance | 39 Results Human resources and maintenance responsibilities - Contracted time allocated to software maintenance | 40 Conclusions ●Only a few participants report that software maintenance is explicitly part of job descriptions. ●The task often falls to PhD students, postdocs, or anyone available, rather than being formally assigned. ●Contractual time allocated to maintenance is minimal or unknown, yet actual time spent can be significant indicating a disconnect between practice and formal planning. ●Maintenance is performed, but informally and without structural safeguards, suggesting a reliance on goodwill and individual dedication. Human resources and maintenance responsibilities | 41 Final reflection from participants Respondents highlighted a lack of institutional recognition for software work. Maintenance activities were often seen as undervalued compared to publications, and some felt that time spent on software even harmed their academic standing. These concerns were raised by individuals across roles — from PhDs to software engineers. | 48 Final reflection from participants Participants pointed out diverse situations not captured by the survey and broader structural barriers. Several noted unique roles (e.g., freelancers, non-academic positions) or one-off software projects that do not fit standard assumptions. Others mentioned technical challenges, missing infrastructure, or risks tied to proprietary platforms. Despite frustrations, some respondents expressed appreciation for the survey and offered concrete suggestions for clearer roles, better handover processes, and improved support structures | 49 Final reflection ●Results point to organizational invisibility of development and maintenance of research software. ●The maintenance of software is widespread and time-consuming yet remains structurally unsupported. ●Recognition and funding are inconsistent, often relying on individual initiative and ad hoc arrangements. | 50 Advice ●To bridge this gap, both research organizations and funders must integrate research software development and maintenance into career systems, budgeting processes, and infrastructure planning. ●Sustainability strategies must account for disciplinary norms, institutional structures, and informal practices, which vary significantly across the NES domain. | 51 Advice ●Field-specific results reveal that these structural differences are not evenly distributed. ●In Astronomy & Astrophysics, participants reported relatively high levels of formal recognition and time allocation for maintenance tasks, alongside high actual time spent. ●In contrast, fields such as Computer Science and Engineering showed little to no formal assignment or contract time, despite ongoing maintenance work. ●These patterns suggest that any effective policy or funding response must be sensitive not only to the technical nature of research software, but also to the disciplinary culture and institutional incentives that shape how maintenance is assigned, resourced, and recognized. | 52 Future ●Given the findings; ○What do you think could be a follow effort? ○What do you think financial model can be improved such that research software development and maintenance tasks could be financed and managed more easily? ○What would you suggest as solutions to financial managers, funding agencies, deans and directors? | 53