Photo by Liam Riby

By Emmy Tsang, Tania Allard, Becca Wilson, Neil Chue Hong, David De Roure and Jez Cope (Editor).

This post is part of the CW20 speed blog posts series.

Most modern-day research involves the use of software, and research software itself is increasingly recognised as a key output of research by the research community. While it is encouraging that more funders are recognising the importance of providing funding for the development of research software, the differences between software and other types of research output often go unacknowledged. One of the key differences is that software requires maintenance to remain useful, and that calls for a long-term, sustained investment. What does software maintenance entail and why is it important? What should funders consider when establishing a funding scheme for software maintenance and what would success look like?

What is maintenance and what needs maintaining?

Research funding focuses on novelty - indeed, research is often thought of as defined by the creation of new knowledge. However, research products often continue to be of use for years, if not decades, requiring maintenance to realise their full value. Maintenance is the opposite of novelty: preventing some part of the infrastructure that many people rely on from changing too quickly, either by accident or design, so that it continues to function without surprising anyone.

Not every piece of software needs maintenance. No-one needs the burden of continuing to support and maintain every last line of code ever written. Small analysis scripts fill a single purpose and don’t need to outlive that purpose. Some software may be useful for a time but reach the end of its life when it no longer supports an active area of research, or is superseded by newer technology or a better implementation. However, software that continues to have a purpose will be used, and if it is to avoid becoming dangerous it must be maintained. Hardware changes, languages and tools develop, bugs are found, needs evolve, and unless the software is updated to reflect this it will become increasingly full of potholes, like an unmaintained road.

Not all software used for research needs to be maintained by the research community. Some have a wider value and the responsibility of maintenance falls wider. Examples of this include programming languages themselves (such as Python and R) and popular numerical libraries such as the NAG library. These receive support from a much wider community through volunteer work, commercial models or both. Research software, developed by researchers for researchers, typically has a much smaller community, and the resource available for maintenance of this currently falls well short of what is required.

What if we don’t maintain research software?

If research software maintenance is under-resourced it contributes to the accumulation of technical debt, with far-reaching consequences. For example, it may render unusable existing research datasets that have already had substantial investment in their creation. Future impacts include contribution to the reproducibility crisis, for example if findings can no longer be validated when a particular software tool is rendered obsolete. At the extreme end a loss of data itself could occur if data pipelines are left unsupported. It’s hard to argue that the initial investment of time and money was justified when data becomes unusable well before being fully exploited.

Where research that relies on research software informs policy there can be even greater repercussions for decision making. It’s not only research and open science that run on software, but the entirety of our modern society. Startups, corporations, government, and financial and health institutions all depend on digital infrastructure to perform their day to day activities. One thing the global pandemic of COVID-19 has shed light on is the importance of readily available and robust infrastructure and software. As a great portion of the global population is quarantined or in lockdown, there has been an unprecedented demand for access to digital infrastructure.

Don’t we fund this already?

It’s true that there are many schemes that fund digital infrastructure e.g. Wellcome’s Technology Development Grants, BBSRC’s Bioinformatics and Biological Resources Fund, and EPSRC’s Software for the Future. However, while most of these schemes can be used to develop software, they are typically aimed at the creation of novel infrastructure, structured as short-term projects, and heavily oversubscribed. 

There are some examples of longer-term investment in maintaining digital infrastructure. ESRC fund infrastructure to support longitudinal studies, as well as the UK Data Service to provide a unified point of access to social and economic data. The Collaborative Computational Projects enable maintenance of flagship codes from different scientific communities, in some cases for decades. 

We also see examples of private foundations funding software maintenance: Chan Zuckerberg Initiative’s Essential Open Source Software for Science, the Sloan Foundation’s Data and Computational Research programme, and Mozilla’s Open Source Support awards. However, these programmes are all typically providing short-term funding; essential for bridging the gap between research funding and the next stage of software development, but not as useful if there is no obvious source of software maintenance funding to bridge to. Even if we are already funding some software maintenance, we need to radically rethink how we do this in the future if we are to make a substantial impact to the way that all research software is maintained and made available for others to reuse.

A new vision for funding research software maintenance

We envisage a future with maximum benefit achieved from investment in research, in which research outputs, including software, are sustained for future use, which in turn adds value. Conversely, at the moment there is significant decay of grant outcomes and we propose to define and measure this so that it can be reduced.

Could funders make budget available to research organisations to support software maintenance? Here are two examples of established (UKRI) mechanisms that might provide a basis for discussion:

1. Impact Acceleration Accounts are strategic awards provided to institutions to support knowledge exchange and impact from their funded research e.g. EPSRC, ESRC, BBSRC (also AHRC has "follow on funding"). Could this provide an explicit mechanism to fund software maintenance to maximise the impact of the software?

2. Open Access Block Grants are issued by the Research Councils to research organisations to enable them to comply with the policy on open access. Could such a mechanism be used to support making research software available open source?
 

Whatever mechanisms for funding are put in place, the clear message is that software maintenance must be supported to ensure a strong platform for research.