The Economics of Maintaining Scientific Software

Getting your Trinity Audio player ready...

Scientific software is not maintained automatically by publishing its source code. It requires continuing labor: fixing defects, updating dependencies, answering user questions, improving documentation, adapting to new hardware, reviewing contributions, preserving compatibility, and protecting scientific results from silent computational errors.

The central economic problem is straightforward:

Scientific software often produces widely distributed public value, while its maintenance costs remain concentrated on a small number of developers.

Researchers, universities, companies, students, and public agencies may all benefit from a software package. Yet the responsibility for keeping it operational may fall on one laboratory, one grant-funded developer, or even one unpaid volunteer.

This mismatch explains why software can be scientifically essential and economically neglected at the same time.

Scientific Software Is Research Infrastructure

Research software includes source code, algorithms, scripts, computational workflows, and executables created during research or for a research purpose. It can function as:

• an experimental instrument;
• an implementation of a mathematical method;
• a data-processing pipeline;
• a simulation environment;
• a shared library used by other scientific projects;
• an infrastructure layer supporting an entire discipline.

The Research Software Alliance emphasizes that software is fundamental to modern research but has historically received less recognition than research data and conventional publications. The FAIR for Research Software principles similarly treat software as a research object that should be findable, accessible, interoperable, and reusable.

A maintained software package may enable hundreds of later studies. An abandoned package may make earlier results difficult to reproduce, prevent new researchers from using an established method, or force several laboratories to rebuild substantially the same tool.

Maintenance is therefore not merely technical housekeeping. It is part of maintaining the productive capacity of science.

Why the Market Underfunds Scientific Software

Scientific Software Often Behaves Like a Public Good

Open scientific software is commonly non-rival: one laboratory’s use does not normally prevent another laboratory from using it. It may also be difficult to exclude users when the code is distributed under an open-source license.

These properties create a familiar public-goods problem. Every user benefits from maintenance, but each user has an incentive to let somebody else pay for it.

A university may reason that another institution will fix an important defect. A company may use an academic package without contributing because its individual contribution appears unnecessary. Researchers may cite a tool while assuming that software maintenance is already covered by its original grant.

The result is free-riding—not necessarily because users are malicious, but because the benefits are dispersed and the responsibility is unclear.

Grant Systems Prefer Novelty

Research grants are usually easier to justify when they promise:

• a new discovery;
• a new method;
• a new platform;
• a measurable project completed within the grant period.

Routine maintenance is harder to present as innovation. “Keep the existing software reliable for another five years” may be scientifically valuable, but it does not resemble the narrative structure of a conventional research proposal.

This can produce a damaging cycle:

1. A grant finances the creation of new software.
2. Publications demonstrate the software’s initial value.
3. The grant ends.
4. The developers move to projects that can generate new grants and papers.
5. The original software accumulates technical debt.
6. Users either tolerate defects or build replacements.
7. Public money finances reinvention instead of preservation.

Recognizing this problem, the UK Software Sustainability Institute established a Research Software Maintenance Fund, supported through UK Research and Innovation. The fund explicitly finances existing software, reliability, accessibility, and reduction of technical debt rather than requiring every award to create a new tool.

The Visible and Hidden Costs of Maintenance

The maintenance cost of scientific software is much broader than correcting reported bugs.

Direct Labor Costs

Maintainers must spend time on:

• defect diagnosis and correction;
• test development;
• dependency upgrades;
• security patches;
• release management;
• code review;
• documentation;
• user support;
• migration to new operating systems and hardware;
• packaging and installation;
• performance optimization;
• preservation of archived versions.

This work may require both scientific expertise and professional software-engineering ability. A general programmer may not understand the numerical assumptions behind a model, while a domain scientist may not have enough time or engineering experience to restructure a large codebase safely.

The relevant labor market is therefore unusually narrow: qualified maintainers often need to understand both the science and the implementation.

Technical Debt

Technical debt is the future cost created by expedient design decisions, insufficient testing, outdated dependencies, fragmented architecture, missing documentation, or postponed refactoring.

It resembles financial debt in one limited sense: postponing necessary work can create growing future obligations. Unlike financial debt, however, technical debt has no standardized balance sheet. Institutions may not notice it until a critical dependency stops working or a scientific result cannot be reproduced.

Recent research on technical debt in research software identifies reliability, maintainability, and scientific validity as interconnected concerns. The economic cost is therefore not limited to programmer hours. It may include invalid analyses, delayed studies, duplicated implementations, or loss of accumulated scientific knowledge.

Coordination Costs

Successful open-source projects also require governance. Someone must decide:

• which feature requests belong in the project;
• which interfaces must remain stable;
• when compatibility may be broken;
• who may approve releases;
• how scientific disagreements affect implementation;
• whether a project should merge with, depend on, or compete with another project.

A repository can be publicly accessible while remaining institutionally fragile. Openness reduces barriers to contribution, but it does not eliminate the need for coordination, responsibility, and decision-making.

Opportunity Costs

Maintainers frequently face a choice between work that keeps existing infrastructure functioning and work that produces visible academic outputs.

A new paper may improve a researcher’s career prospects. Repairing installation instructions for a widely used package may help thousands of users while generating little formal academic credit.

The economic cost of maintenance therefore includes the maintainer’s forgone publications, grant applications, consulting work, or new software projects. A funding model that ignores this opportunity cost effectively asks maintainers to subsidize the scientific community with their careers.

Maintenance Can Be More Valuable Than Replacement

Creating a new package often appears more exciting than maintaining an old one. Economically, however, replacement may be the more expensive option.

An established scientific package may already contain:

• years of domain knowledge;
• tested algorithms;
• known numerical behavior;
• compatibility with established datasets;
• integrations with other tools;
• user documentation;
• accumulated community trust;
• thousands of resolved edge cases.

These assets are forms of intangible capital. They may not appear in a university’s accounts, but rebuilding them can be expensive.

The original development cost is partly sunk: it cannot be recovered merely by abandoning the software. The relevant decision is whether the future benefits of maintenance exceed the future maintenance costs. For widely used software, a comparatively small maintenance investment can preserve a much larger stock of prior scientific investment.

This does not mean that all old software should be preserved indefinitely. Some projects should be retired when:

• usage has disappeared;
• a demonstrably better replacement exists;
• the architecture cannot be repaired economically;
• maintenance would create unacceptable security or validity risks;
• the underlying scientific method is obsolete.

Good funding systems should support both maintenance and orderly retirement. Permanent support for every repository would be as inefficient as automatic abandonment after every grant.

The Option Value of Maintained Software

Maintained research software has option value: it preserves society’s ability to use, inspect, extend, or reproduce scientific work in the future, even when the exact future application is unknown.

A niche mathematical library may suddenly become important when a new field adopts its methods. A simulation package may become valuable during an unexpected public-health, environmental, or engineering problem. Archived code may be needed to audit an influential scientific result years after publication.

Traditional project evaluation often discounts these possibilities because they cannot be forecast precisely. Yet maintaining a relatively inexpensive software dependency can preserve many future research options.

This is one reason prediction-free research funding may be relevant to scientific software. Instead of requiring maintainers to predict the next major discovery enabled by their work, a funding system can evaluate demonstrated usage, dependency relationships, scientific importance, reliability, and continuing contribution.

Who Should Pay?

No single revenue model is appropriate for all scientific software.

Research Grants

Project grants can finance software development and maintenance when the work is directly connected to a research program. Their weakness is discontinuity: funding may disappear between grant cycles, and maintenance may be forced into proposals designed around novelty.

Institutional Core Funding

Universities, laboratories, and research infrastructures can employ research software engineers as permanent staff. This preserves expertise and allows maintenance across multiple projects.

However, institutional funding may favor software used locally, even when the largest benefits occur globally. It may also leave independent developers and maintainers outside established universities unsupported.

Public Maintenance Funds

Dedicated funds can treat software as infrastructure rather than as a temporary research by-product. The UK Research Software Maintenance Fund is one concrete example. The U.S. National Science Foundation has also supported programs aimed at building safe and sustainable open-source ecosystems around research products.

Dedicated programs improve recognition, but they still require applications, selection panels, reporting, and periodic renewal. A small project may be too important to abandon yet too specialized to compete effectively in a conventional call.

Consortium Funding

Universities, companies, foundations, and public agencies can share the cost of maintaining common software. This aligns the contributor base with the beneficiary base.

The main difficulty is coordination. Each organization may wait for others to commit first. Dominant funders may also attempt to control a project whose value depends on remaining open and scientifically neutral.

Commercial Services

A project may sell support, hosting, integration, certification, training, or custom development while keeping the core software open.

This works best when users have budgets and need operational guarantees. It works less well for fundamental mathematical software, small research communities, educational tools, or software primarily used by underfunded laboratories.

Commercial incentives may also prioritize paying customers over less profitable scientific requirements.

Donations and Retroactive Funding

Donors can reward software after it has demonstrated value. Retroactive funding reduces the need to predict which proposed tools will succeed.

The difficulty is discovery. Donors may see highly visible applications while overlooking foundational libraries, maintenance work, and obscure dependencies. This is closely related to the broader problem of measuring the impact of research software and mathematical libraries.

Why Download Counts Are Not Enough

A software package should not be funded solely according to downloads, stars, citations, or the size of its user community.

Each metric can misrepresent value:

• downloads may include automated installations;
• citations may omit software used indirectly;
• repository stars measure attention more than scientific necessity;
• dependency counts may treat trivial and critical dependencies equally;
• user numbers may undervalue specialized software used in high-impact research;
• recent activity may reward cosmetic updates over difficult maintenance;
• popularity may reinforce the existing Matthew effect.

Scientific software evaluation should combine several forms of evidence:

Evidence	What it may reveal
Scientific citations	Explicit use in publications
Dependency relationships	Infrastructure value to other software
Reproducibility use	Importance for verifying results
Active users	Current practical demand
Issue resolution	Ongoing maintenance labor
Release history	Reliability and continuity
External contributions	Community development
Documentation and tests	Reusability and quality
Security and compatibility work	Risk reduction
Expert assessment	Scientific correctness and uniqueness

No metric is individually sufficient. Evaluation must distinguish between writing software, maintaining it, governing its community, documenting it, and supplying the scientific expertise required to validate it.

A Possible Role for AI Internet-Meritocracy

AI Internet-Meritocracy proposes funding scientists and free and open-source software developers according to evidence of demonstrated contribution rather than only through advance project selection.

Applied to scientific software, such a system could examine:

• public repositories and release histories;
• dependency graphs;
• software citations;
• documented scientific applications;
• maintenance activity;
• issue and pull-request histories;
• reproducibility evidence;
• the originality and difficulty of the software;
• contributions that preserve compatibility or reliability;
• the division of labor among developers, reviewers, documenters, and maintainers.

This approach could address several weaknesses of conventional grants.

First, maintenance could be rewarded continuously rather than only through occasional competitions. Second, obscure foundational dependencies could be evaluated through their relationships to downstream software. Third, independent developers could receive support without first obtaining an institutional position. Fourth, funding could follow demonstrated work instead of requiring maintainers to repeatedly describe speculative future deliverables.

However, automated evaluation also creates risks. Repository activity can be gamed. Dependency counts can exaggerate importance. Generated documentation or low-value commits can create misleading signals. Popular projects may dominate obscure but scientifically essential tools. AI systems may misunderstand specialized code or reproduce existing prestige biases.

For that reason, AI-based funding should not be treated as an infallible measure of value. It requires transparent criteria, multiple evidence sources, adversarial testing, human appeal mechanisms, and protection against manipulation. The goal should be better allocation—not replacing every scientific judgment with a single score.

Maintenance Should Be Treated as Productive Scientific Work

Scientific institutions often distinguish “research” from “maintenance,” as though the former creates knowledge while the latter merely preserves machinery.

For software-based science, this distinction is frequently false.

Correcting a numerical instability can change scientific conclusions. Updating a library can make an old method usable on new hardware. Adding tests can reveal hidden assumptions. Improving an interface can allow another discipline to apply an existing technique. Preserving an executable environment can make a published result reproducible.

Maintenance can therefore produce new knowledge, protect existing knowledge, and increase the return on earlier research investment.

A rational science-funding system should recognize at least three different activities:

1. Creation: developing a new method or software system.
2. Maintenance: preserving reliability, usability, and compatibility.
3. Stewardship: governing the project, supporting users, documenting knowledge, and planning its long-term development or retirement.

All three can create scientific value. Funding only the first guarantees deterioration of the infrastructure on which later discoveries depend.

Conclusion

The economics of maintaining scientific software is defined by a structural mismatch: the benefits are broad, cumulative, and difficult to exclude, while the costs are immediate and concentrated.

Conventional grants can create powerful software but often fail to sustain it. Universities may depend on tools that they do not directly finance. Users can benefit without contributing. Maintainers face strong incentives to pursue new publications and projects instead of preserving existing infrastructure.

The solution is not to maintain every codebase forever. It is to evaluate software as scientific capital and fund maintenance when its expected future value exceeds its cost.

That requires dedicated maintenance programs, institutional research-software careers, consortium financing, commercial services where appropriate, donations, retroactive rewards, and new systems capable of identifying hidden infrastructure work.

Scientific software does not remain valuable merely because its repository remains online. Its value survives because people continue to understand, test, repair, document, and improve it—and those people must be economically supported.