 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Working in open source software (OSS) sometimes feels like running on a treadmill that never stops. The projects you depend on keep moving, but if you miss a step, you get flung off the back. For many developers, it’s an endless race to keep up with shifting dependencies, urgent common vulnerabilities and exposures (CVEs) and new features.
But not all open source moves at that speed. It exists on a spectrum from fast-moving, feature-rich projects to quietly abandoned ones. In between lies the most overlooked category: software that is simply “done” and ready to graduate into long-term stewardship.
“Done” software should be celebrated. It finally lets developers step off the treadmill without worrying that the ground will shift beneath them.
Not every open source project requires a sprint forever. Some reach a point where the core functionality is complete, the design is stable and the user base is satisfied. “Done” projects become quiet infrastructure that’s dependable and predictable, and only requires occasional maintenance.
Ingress-nginx is an example of a project that was “done” long before the community realized it. It’s one of the most popular open source ingress controllers for Kubernetes, powering billions of requests in data centers and home labs all around the world. Despite its massive adoption, the project never had more than one or two maintainers who contributed to it in their spare time. Just last month, the Kubernetes community announced its decision to archive the project in March 2026.
When a project reaches the “done” phase, it’s an achievement. The code is stable, the design is sound and the community relies on it. These projects are the foundation of a healthy, long-lasting ecosystem, which means they still need occasional upkeep so the community that depends on them can use them securely.
A surprising number of open source projects today have only one or very few maintainers. When that maintainer wants to step away, people still depend on the project, but no one is formally responsible for its long-term care.
Last year’s xz-utils incident showed us what happens when there isn’t a path for handing off projects safely. When xz-utils’ original maintainer — an individual who had dutifully managed its upkeep for 20 years — wanted to step away, a new contributor gradually earned trust, only to nearly slip in a sophisticated backdoor. If that attack had succeeded, it could have taken down almost every major system.
We need a way for open source maintainers to gracefully hand off “done” projects even when they no longer have a significant feature roadmap. We need to offer them a place where:
This graduation should signal that the project is stable, valuable and ready for a long life supported by shared responsibility.
Putting a fork in abandoned software is how the community can bring it back to a “done” state. Kaniko is one of the clearest examples of this. When Chainguard forked and took over its maintenance, we inherited a tool that was already doing its job well, which thousands of people relied on. We stepped into the role of long-term custodians for something that was effectively complete. Kaniko required predictable, responsible oversight with occasional updates and minor patches every year. It didn’t need new features. Today, when teams want new features, they can fork Kaniko from a trusted source and build those features themselves.
Forks offer a path for teams to build on a stable foundation without disrupting the project’s core purpose. They preserve user choice, prevent burnout and allow innovation without destabilizing the core. Most importantly, they ensure that open source remains open and free to evolve wherever the community needs it to go.
Open source will always have projects that sprint forward and projects that fall behind, but the future of a healthy ecosystem is ensuring mature software has a safe place to land. By establishing graduation paths for “done” software, empowering maintainers to step away safely and encouraging organizations to take on long-term custodial roles, we can prevent the next xz-utils scare.
If working in OSS sometimes feels like running on a treadmill, then “done” software is the rare moment when the pace finally eases. By embracing sustainable stewardship and welcoming forks as part of the open source life cycle, we can build a future where stepping off the treadmill is a sign of success, not failure.
