In 2003, a postdoctoral researcher at a mid-sized European university wrote a set of Perl scripts to automate the flow of manuscripts through the lab's internal peer-review process. The scripts were part of a three-year methodology project, funded by a national science agency, and they worked well enough that the lab kept using them after the grant ended. The postdoc left academia a year later. The scripts stayed.

Twenty years on, those scripts still run the lab's peer-review pipeline. They assign reviewers, track revisions, and send reminder emails. They are unpatched, undocumented, and maintained by no one in particular. When the lab's IT director was asked who owns the code, she laughed. "Ownership implies someone could be held responsible," she said. "Nobody is."

This is not an isolated story. Across computational science, research groups depend on software that outlived its funding and its original authors. A 2021 survey of research software engineers found that over 60 percent had worked on code that was no longer actively funded, and most of that code had no formal support mechanism. The code becomes a public good in practice, but without the budget, governance, or liability that public goods usually require. The result is an infrastructure risk that grows quietly, one expired dependency at a time.

This article traces one lab's journey with such code, from the grant that created it to the day the lab finally decided to retire it. Along the way, it asks a question that few funders ask: if a piece of code shapes peer review, who pays to keep it alive?

A Peer-Review Pipeline Built on Code Nobody Owns

The lab in question is not obscure. It is a well-regarded institute in the life sciences, with dozens of researchers and a publication record that attracts international collaborators. Its peer-review pipeline handles roughly 300 manuscripts a year, each one routed through a series of Perl scripts that were written for a world before cloud computing, before GitHub, before most of the current staff had even started graduate school.

The scripts were originally built for a project called "Automated Review Workflow," a grant-funded effort to reduce the administrative load on editors. The project was considered a success: it cut review turnaround time by about 20 percent in its first year. But the grant explicitly covered only the development phase, not maintenance. When the postdoc who wrote the code moved to a biotech firm, the scripts were left in a shared directory with a single README file that said, "Run with Perl 5.6. See comments."

For years, the scripts worked. They were simple, deterministic, and unglamorous. They did not need to scale. They did not need to be secure. They just needed to send email and update a spreadsheet. The lab's staff learned to work around their quirks, like the fact that reviewer names had to be entered in a specific format or the script would silently drop them. "It was like a stubborn colleague," one senior editor said. "You knew its moods, so you worked with them."

But the colleague never retired. It just got older. As the lab upgraded its operating systems, the scripts' dependencies began to fail. A module that handled date parsing broke when the system switched to a new timezone database. A routine that formatted emails stopped working after the university changed its mail server. Each time, a junior researcher or a sympathetic sysadmin would patch the code, usually without documenting the change. The patches accumulated, often contradicting each other.

By the mid-2010s, the pipeline was a patchwork of fixes that none of the current staff fully understood. When a reviewer's invitation went out with the wrong link, it took the lab three days to trace the bug to a hard-coded URL that had been updated in one script but not another. The incident was resolved, but no one filed a bug report. There was no bug tracker. There was no version control. There was just the code, running on a server that the lab's IT department had long ago stopped actively managing.

The Grant-Funded Code That Refused to Die

Why did the lab keep using the scripts? The answer is not nostalgia. It is inertia, combined with a reasonable fear of change. The pipeline worked. Editors knew how to use it. Reviewers had been receiving emails from it for years. Replacing it would mean learning a new system, migrating data, and testing edge cases. That takes time, and time in a lab is measured in grant hours, not infrastructure hours.

The postdoc who wrote the code left no handover notes. He did not document the design, the data structures, or the assumptions baked into the logic. When the lab's current IT director asked to see the source code, she found a directory with no version history and no license. "It was like finding a manuscript with no methods section," she said. "You could see the results, but you had no idea how they were produced."

And yet the code survived because it solved a problem that the lab did not want to pay to solve again. Peer review is a bureaucratic process, and bureaucracy is exactly the kind of thing that software can automate. The lab's editors had grown up with the scripts. They did not think of them as software. They thought of them as furniture.

Survival by inertia is not the same as survival by design, but it is a powerful force. The scripts were not chosen. They were not evaluated against alternatives. They simply were, and so the lab continued to use them, year after year, as the research landscape around them changed.

The change that finally forced the issue was not a technical one. It was a social one. In 2018, a graduate student in the lab ran a reproducibility audit on a set of published papers. The audit found that several papers had used a statistical analysis script that was run by the same Perl pipeline, and that the script had a bug that silently dropped certain data points. The bug was not malicious. It was a simple off-by-one error in a loop that had been there since the postdoc wrote it. But it meant that some published results were wrong.

The audit did not make headlines. It was an internal memo. But it convinced the lab's director that the pipeline was no longer a convenience. It was a liability. The code that had outlived its grant was now shaping the scientific record itself.

When Scientific Software Becomes a Public Good

The lab's situation is a microcosm of a larger problem. Across the sciences, research increasingly depends on software that is written for one project and then reused, often informally, by other groups. This software is a public good in the economic sense: it is non-rivalrous, and it is difficult to exclude people from using it. But unlike a park or a bridge, it has no dedicated funding stream, no maintenance crew, and no clear owner.

The result is a tragedy of the commons, but with a twist. The commons here is not overgrazed. It is under-maintained. Everyone benefits from the software, but no one has an incentive to pay for its upkeep. The cost of neglect is diffuse and delayed, so it is easy to ignore. The cost of maintenance is immediate and concrete, so it is easy to postpone.

Consider the climate model archiving tool described in a related article on this site: a Fortran 77 routine from 1987 still determines which models get archived. That routine was written for a specific research question, but it became the gatekeeper for a whole field. No one chose it. It was just there.

The same pattern appears in labs that use shared analysis scripts for everything from fly behavior to isotope ratios. A penguin foraging model flipped when one lab rechecked museum dates, and the underlying code had been reused across three continents. The code was not designed to be a standard. It became one because it was convenient.

Economists call this the "software sustainability gap." Funding agencies typically pay for the creation of software, not its maintenance. A grant might support a postdoc for three years to build a tool, but there is no line item for updating that tool when the operating system changes, when a library is deprecated, or when a security flaw is discovered. The tool becomes free to use, but it is not free to maintain, and someone has to pay.

The Hidden Costs of Running on Borrowed Time

The lab's Perl pipeline is not unique in its neglect. The 2021 survey of research software engineers mentioned earlier found that most legacy code had no formal support mechanism. The engineers estimated that they spent, on average, about a day per month patching legacy software, time that was not billed to any grant. That time is a hidden cost. It is not counted in the lab's budget. It is not reflected in the institution's overhead rate. It is simply absorbed by the researchers and staff who keep the system running, often out of a sense of duty. "We had a postdoc who spent two weeks rewriting a script that had a hard-coded path," the lab's IT director recalled. "She could have been writing a paper. Instead, she was fixing a bug that someone else introduced in 2009."

The security risks are more serious. Legacy code often uses outdated libraries with known vulnerabilities. A 2022 analysis of scientific software found that nearly a third of the packages in common use had at least one unpatched security flaw, and that the median time to patch was over a year. For a lab that handles sensitive data, such as patient records or proprietary research, the risk is not abstract.

Even when the code does not fail, it creates friction. New formats for data, new APIs for email, new regulations for data retention: each one requires adaptation. The lab's editors spent hours each week manually reformatting files to match the scripts' expectations. "It was like filling out a paper form in triplicate," one editor said. "The software was supposed to save us time, but we were spending more time feeding it than it saved us."

The failure risk grows with every upgrade. When the university migrated its email system to a new platform, the scripts' SMTP library stopped working. The lab had to scramble to find a workaround, and for two weeks, review invitations were sent manually, one by one. No one was paid for that overtime. No one filed a change request. It was just another Tuesday.

Beyond the lab's direct experience, consider the case of a materials science group that used a legacy Fortran program to analyze diffraction data. The program had been written in the 1990s by a graduate student who never returned to academia. When the group upgraded its Linux distribution, the program's compilation failed due to a deprecated library. A postdoc spent three weeks porting the code to a modern compiler, but the port introduced subtle numerical differences that affected the group's published results. The group had to issue a correction, and the postdoc's own project was delayed by months. The cost of that maintenance was borne entirely by the group, with no external support.

The cumulative effect is a drain on research productivity. A 2019 study in the journal PeerJ Computer Science estimated that researchers spend a significant fraction of their time on software maintenance, time that could otherwise go to new experiments or analyses. The study's authors argued that this hidden labor is a form of unpaid infrastructure work, analogous to the invisible work of academic administration.

Why Funding Models Miss the Maintenance Problem

The root cause is a funding model that rewards novelty over longevity. Grants are awarded for new ideas, new methods, new tools. The goal is to produce a publication or a prototype, not to sustain an infrastructure. The incentives are aligned with creation, not with care.

This is not a secret. Funding agencies have held workshops on software sustainability for over a decade. They have issued reports. They have funded pilot programs. But the core problem remains: maintenance is not a research question, and it is not a training opportunity. It is a chore, and chores are hard to sell to a review panel.

Peer review itself is part of the problem. The system that evaluates grant proposals is staffed by active researchers, not by software engineers. They are trained to judge scientific merit, not to assess the long-term viability of a codebase. A proposal that promises to build a new tool is exciting. A proposal that promises to patch an old one is not.

There is also a cultural dimension. Many researchers treat software as a means to an end, not as an object of study. They write code to answer a question, and once the paper is out, they move on. The idea of maintaining that code feels like a distraction, even a waste. "I'm a scientist, not a developer," is a common refrain. The result is that the code becomes someone else's problem, and that someone else does not exist.

Some argue that the market should solve this. If software is valuable, someone will step in to maintain it. But scientific software is not a commodity. It is often highly specialized, poorly documented, and tied to specific workflows. There is no profit motive to maintain it, and there is no mechanism to charge users. The commons remains unmanaged.

There are, however, emerging models that attempt to address this. For example, some research communities have formed consortiums to support shared software. The numpy library, a cornerstone of scientific computing in Python, is maintained by a team funded by a mix of grants, donations, and institutional support. Similarly, the R statistical computing project relies on a volunteer core team and contributions from corporations that depend on it. These examples show that community governance can work, but they are the exception rather than the rule. Most scientific software is not as widely used as numpy or R, and so it lacks the critical mass to attract sustained funding.

Lessons from a Lab That Let Its Code Go Legacy

The lab's decision to retire its Perl pipeline came in 2022, after the reproducibility audit. The decision was not easy. The lab had to choose between building a new system from scratch and adapting an off-the-shelf tool. Both options were expensive, and neither was funded.

The lab chose to build its own, but with a difference. This time, the project was planned with maintenance in mind. The code was written in a modern language, with unit tests, version control, and documentation. The team included a software engineer, not just a postdoc. And the budget included a line item for ongoing support, funded by a mix of institutional money and a small grant from a scientific society.

The migration took two years, and it was not smooth. The old scripts had inherited a set of behavioral quirks that users had come to rely on, even if those behaviors were bugs. The new system had to replicate those quirks, or the editors would rebel. "We spent six months just documenting the old system's behavior," the IT director said. "We had to reverse-engineer our own infrastructure."

The new system is still not perfect. It has its own bugs, its own quirks. But it is maintained. There is a named person who is responsible for it. There is a budget for it. There is a process for reporting and fixing issues. The lab's director said, "We learned that the cost of building software is not the price of the building. It is the cost of the upkeep. We just never counted it."

The lab is not triumphant. The migration consumed time and money that could have gone to research. The new system is more reliable, but it is not more innovative. It does the same thing the old scripts did, just with better documentation. The lab's director is frank about the trade-off: "We lost two years of research productivity to fix something that should have been fixed a decade ago. The only consolation is that we won't have to do it again."

Making Code Outlive Its Grant, Responsibly

The lab's story offers lessons, but they are not easy ones. The first lesson is to plan for maintenance at the start of a project, not at the end. This means writing code that is modular, documented, and testable. It also means budgeting for the time it takes to maintain that code, even if that time is not glamorous. "We now ask every new project to include a software sustainability plan," the lab director said. "It is not a formality. It is a commitment."

The second lesson is to archive code with a DOI and a license. This makes it possible for others to use the code legally and to cite it properly. It also creates a record of what the code was supposed to do, which is invaluable when the original authors are gone. A DOI does not guarantee maintenance, but it does make the code visible, and visibility is a prerequisite for community support. The lab now has a policy that all code produced with grant funding must be deposited in a public repository with a permissive license.

The third lesson is to budget for handover and training. When a postdoc leaves, their code should not leave with them. There should be a process for documenting what the code does, how it works, and how to run it. This is not just a technical task; it is a human one. It requires the departing researcher to spend time they do not have on tasks they do not enjoy. The lab has started requiring a "code handover" as part of the exit process, and it has found that it saves time in the long run. "It is painful," the IT director admitted. "But it is less painful than reverse-engineering a script five years later."

The fourth lesson is to spread ownership across a community. A single lab is fragile. A consortium is more robust. If multiple groups use the same software, they can share the burden of maintenance. This works best when there is a formal governance structure, such as a steering committee, and when funders recognize the value of such structures. The lab is now part of a small consortium of peer-review platforms that share a common codebase. The consortium has a shared maintenance fund, supported by membership fees from participating institutions. It is not a perfect model, but it has reduced the burden on any single lab.

Finally, funders need sustainability checklists. They already ask for data management plans. They should ask for software sustainability plans. These plans should cover not just the creation of code, but its maintenance, its archiving, and its eventual retirement. The cost of such plans is small compared to the cost of neglect. Some funding agencies have begun to require such plans, but they are still the exception. The lab's director hopes that will change. "We need to stop treating software as a disposable byproduct of research," she said. "It is a piece of infrastructure, and infrastructure requires investment."

None of this is easy, and none of it is guaranteed to work. The lab's new system could itself become legacy in a decade. The field could change, the funding could dry up, the engineer could leave. But the lab has learned that the problem is not the code. The problem is the assumption that code takes care of itself.

Science has always depended on infrastructure, from telescopes to particle accelerators to the temperature-controlled rooms that keep model organisms alive. Software is just another piece of that infrastructure, and it deserves the same respect. The code that outlived its grant is not a curiosity. It is a warning. The next time a grant proposal is written, the question should not be only what the software will do. It should be who will keep it doing that, and at what cost.