Lately I keep circling back to software that’s done.

Not dead. Not abandoned. Not deprecated. Done. Feature-complete. Stable. Doing exactly what it set out to do, with no urgent need to do anything else. The concept makes most engineers uncomfortable—our entire industry rests on the assumption that software must continuously evolve or die.

That assumption runs wrong, and burns people out.

The Cult of Continuous Development #

Open source has an update problem. We’ve internalized the idea that a healthy project ships frequently—new features, new releases, activity graphs that glow green. GitHub’s contribution graph literally visualizes this: green squares good, gray squares bad. A project with no commit in six months looks neglected, even when stable, secure, and doing the job perfectly.

I’ve watched this play out from both sides. At Google, I work with open-source ecosystems daily. At my previous startup, we depended on dozens of open-source libraries, and I’ll admit we evaluated project health partly by commit frequency. “Last updated 14 months ago” triggered an instinctive wariness that had nothing to do with actual code quality.

But some of the most reliable software I’ve ever used sat unchanged for years. curl had a period of remarkable stability. SQLite’s core froze essentially in place while the test suite kept growing. Unix utilities that shipped in the 1980s still work exactly as documented. None of these qualify as abandoned. Call them finished.

The Maintenance Tax on “Done” #

The concept complicates quickly. Software never reaches truly “done” in any absolute sense. Even a feature-complete, battle-tested library needs:

• Security patches when vulnerabilities surface
• Dependency updates when the ecosystem shifts
• Compatibility fixes for new OS versions, runtimes, or language specs
• Documentation updates as the surrounding context changes

The maintenance tax. Real, ongoing, almost entirely thankless work. Nobody writes blog posts about updating a CI config to support Node 22. Nobody earns conference talks from bumping a dependency version. But when nobody does it, the software quietly rots until someone files a CVE.

The 2024 Tidelift “State of the Open Source Maintainer” report found that 60% of open-source maintainers remain unpaid. Six out of ten people maintaining the infrastructure the global software industry runs on—for free. In their spare time. Often alone.

That number made me angry. Still does.

Done vs. Abandoned: A Critical Distinction #

Users struggle with this distinction, and understandably so. From the outside, a done project and an abandoned project look identical: no recent commits, no new releases, issues piling up without responses.

Intent separates them.

A “done” project carries a maintainer (or team) who consciously decided the software meets its goals. Monitoring happens for security issues. Critical bugs get responses. Stability won the vote over novelty—and some human being stands behind the silence, deliberately. An “abandoned” project has no one. The maintainer moved on, burned out, landed a job that crowds out open-source time, or simply lost interest. No monitoring, no fixes, silence by accident.

The problem? No standard mechanism exists to communicate which state a project occupies. GitHub’s archive mode—read-only repository—comes closest, but signals “dead” rather than “complete.” The gap between those meanings deserves its own signal: a way to say “this works, someone watches it, new features aren’t coming.”

The Stewardship Problem #

What happens when a “done” project’s maintainer can no longer serve as steward? A demanding new job arrives. A kid. A decade of unpaid labor finally exhausts the goodwill. (All of those qualify as entirely reasonable exits.)

The stewardship transition problem ranks among the biggest unsolved challenges in open source.

The Linux Foundation model works for massive projects with corporate backing. A small utility library used by 50,000 projects doesn’t qualify for that level of governance. Tidelift tries to bridge this gap by paying maintainers through enterprise subscriptions, but adoption remains modest relative to the scale of the problem.

The OpenSSF Scorecard project gives users a way to assess project health—valuable, but reactive. The scorecard tells you a project might carry risk; no mechanism follows to save it.

A governance middle ground remains absent: lightweight stewardship organizations that adopt mature, feature-complete projects and handle the maintenance tax without trying to turn them into something different. Not foundations. Not corporations. Something more like a trust—an entity whose sole job means keeping stable software stable.

The OpenTofu Pattern #

Community forking offers one response to the stewardship vacuum, and the OpenTofu story rewards close study. When HashiCorp changed Terraform’s license, the community didn’t just complain; they forked. OpenTofu emerged as a community-governed alternative under the Linux Foundation.

But forking costs too much. Community splits, effort duplicates, and the pattern works best for large projects with significant commercial interest. For the long tail of feature-complete libraries quietly powering modern software, forking stays impractical. Nobody forks a JSON parsing library with 100 million weekly downloads just because the maintainer went quiet.

The more common outcome degrades further: the project slowly decays. Users pin to the last stable version, unable to move forward. Vulnerabilities accumulate. Eventually someone rewrites the functionality in a new package, fragmenting the ecosystem further.

What Good Stewardship Looks Like #

My own experience at TaskRabbit shaped how I think about this. The team maintained internal forks of several “done” libraries because upstream maintainers had moved on—a terrible pattern, with every organization patching the same abandoned library in isolation, duplicating the same security fixes. Extremely common, though.

Good stewardship for done software looks roughly like this:

Transparent status communication. A machine-readable indicator—not just a badge, but something package managers and security scanners actually parse—declaring: “Feature-complete. Security maintenance active. No new features planned.”

Defined escalation paths. When the current steward can no longer serve, a documented process handles the transfer. Not informal. Documented and enforceable.

Minimal maintenance commitments. Security patches, dependency compatibility, CI maintenance—nothing more. The scope stays explicitly limited to prevent feature creep and burnout.

Funding for maintenance labor. Not donations; structured payments for defined work. Maintenance labor deserves compensation like any other real work. CORSA (the Center for Open-Source Research Software Stewardship and Advancement) explores models for this in the academic software space—a start, not a solution.

The Cultural Shift We Need #

The hardest part isn’t technical or organizational. Culture runs the problem.

We need to stop treating “no recent activity” as a signal of project failure. Stop conflating stability with stagnation. Build tools and processes that distinguish done from dead, and value the unglamorous work of keeping stable software stable.

This conflicts with how most engineers think about career growth, and I know it. Nobody gets promoted for maintaining a library that already works. The incentive structures—at companies, in open source, in the broader industry—reward novelty over stewardship.

Worth fixing. Because the software we depend on most rarely ships weekly; it shipped years ago and hasn’t broken since. The people keeping it that way deserve better than a gray contribution graph and a growing pile of GitHub issues.

Done doesn’t mean dead. Without sustainable stewardship, though, it eventually will.