Introducing Chainguard EmeritOSS: Sustainable stewardship for mature open source
There’s a category of open source projects we don’t talk about often: the ones that aren’t racing ahead anymore because they’ve already reached maturity. These projects aren’t always abandoned, but they’ve fulfilled their purpose, become foundational to customer workloads, and no longer require a roadmap of sweeping changes. What they need is safe, predictable maintenance after their creators have moved on.
This issue of long-term OSS sustainability is something the community has grappled with for decades. How do we keep essential OSS safe and supported when its maintainers are ready to step away, or the project no longer needs constant upkeep?
Today, we’re thrilled to announce a new program that addresses this challenge: Chainguard EmeritOSS, the most viable model we’ve seen for supporting mature open source projects and long-term OSS sustainability for the community.
Why stability matters for mature software
When maintainers step away from projects that have been widely adopted, the software they built often remains deeply embedded in downstream systems, creating challenges for teams that still rely on it. Last year’s xz-utils incident demonstrated how severe the consequences can be when there’s no clear path for maintainers to step away safely. When the original maintainer wanted to retire after 20 years of commitment to the project, a new contributor gradually gained trust and then nearly introduced a sophisticated backdoor that could have compromised countless systems across the industry.
Without a structured transition model, organizations that depend on these mature projects are left vulnerable. EmeritOSS helps fill this gap. It provides a secure, stability-focused, safe landing for essential open source projects that don’t need new features but do require ongoing care.
How EmeritOSS provides OSS sustainability
EmeritOSS provides stability-focused maintenance for select unmaintained and archived open source projects so teams who depend on these projects can plan their next steps. We offer various levels of support depending on community expectations and the project’s lifecycle, including:
Creating a public fork of the project to preserve ongoing access to the codebase. These are not hostile forks—our goal is continuity, not competition.
Updating dependencies to fix vulnerabilities and creating new releases with the updates.
Publishing clear documentation outlining support scope and service levels.
Building EmeritOSS projects from source and adding them to our image catalog when needed, along with updated APK packages where applicable.
We won’t support new feature development or proactively engage with community issues or pull requests because these projects are mature and don’t require it. Our job is to keep them safely in that state.
Our forked, stability-focused versions will remain freely available on GitHub in source form only. Organizations that prefer a secure, continuously maintained container image or APK can opt for our commercial distribution.
Our early inductees: Kaniko, Kubeapps, and ingress-nginx
In June 2025, when Google announced it was archiving the Kaniko project, some of our customers reached out to tell us how disruptive the change was to their workflows. We stepped in with maintenance-only support on our fork of Kaniko to help them safely use or transition away from Kaniko over time. It quickly became clear that many other teams required similar support for Kaniko.
Kaniko is not an isolated case. Many customers have brought us archived or unmaintained projects that remain essential due to compliance needs, pipeline fragility, or deeply embedded dependencies. Today, we’re adding two additional inductees into the EmeritOSS program: Kubeapps and ingress-nginx, two beloved tools whose maintainers have reached natural lifecycle transitions. As part of the program, we’re allowing these projects to stay secure and operational for teams who depend on them.
“"Having the possibility to get a supported ingress-nginx allows us to spend more time evaluating the plan to move teams to another ingress controller or gateway api. Chainguard’s decision to take on the maintenance of ingress-nginx gives us confidence that we can continue to operate securely. It’s great to see an organization step in to support critical OSS in a way that respects maintainers and protects users at the same time.”
Looking ahead
As a company with a deep history in open source, we know the pressures on both maintainers and the teams that depend on their work and we’re committed to supporting the community. Chainguard contributes upstream, participates in critical OSS security efforts like on-call rotations for Sigstore, and funds initiatives such as the GitHub Secure Open Source Fund. We know how hard it is when critical open source software becomes unmaintained.
Without a path for mature software to transition into safe, long-term stewardship, the entire ecosystem absorbs unnecessary risk. With EmeritOSS, we’re creating a stable and predictable home for projects that have reached this stage. With Kaniko, we’ve already delivered CVE fixes, dependency updates, and maintained commercial images to keep customer workloads running safely during their migration period. Kubeapps and ingress-nginx will receive the same stability-focused care.
Our goal isn’t to evolve these projects, but to strengthen the sustainability of OSS itself and provide teams with a secure, predictable haven while they plan what’s next.
If your organization depends on an archived or unmaintained project, we invite you to submit it for consideration so we can help keep essential OSS running safely for as long as you need it.
Share this article
Related articles
- open source
Fork Yeah: We’re Bringing Kaniko Back
Priya Wadhwa, Senior Engineering Manager, Kim Lewandowski, Co-founder & CPO, and Dan Lorenc, Co-founder & CEO
- open source
Guardcraft: A Minecraft Java Server with Zero CVEs
Erika Heidi, Staff Developer Experience Engineer
- open source
Wolfi: a new paradigm in Linux for containers
Erika Heidi, Developer Experience Engineer
- open source
Kubeburned out? Navigating the world of Kubernetes without losing your spark
Carlos Panato, Staff Software Engineer and Sascha Grunert, Senior Software Engineer, Red Hat
- open source
Unlocking efficiency and security on GitLab: On-demand images with 0-CVE packages powered by Wolfi
Batuhan Apaydin and Furkan Türkal
- open source
VEXed? Then Grype about it: Chainguard and Anchore announce Grype supports OpenVEX
Adolfo Veytia, Alex Goodman, Dan Luhring, and John Speed Meyers