How to fund research software or cost it into grants
This is a guide to how to find funding for research software, and how to cost it into grant applications. It collects together the advice we give to researchers at the University. It is not exhaustive. Please get in touch if you think we are missing something or there is something you think we should change.
What do we mean by "funding software"?
Funding software means funding the people with skills who are needed to write, maintain and/or optimise that software. Many people have these skills, whether they are researchers on an academic career track, professional services staff in centralised groups, students, consultants or general members of the public.
Who are "Research Software Engineers"?
Many people who spend their time developing research software now identify themselves as Research Software Engineers (RSEs). Indeed, there are now so many RSEs that they have a whole professional Society, and they have encouraged universities and research organisations to develop RSE career paths and set up RSE Groups so that their skills and software achievements are recognised and rewarded.
What do I need to do to fund my software?
If you want to fund your research software, then you need to find a way to raise money to employ someone with software skills, whether or not they identify as a RSE. Maybe that person is yourself, and you want to fund your time to continue developing software that you have created as part of your research?
What are the sources of funding for software?
There are lots of funding sources for software, e.g. research councils, charitable organisations, commercial funders etc. Very occasionally there are specific software funding calls, where the focus of the call is entirely about funding people to engage in software development. However, these calls are very rare and often highly oversubscribed. More normally, the time of software developers is funded as a small part of a larger grant. This is because writing software is, in itself, not the primary output of research funding. Instead, research software is a tool that enables research activities to be successful. It is thus important to think about what research your software will enable, and who the audience who will use your software as part of a research project would be.
How can I request research funding for software?
Typically, the best approach is to fund software by adding it to the grant that needs that software for the research (e.g. if the software needs developing to undertake that research, or if porting, maintenance or optimisation are required). Work out what software activities are needed to fulfill the requirements of that research project. Estimate how long those activities would need to be, what the deliverables would be, and how many skilled people would be needed to deliver on those requirements within the needed timelines of the project. This will give you a good idea of how much person effort is needed, and from this, you can generate a costing (e.g. via WorkTribe). You would also have a good idea of the skeleton software development plan, which can be translated into work packages in your proposal.
How do I cost RSEs into grant proposals?
Researchers who write software should be costed identically to any other researcher. To make recruitment easier, the Research Software Engineering Group operates a "postdoc-pool" model of skilled postdoctoral researchers who code (who we call RSEs). They are costed identically to postdocs, and operate in a very similar way (i.e. they are embedded in your research group and will be focussed on your project). The only difference is that we try to join different projects together so that, when the funding on your projects comes to an end, we can move the RSE from your project onto another. This "postdoc-pool" model helps detach research funding from length of employment, thereby providing more career stability to RSEs. It also helps the University retain their valuable skills, and avoids the situation where an RSE is being made redundant in one part of the University, while another department is trying to recruit someone with exactly those skills.
The benefit to you of this postdoc-pool model is that the RSE is focussed entirely on the software, and not worrying about applying for future jobs or trying to generate outputs that would progress a more traditional academic career. In addition, all RSEs in this model are co-managed by the central RSE Group and network together via our group meetings, group chat and social events. This means that the RSE doesn't feel alone, but instead has the support and can draw on the knowledge and experience of the other RSEs in the University.
A further benefit of working with us is that we can help you work out what the requirements are for the software, and can estimate the amount of time and person-effort needed to deliver on those requirements within your project timescales. We can also provide technical management and architecting of the software, as well as helping write the grant and providing track record.
That sounds great. What do I do next?
If you are interested then please get in touch. The only constraint is that we ask that RSEs are costed in units of 50% for blocks of 6 months or more (e.g. 18 months at 50% would be ok, as would 12 months at 100%. But 3 months at 50% or 6 months at 25% would not). This is so that a single RSE is working on no more than two projects at once, and that we can schedule the projects to minimise gaps in funding. In addition, you must talk to us before costing in an RSE, and we do need at least 3 months notice of the project start time to support scheduling (e.g. we may need to recruit a new RSE if none are available).
We should emphasise that we are not the only route to hire people who have software skills and you do not need to use us to hire an RSE. We also know that there are projects that don't fit this 50%/6 month model, e.g. because they need smaller or more focussed bursts of software development activity. For these projects, we encourage you to get in touch with Research IT. They are a group of professional software developers who can be costed using a day-rate.