How do you sustain your research software project long-term?
This page provides practical guidance on how you ensure your software project remains maintainable, usable, and supported over time.
Description
Sustaining a research software project means ensuring that your software continues to meet its purpose over time. You must plan for maintenance, support, governance, funding, people, and community needs beyond the initial development phase. Without explicit attention to software project sustainability, research software can become outdated, unsupported, or unusable after the project or grant that created it ends.
Considerations
| Area | Typical issue | Why it matters |
|---|---|---|
| Scope | Sustainability is treated as a separate activity | Creates a disconnect between development, maintenance, and long-term use |
| Funding | Project funding ends before software use ends | Leaves maintenance dependent on future grants, informal effort, or user goodwill |
| Hidden costs | Maintenance work is not budgeted or tracked | Makes the real cost of sustaining software invisible to projects and institutions |
| Governance | Ownership and responsibilities are unclear | Blocks decision-making, accountability, and continuity |
| Roles | Maintenance is not formally assigned | Makes sustainability dependent on individuals rather than planned responsibilities |
| Recognition | Development is valued more than maintenance | Weakens incentives for long-term support, handover, and quality work |
| Community | Users or contributors are expected to maintain software without structure | Creates risk if no governance, onboarding, or support model exists |
| Adoptability | Software is difficult to install, use, or integrate | Reduces reuse and weakens the case for continued investment |
| Planning | No SMP or lifecycle plan exists | Leaves risks, dependencies, staffing, and end-of-life decisions unmanaged |
| Context | Software type and disciplinary setting vary | Requires context-sensitive sustainability strategies rather than one-size-fits-all solutions |
Solutions
Use the following sustainability area and actions to systematically address software project sustainability across its lifecycle.
| Sustainability area | What you need to address | What you should do |
|---|---|---|
| Technical sustainability | Maintainability and software quality | Address technical sustainability through design, architecture, testing, dependency management, and documentation; see the related task page on how to design sustainable and future-proof research software |
| Organisational sustainability | Ownership, governance, and accountability | Define roles and responsibilities; establish decision processes; assign maintenance ownership; make sustainability part of lifecycle management |
| Economic sustainability | Funding continuity and resource allocation | Combine project grants, institutional support, infrastructure funding, partnerships, and community support; avoid relying only on future grants unless this is an explicit strategy |
| Maintenance budgeting | Hidden and long-term maintenance costs | Reserve budget for maintenance during and after the project; document how maintenance work is funded, tracked, and reported |
| Personnel sustainability | Skilled people and formal responsibilities | Allocate staff time for maintenance; include maintenance in job descriptions or work plans; support training, hiring, and career progression for people who develop and maintain the software |
| Community sustainability | Contributions, users, and shared responsibility | Build a contributor base; define contribution guidelines; recognise contributors; establish communication channels; avoid assuming that “the community” will maintain the software without governance |
| Research software ecosystem | Support beyond a single project or institution | Connect with ecosystem-level initiatives such as ReSA, SustainOSS, and ADORE.software to align with broader sustainability practices |
| Adoptability | Usability and workflow integration | Provide documentation, examples, onboarding material, and reproducibility support; align with Documenting software project |
| Resourcing strategy | Access to expertise and capacity | Use internal teams or external expertise to sustain development and maintenance; see the related task page on outsourcing for additional research software expertise |
| Lifecycle management | Evolution, handover, and end-of-life | Define maintenance scope; plan releases and archiving; identify future maintainers; document handover; define an end-of-life strategy; align with Software Lifecycle and Archiving software |
| Sustainability planning | Explicit management of sustainability risks | Use a Software Management Plan to define sustainability goals, funding assumptions, responsibilities, risks, dependencies, and mitigation strategies; see Software Management Planning |
| Impact and recognition | Evidence that the software is worth sustaining | Track meaningful indicators such as reuse, citations, adoption, contributors, users, and community value; use these indicators responsibly and avoid relying only on informal visibility metrics |
| Responsible sustainability | Social, environmental, and equity considerations | Consider environmental impact, social impact, accessibility, diversity, equity, and inclusion when deciding how the software should be sustained |
Further Reading
-
RSMM: A focus area maturity model for research software projects — Provides a structured maturity model for research software projects, including sustainability as a capability with practices such as funding strategies, software management planning, and lifecycle decisions. It helps you assess your current maturity level and prioritise improvements across software project management, research software management, community engagement, and adoptability. It is especially useful if you want to operationalise sustainability in a structured and measurable way.
-
Financing Sustainable Research Software — Reports survey findings on funding, maintenance, roles, time allocation, budgeting, and recognition for research software in the Dutch Natural and Engineering Sciences domain. It shows how maintenance is often under-budgeted, informally assigned, and weakly recognised despite being essential to long-term software sustainability. It is particularly useful if you need evidence for why sustainability planning must include funding, formal responsibilities, and institutional support.
-
Amsterdam Declaration on Funding Research Software Sustainability — Sets out recommendations for funders to support sustainable research software through documentation, reuse, open science policies, ecosystem investment, fit-for-purpose funding instruments, personnel support, recognition, and responsible indicators. It is useful when you need to connect project-level sustainability planning to funder expectations and policy-level change.
-
Research Software Alliance — Coordinates international work to advance the research software ecosystem and improve recognition of research software and the people who develop and maintain it. It is a useful entry point for ecosystem-level initiatives, policy discussions, community coordination, and resources on research software sustainability.
-
SustainOSS — Provides resources and community discussions on sustaining open source software, including governance, funding models, contributor dynamics, and organisational resilience. It complements research software guidance by focusing on how software projects survive economically and organisationally over time.
AI Disclosure
This work was produced with the assistance of GPT-5, under the strict editorial control and factual verification of the human author.
Related pages
tasks
Guidance on making software contributions visible, citable and verifiable, and building the evidence needed for career progression for people who write research code.
tasks
How to prepare a software management plan?
tasks
How to test your software?
tasks
How to write clear and useful software project documentation for end-users and collaborators?
tasks
How can you archive your software for preservation?