Funding the maintenance of research software
Research software is easy to fund once and hard to fund forever. This guide explains why maintenance falls through the gaps and walks through the realistic ways to pay for it, from grant budgets to community donations.
- Most research funding rewards new results, so the ongoing work of fixing, updating and supporting software rarely has a natural budget.
- No single source covers maintenance well. Sustainable projects usually combine grant line items, institutional support and community money.
- Fiscal sponsors and donation platforms let a project receive money without becoming a legal entity, which makes community funding practical.
A research tool gets written for a project. It works, the paper comes out, and other groups start using it. Then the requests arrive. A dependency changes and the install breaks. Someone finds a bug that affects results. A new operating system release needs testing. The original grant has ended, the developer has moved on, and nobody is paid to do any of this.
This pattern is common enough that most researchers will recognise it. It is not a failure of the people involved. It is a gap in how research is funded. This post explains where that gap comes from and the main ways projects fill it today.
Why is maintenance so often unfunded?
Because research funding is built around novelty, and maintenance is not novel. Grant proposals are judged on new questions and new methods. Keeping an existing tool working is necessary, but it rarely sounds like research, so it is hard to write a competitive proposal around it.
There are other reasons too:
- Short grant cycles. Projects last a few years. Software that is useful can last decades.
- Invisible users. Many people use a tool without citing it, so its impact is underreported and hard to show to a funder.
- Career incentives. Papers count for promotion. Releases, bug fixes and user support usually do not.
- Shared benefit, no owner. A package used by hundreds of groups helps all of them, but no single group feels responsible for paying for it.
The result is that maintenance often happens in evenings and weekends, or not at all. That puts the research built on the software at risk. Our post on common errors in research code shows how quietly broken code can affect results.
What does maintenance actually cost?
People time, mostly. Servers and services are usually cheap in comparison. Maintenance includes fixing bugs, reviewing contributions, updating dependencies, keeping tests and continuous integration running, writing documentation, answering users, making releases and handling security reports.
A useful way to plan is to estimate a fraction of a person rather than a set of tasks. Even a small, stable tool tends to need some regular attention every month. A widely used library needs far more. Write down what you actually spend for a few months and use that as the basis for any request. Funders respond better to a specific, honest estimate than to a vague one.
Can you put maintenance into a normal research grant?
Yes, and this is the most accessible option for most researchers. Many funders allow software development and maintenance as an eligible cost when it supports the proposed research. The trick is to make it explicit rather than hoping it fits under general staff time.
In practice that means:
- Name the software the project depends on, including your own tools.
- Describe the maintenance work it needs during the grant, with an effort estimate.
- Include it in a software management plan if the funder asks for one, or attach one anyway.
- Budget for research software engineer time as a named role. Our guide to research software engineers explains how these roles usually work.
This does not solve long term sustainability, because the money still ends with the grant. But a chain of grants that each include a maintenance line can keep a tool healthy for many years.
Are there programmes dedicated to research software?
Yes. Over the past several years a number of funders have started programmes aimed specifically at research and open source software, including maintenance rather than only new features.
Well-known examples include the Chan Zuckerberg Initiative's Essential Open Source Software for Science programme, which has supported maintenance of widely used scientific packages. The Alfred P. Sloan Foundation has funded work on open source tools and the sustainability of research software. In the United States, the National Science Foundation runs the Pathways to Enable Open-Source Ecosystems programme, known as POSE. In Germany, the Sovereign Tech Fund, now part of the Sovereign Tech Agency, invests in open source infrastructure that many projects depend on. Some national research councils also run software-focused calls or fellowships for research software engineers.
Calls open and close, and eligibility rules change, so check each funder's current pages before planning around them. The Research Software Alliance brings funders and the research software community together and is a good place to follow developments in this area.
How do institutional RSE groups help?
They provide continuity that individual grants cannot. A central RSE group is funded, at least partly, by the institution itself. Its staff stay when a project ends, which means knowledge about a tool does not leave with a fixed-term contractor.
Some groups offer a small amount of free time to projects, often for maintenance or for making code ready to publish. Others work on a cost recovery basis, where projects buy days from the group using grant money. Either way, the institution carries some of the risk. If your institution has such a group, ask whether it can adopt a tool that has become important to several labs. If it does not, the case for creating one is often built on exactly these orphaned projects.
What is a fiscal sponsor, and why would a project need one?
A fiscal sponsor is a nonprofit organisation that receives and manages money on behalf of a project that is not its own legal entity. Most open source projects are just a group of people and a repository. They cannot easily sign a grant contract, open a bank account or accept tax-deductible donations. A fiscal sponsor does those things for them, usually in return for a small share of the funds.
NumFOCUS is a well-known fiscal sponsor for scientific computing projects in the Python, R and Julia ecosystems, among others. Other open source foundations play a similar role in their own areas. Joining one usually comes with expectations about governance, a code of conduct and transparency, which are worth having anyway.
| Need | Without a sponsor | With a sponsor |
|---|---|---|
| Receive a grant | Must go through one member's university | Sponsor can hold the grant for the project |
| Accept donations | Personal accounts, unclear tax status | Donations to a recognised nonprofit |
| Pay contributors | Informal and hard to audit | Contracts and records handled centrally |
Can community donations really pay for maintenance?
Sometimes, and rarely on their own. Platforms such as Open Collective and GitHub Sponsors make it easy for individuals and companies to give money to a project, and for the project to show openly how it is spent. For a small tool, modest regular donations can cover hosting, a release now and then, or a few hours of paid maintenance each month.
Donations work best when the project has a clear, visible user base and a specific ask. "Help us pay for one day a month of maintenance" is more persuasive than a generic donate button. Companies that rely on a tool are often willing to sponsor it if someone asks directly and explains what the money will do.
The weakness of donations is that they are unpredictable. Treat them as one part of a mix, not as a salary.
How do you make the case to funders?
Show that the software is used and that the research depends on it. Funders want evidence of impact, and the main problem for software is that impact is badly recorded. You can improve that yourself:
- Make the software citable with a DOI and a citation file. See citing software in papers.
- Track citations, downloads and dependent packages where you can.
- Collect short statements from groups who rely on the tool.
- Describe what would break if the software stopped being maintained.
A clear account of who depends on a tool and what it costs to keep it working is usually more convincing than any argument about the importance of software in general.
What to do this week
List the research software your group depends on and mark which tools have nobody paid to maintain them. For your own tools, write down roughly how many hours a month maintenance takes. If you have a grant proposal in progress, add an explicit maintenance line. If a tool has many outside users, look at whether a fiscal sponsor or a donation page would make sense. None of this solves the funding gap on its own, but each step makes the next conversation with a funder easier.
Questions
Is software maintenance an eligible cost in research grants?
Often yes, when it supports the proposed research. Rules differ between funders, so check the guidance and make the cost explicit in the budget and the software management plan rather than hiding it in general staff time.
Does my project need to be a legal entity to receive funding?
Not necessarily. A fiscal sponsor can hold grants and donations on behalf of an open source project, or a member's institution can host a grant. Many scientific projects use one of these routes.
Are donations enough to sustain a research tool?
For small tools they can cover hosting and some paid hours. For widely used software they are usually one part of a mix that also includes grants and institutional support.
How can I show funders that my software matters?
Make it citable, track citations and downloads, collect statements from groups who rely on it, and explain what would break without maintenance.
Keep reading. More from the desk.
Teaching researchers to code: what works
Most researchers learn to code by copying a colleague's script and hoping. There are better ways. This guide covers the teaching approaches that have proven themselves in research settings and how to start one where you work.
Research software engineers: who they are and how to work with them
Research software engineers combine research knowledge with software skills. Many groups only call them when something breaks. This guide explains the role and how to bring an RSE in early, when it helps most.
How to organise a research project folder so others can follow it
A research project that only its author can navigate is hard to review, hard to hand over and hard to reproduce. A simple, consistent folder layout fixes most of that, and it takes an afternoon to set up.