You are three years into a postdoc, your grant is ending, and the tool you built is cited in four thousand papers. Nobody is paying you to answer the bug reports. Nobody is paying anyone.
This is not an edge case. It is the standard life cycle of open-source scientific software, playing out thousands of times across disciplines, and the question of what separates the tools that survive from the ones that quietly calcify is not abstract. It determines whether a field's shared computational foundation holds, or gets rebuilt expensively by the next generation who never knew it had already been solved.
The short answer: sustained institutional support follows tools that have achieved what economists of science call infrastructural lock-in, combined with a governance structure that makes funding feel safe. Neither condition alone is sufficient. Both together are close to necessary.
The tires of the research stack, not the engine
Scientific software earns sustained support when it becomes genuinely invisible in the way that roads are invisible. Nobody praises the asphalt. But when it cracks, everything stops.
Consider NumPy, the numerical computing library underpinning an enormous fraction of computational science. For most of its existence it ran on volunteer labor and sporadic grants. What changed was not the quality of the code, which had always been high. What changed was the accumulation of downstream dependencies: once thousands of other packages, and by extension millions of researchers, could not function without it, NumPy stopped being a useful tool and became infrastructure in the strict sense. At that point, funding bodies and large technology companies had a self-interested reason to keep it alive. The Chan Zuckerberg Initiative and others eventually provided multi-year support. The lock-in came first. The money followed.
Projects that don't achieve this threshold tend to stay in a precarious middle zone: too specialized to attract philanthropic interest, too widely used to die cleanly without causing pain. Bioinformatics is full of them. A pipeline tool written for a specific sequencing technology, used by perhaps two hundred labs, cited in four thousand papers, maintained by one postdoc who has since moved to industry. That's not a hypothetical. It is a description of a dozen real cases in any major genomics subfield.
What those tools lack is replacement cost visibility. The institutions that might fund them haven't had to calculate what it would cost to rebuild or replace them, and when that calculation finally gets done, usually after a crisis, the number is almost always shocking. One software sustainability study found that a single widely-used neuroimaging analysis package would cost roughly forty person-years to reconstruct from scratch. That figure, once known, changed the conversation with funders overnight.
What people get wrong: quality is not the deciding variable
The intuition most researchers carry is that good software survives and bad software doesn't. It's a comforting story. It's also largely false.
Technical quality matters at the margins, but governance structure matters more. A project with clean code, comprehensive documentation, and no formal decision-making process is more vulnerable than a messier project that has established a steering committee, a clear contributor ladder, and a policy on what happens when the lead maintainer leaves. Funders, whether government agencies, foundations, or university research computing offices, are not primarily evaluating the software. They're evaluating the institution around the software. Can we give this project money and trust it will still exist in five years? That question is answered by governance documents, not commit logs.
Take two researchers, Maria and Tom, who both release well-regarded data analysis tools in the same year. Maria's project has a GitHub repository, a mailing list, and her email address. Tom's has the same code quality, plus a formal fiscal sponsorship through a nonprofit, three named co-maintainers at different institutions, a documented release process, and a public roadmap. Three years later, Maria has taken a position at a company and her tool's issue tracker has gone quiet. Tom's tool received a two-year NSF grant renewal almost automatically, because the program officer could point to organizational continuity. Same software quality. Completely different outcomes.
Ask yourself: how many tools are you currently using whose entire governance structure is one person's university email address?
The other thing people get wrong is assuming that a large user base guarantees support. Users generate citations and goodwill. They don't generate revenue or institutional commitment unless they are organized into something with a voice: a consortium, a user group with formal representation, a commercial ecosystem that has staked its own products on the tool's survival. Passive users are not a constituency. Organized stakeholders are.
The projects that last treat governance as a technical problem from the start, not a bureaucratic afterthought for when things go wrong. Infrastructure doesn't survive on merit. It survives on legibility, the ability of an outside institution to look at a project, understand who is responsible for what, and feel confident enough to write a check. Get that structure in place early, before the original developer takes that faculty job, and the odds shift considerably. Wait until the bug reports go unanswered, and you are not saving a tool. You are performing an autopsy.