How to write a case for funding a software developer

MoneyBy Mike Jackson, Software Architect.

Your project has been developing software that is becoming ever more popular. You now find yourself struggling to find time both to develop and support your software, and keep your stakeholders happy, and to do your research. One way to continue to satisfy demand is to recruit a dedicated software developer for your project. But how do you get the funding? This guide helps you to make the case for funding a software developer for your project. It helps you to define the activities that a software developer would do and the effort these will take. It suggests how you can gather evidence of your software’s impact and popularity so funders can be reassured that the benefits of funding ongoing development of your software are far beyond just your project itself.

Why write this guide?

As part of our collaboration with BoneJ we helped to write a case for funding a full-time software developer to maintain and further develop the BoneJ open-source software. We felt that a guide based upon both this work and our experiences in developing, maintaining and supporting open source software would be useful to researchers seeking funding for developers on their projects.

Provide an overview of your software

What is the nature, and origins, of your software? What are funders helping to keep alive?

Provide an overview of your software, including:

  • What the software is designed to do, its key capabilities, its novel features. If you have any associated papers, then cite these.
  • The target audience for the software e.g. evolutionary biologists, particle physicists, epigraphers, scientists requiring efficient mathematical computations etc.
  • Other audiences the software may appeal to. If you’re aware of any potential for your software to be used within other domains then state these.
  • Key implementation details e.g. what language(s) it is written in, what operating systems it runs under, its support for parallel programming libraries, whether it is an application, a middleware, a library or a service etc.
  • Its provenance including how it originated and when, which individuals, projects and organisations have been involved in its development, who has funded development to date. If possible, include an estimate of the person-hours (funded and unfunded) invested to date as this can give funders a better idea of both the return on investment and also the potential loss if the software cannot continue to live.
  • How your software is distributed e.g. as source code, a binary, a service, and any conditions relating to this e.g. its licencing, whether the source code repository is anonymously readable, whether companies need to pay for a licence, whether your service is free or for a subscription etc.

Demonstrate impact, popularity and ongoing demand

Why should funders help keep your software alive? Who will benefit from this beyond just your own research project?

Provide evidence that there is a community that depends upon your software, who need it now and will need it in the future and why. Demonstrate that, by funding ongoing development of your software, funders are not just helping you with your research, but are helping others with theirs.

For the impact that your software makes upon the research of others, consider:

  • Publications associated with your software. The number of citations these publications have on ScienceDirect, Scopus or GoogleScholar.
  • Other researchers that use your software, or, better still, other researchers that need it (even if your software is not innovative, in research terms, the research it enables may be highly innovative). Papers they have published. Citation counts for these papers. Any feedback they have given you about how your software or your research has helped them.
  • Domains your software has been applied in, especially if these are cross-disciplinary or your software has broken into domains that you did not envisage when you started its development.
  • The global reach of your software e.g. the Bioinformatics Support Service at Imperial College London geo-locate downloads of their MRIdb to indicate impact.

For the popularity of your software, consider:

  • Number of downloads, known deployments, and registered users.
  • Number of mailing list subscribers, forum members, and Twitter followers.
  • Number of search engine hits that your software and related project resources have and the rankings of these.

For the novelty of your software, consider:

  • Open source or proprietary, academic or commercial software that fulfils a similar function to yours.
  • What makes your software different from theirs, what are its “unique selling points”. Consider correctness, accuracy, efficiency, scalability, customisability, usability, cost, popularity and openness.
  • Any awards, or recognition, your software has won from your institution or other bodies.

You may also want to:

  • Contact your stakeholders, collaborators and existing users for supportive quotes or, ideally, formal letters of support.
  • Set up a community survey to find out who uses your software, what for, any publications they have, how critical your software is to their research, whether they are willing to contribute to the future development of the software, and how they would be willing to contribute (e.g. by providing case studies, testing, or development).
  • Set up a community survey to find out about potential users of your software, those who are not using it just now but would be interested in doing so, what is preventing them from using your software just now, and what would they like to see from your software.
  • Mention any contacts from other projects or groups about possible collaborations.
  • Demonstrate any commercial interest, as funders can look favourably on such collaborations and the potential for technology transfer.

If your existing funding still has some time to run, or you’re reading this guide to draw up plans to apply for funding a few months away, then another alternative is to set up some form of, mandatory or optional. user registration e.g. on a download page, or built-in to your software. This provides you with a set of known users you can contact directly.

Describe what a software developer would do

Assuming a software developer was funded, what exactly would they do? How would their work on your software help your stakeholders, collaborators and users?

An important part of the software developers role is the development of new functionality, for your own research and for that of others. Remember to relate any new functionality to the needs of the users you’ve already listed, and that new features may go beyond the software itself to complementary resources such as user guides, tutorials and infrastructure. For example:

As part of our community survey, respondents were asked to rate the importance of proposed future developments. Ranking these in terms of the perceived importance to the users gives (most important first):

  • A 10 minute quick start guide.
  • An implementation of the data analysis component that uses Bayesian inference.

The Chemical Processes Group at the University of Oxbridge require a distributed memory version of the basic data analysis component to enable our software to run their analyses within hours rather than days.


It can be easy in a research context, focusing on the new and innovative, to forget that developing software involves many tasks that are not related to new functionality, but on improving the existing software and supporting users. These tasks may neither be innovative nor directly related to writing code, but they contribute to both improving the quality of the software and to building a productive relationship with users, and they are the reason why software development is a full-time activity in its own right. This day-to-day grunt work includes:

  • Refactoring software to improve its usability, maintainability, reliability, efficiency, correctness, robustness, extensibility or inter-operability.
  • Bug fixing and writing associated tests to ensure that bugs don't reappear.
  • Writing and updating documentation and tutorials.
  • Managing releases.
  • Supporting users and developers including handling queries about usage, bug reports and requests for new functionality.
  • Managing contributions such as new features, bug fixes or case studies.
  • Disseminating information including announcements, papers, articles and talks.
  • Managing project infrastructure including web sites, mailing lists, source code repositories, wikis, Twitter feeds, Docker images, virtual machines, continuous integration servers etc.

Remember that software developers have interests, abilities and aspirations that are centred upon the design and development of software as an end in itself. This is in contrast to researchers, for whom developing software is a means to an end, the research itself. Consequently, another important role a software developer can fulfil is that of a mentor or local expert. They can provide advice, best practice, guidance, technical review and quality assurance to help you and your group or department improve the quality not just of the software you seek funding for, but of all the software produced by your group or department, and the software development skills of you and your researchers.

You could summarise this information on what your software developer would do in a form analogous to a job description, highlighting the key roles and responsibilities of your software developer and the percentage of time on each that would be spent. For example:

Responsibility and key tasks Key tasks Approximate percentage of time, based on a 35 hour week
Development Designing and developing new functionality, and associated tests and documentation.
Managing new releases.
Maintenance p>Refactoring to improve efficiency, robustness, extensibility and inter-operability.
Fixing bugs and writing associated tests to ensure that the bugs do not recur.
Managing bug fix releases.
Community engagement and support Supporting users and third-party developers.
Reviewing and integrating contributions from users and third-party developers e.g. publishing tutorials and HOW-TOs, and case-studies, bug fixes, new functionality, refactored code.
Meeting with researchers to discuss their requirements in terms of functionality, usability, efficiency, robustness, extensibility and inter-operability.
Dissemination Publishing release announcements, technical papers, e-mails.
Delivering talks and tutorials at conferences and other events.
Contributing to journal and conference papers.
Infrastructure management Managing infrastructure e.g. web site, GitHub, Google Group, Twitter feed, continuous integration server.  
Mentoring Providing advice and guidance to researchers within the group or department.
Reviewing software provided by researchers within the group or department.

It may help to make your case if you also provide a work plan summarising what your software developer would do for their first 6-12 months, to show to funders that you have a clear picture as to how you will use your developer (and so use their funding). You should base this on your requirements and those of your users. Choose as an initial task something that is quite straightforward but would allow a new developer to become familiar with your software and your current development infrastructure.

Describe the challenges you have in developing the software yourself

If these tasks are so important, what stops you from doing them yourself? What are the constraints on your project team? Why do you need a software developer?

You’ll have now demonstrated that there is plenty to keep a software developer busy and that their role will be addressing the requirements of your users. You now need to explain the challenges you face in doing these tasks yourself. Consider:

  • Who in your research group carries out these tasks just now (this might just be you).
  • What are the other demands their (or your) time.
  • How do these rank in terms of importance compared to working on your software.
  • What are the consequences if they are not available, due to these demands or due to illness or leave.

For example, a member of your project may have lecturing commitments which means they have very little time to devote to development. If one of your project team is ill then there may be key features of your software that you cannot support until they return. You may be able to commit time for maintenance but only at the expense of your research.

If you no longer have adequate time or effort to support and develop your software or to satisfy requests from users in a timely way, this impacts upon the users who depend upon your software, which may hamper, or even prevent, their research from continuing. More drastically, think about your software’s “bus factor” – the number of developers who would have to be struck down by a bus before there is no one left who understands you software which would be bad not just for you, but for your users too. For many research projects, the bus factor for their software is 1. A funded developer can help to increase your bus factor to 2.

A software developer allows you to focus not only on your research but on networking to promote the uptake and use of your software, while the software developer manages the technical side of developing the software itself.


By completing the foregoing activities, and writing these up, you will have a document that:

  • Provides an overview of what your software does and why it is important.
  • Demonstrates the impact, popularity and demand for your software and who your software is important to, and why.
  • Describes the key roles and responsibilities that a funded software developer would fulfil, how they’d spend their time, and how this helps you and your users.
  • Describes the challenges you would face in continuing to develop the software yourself and why your current resources are no longer adequate.

Together, these make your case for funding a software developer. Good luck!

More information

For help in setting up a community survey, please contact us.


Thanks to Michael Doube of The Royal Veterinary College, The University of London whose request inspired this guide, and to Mark Woodbridge of the Bioinformatics Support Service, Imperial College London, who provided valuable feedback and suggestions.

Share this page