Why "Working" Open Source Software Stops Being Maintained Six Months Later
When engineers add a new tool to a Kubernetes cluster, the first stop is usually GitHub. Star count, last commit date, how fast issues get answered. These are useful signals, but they barely tell you whether a project will still be alive a year from now.
The Cloud Native Computing Foundation (CNCF) currently oversees hundreds of projects, including 38 Graduated and 36 Incubating projects (CNCF's official project list, as of August 2026). If you're deciding to adopt a tool in your Kubernetes ecosystem just because "it's a CNCF project," you're only looking at half the picture. CNCF projects sit at clearly defined maturity stages, and the stage a project occupies changes how much risk you're actually taking on when you put it into production.
Many tools, including lightweight Kubernetes distributions like K3s, enter the ecosystem at the experimental "Sandbox" stage. Bringing a Sandbox-stage project into a production K3s cluster means accepting the full risk that the development team changes direction or a maintainer walks away.
Sandbox / Incubating / Graduated — Reading the Three Stages Through the Lens of "Is It Production-Ready?"
CNCF's maturity stages aren't a one-time badge; they're an actively monitored status maintained by the Technical Oversight Committee (TOC). TOC meetings routinely include due diligence for new graduation requests and follow-up tracking of already-graduated projects — "Graduated" is not a title you earn once and keep forever.
Translating CNCF's official project lifecycle definition into something practitioners can actually use, there are three main things worth checking.
- Independent production adoption: To move to Incubating, a project needs documented evidence of multiple independent adopters that the TOC judges to be of sufficient scale and quality. That's a different bar from a single company open-sourcing its internal tool.
- Committer diversity across organizations: Graduated status requires committers spanning multiple organizations. This matters because it determines whether development can continue even if the founding company gets acquired, exits, or changes strategic direction.
- Proof of security practices: Whether a project holds the OpenSSF Best Practices Badge (formerly the CII Best Practices Badge) is another useful signal. The badge is a self-certified attestation covering six categories, including vulnerability reporting processes, build reproducibility, and static analysis practices.
In other words, if you bring a Sandbox-stage project that doesn't meet these criteria into a production cluster, you should go in assuming you'll be the one handling any future migration or fork on your own.
Why Harbor's "Graduated" Status Became a Reason to Choose It
As a concrete example, look at Harbor, the container registry project. Harbor joined CNCF in July 2018, reached Incubating status that same November, and reached Graduated status in June 2020 (CNCF's Harbor project page). With vulnerability scanning, image signing, RBAC, and replication built in, Harbor sits on the critical path of production operations as a container registry — and its Graduated status became a meaningful backstop for adoption decisions.
The same trajectory shows up in other major projects. cert-manager, the certificate automation project, joined CNCF in November 2020, reached Incubating in September 2022, and reached Graduated in September 2024. The GitOps tool Argo graduated in December 2022, and the service mesh Envoy joined the ranks of graduated projects as the third project to do so, following Kubernetes and Prometheus. Kubernetes itself only reached the status of CNCF's first-ever graduated project in March 2018 after building up a documented governance structure and a committer base spanning multiple organizations.
The common thread across all of these is clear: none of them graduated simply because they had a rich feature set. They graduated because they built a structure where multiple organizations share responsibility for operating the project. When you're making a technology selection decision, what you should actually be evaluating isn't the feature list — it's whether that structure exists.
Designing a Production K3s Cluster That Absorbs This Selection Cost For You
That said, researching the CNCF maturity stage of every individual component and checking committer diversity for each one is real, ongoing operational overhead. Plenty of infrastructure teams are redoing this research from scratch every time they make a technology selection.
One way to handle this is to bake that selection cost into the underlying stack itself. Kubo provides a production-grade Kubernetes environment built on K3s with the Rancher management plane, automated certificate management via cert-manager, and standard monitoring via Prometheus + Grafana, all pre-integrated. Instead of evaluating each CNCF project one by one and assembling your own stack, you get a foundation of components with an established production track record already in place — a value proposition that sits between fully managed Kubernetes services like EKS/AKS and building everything yourself.
For industries with strict security requirements that need on-premises operation, Kubo On-Premise is also worth considering, since it lets you reproduce the same standard stack while retaining full data sovereignty. How much you can reduce the cost of re-researching CNCF maturity criteria at the stack-selection stage is a quiet but significant factor in how much bandwidth your operations team has left for everything else.
If you're currently weighing whether to bring a Sandbox-stage project into production, it's worth comparing it against Kubo's standard stack to see whether that risk is really worth taking. If you're unsure, you can also reach out via Contact Us to talk it through.
Summary
When choosing a CNCF project, GitHub star count and commit frequency are just entry-level signals. What actually matters is whether the project has reached the Sandbox, Incubating, or Graduated maturity stage — and what that stage tells you about whether multiple organizations are sharing responsibility for its continued operation. Projects like Harbor, cert-manager, and Argo didn't earn production trust through a rich feature set; they earned it through a mature operating structure.
Before you add a new piece of open source software to your Kubernetes cluster, take a moment to check what stage it's currently at. And consider putting a standard stack like Kubo on the table as a foundation that saves you from repeating that check every single time — it's one more way to protect your operations team's long-term capacity.