CNCF Community, Project Maturity Levels, and Open Source Governance

The Cloud Native Computing Foundation, almost always shortened to CNCF, is a nonprofit organization that hosts and supports open source cloud native projects. It is not an independent entity: the CNCF is a project of the Linux Foundation, the larger umbrella organization that hosts many open source foundations and initiatives. When KCNA asks who the CNCF belongs to, the answer is the Linux Foundation.

The CNCF was founded in 2015, and its seed project was Kubernetes. Google donated Kubernetes to the newly formed foundation, making it the first project the CNCF ever hosted. This donation is the defining origin story of the foundation: rather than one company controlling the most important container orchestrator, a neutral foundation would hold the trademark, host the code, and guarantee open governance. Prometheus, the monitoring system, was the second project to join.

That word neutral is the key to understanding why the CNCF exists. The foundation describes itself as a vendor-neutral home for cloud native open source software. Companies that compete fiercely in the market, including every major cloud provider, collaborate on CNCF projects because no single vendor owns them. The foundation holds project trademarks, funds infrastructure and events, and enforces governance rules so that a project's direction is set by its community of maintainers rather than by any one company's product roadmap.

For the exam, anchor three facts: the CNCF is part of the Linux Foundation, Kubernetes was its first project, and its core purpose is to provide vendor-neutral stewardship for cloud native open source projects.

Every active CNCF project sits at one of three maturity levels: Sandbox, Incubating or Graduated. The levels form a ladder that reflects how adopted, stable and sustainably governed a project is. Labels such as alpha, beta, stable or certified are not CNCF maturity levels; they describe software releases or products, not a project's standing in the foundation.

Read the table as a series of raised bars. Incubation is about proof that people outside the founding team use the project and contribute to it. Graduation adds the things that make a project safe to depend on: it is running in production, no single employer controls it, and an outside party has reviewed its security. A project whose maintainers all work for one company cannot graduate, however popular it is.

The ladder is directional. Projects usually enter at Sandbox, apply to move to Incubating as adoption grows, and later apply to graduate; a project that already meets the incubation bar can apply to join directly at Incubating instead. Kubernetes was the first project to reach Graduated status, followed by Prometheus.

Archived is a status, not a fourth level

Archived is where a project goes when it is no longer active or no longer recommended, for example after years without releases or maintainer activity. It is not a rung above or below the other three: a project at any level can be archived, and archiving takes it off the ladder rather than moving it along it. The archiving process is covered in the next section with the rest of the TOC's decisions.

The Technical Oversight Committee (TOC) decides which projects the CNCF accepts and when they move between maturity levels. When a project applies to join, to move from Sandbox to Incubating, or from Incubating to Graduated, the TOC reviews it against published criteria and votes; moving up a level needs a two-thirds supermajority of the TOC. Projects cannot promote themselves, and neither can CNCF staff or member companies.

The TOC is a technical body of experienced practitioners, and it exists so that maturity decisions rest on technical and community health rather than commercial interest. It does not run any project day to day; each project's own maintainers do that.

The other bodies you will see named

Several groups sound alike, and KCNA uses them as near-twins. Each has one job:

The split is technical versus business: anything about which projects the CNCF hosts and how mature they are goes to the TOC, while anything about how the foundation spends or raises money, such as membership fees or a marketing campaign, goes to the Governing Board. The Kubernetes Steering Committee governs only Kubernetes and has no say over other CNCF projects' maturity.

Archiving a project

When a project has gone inactive, anyone can raise it and the TOC reviews it; archiving also needs a two-thirds TOC vote. An archived project loses CNCF support services such as the service desk and may no longer advertise the maturity level it held. Its trademarks and domains stay hosted by the CNCF and the Linux Foundation rather than returning to the company that donated it, which protects users from a former project name being reused for something else.

Suppose a project you rely on has just reached Graduated status. You can conclude that the TOC voted to graduate it after it showed production use by independent adopters, maintainers spanning at least two organizations, open governance and a completed third-party security review. In practice, Graduated is the CNCF's signal that the project is stable, production-ready and does not depend on a single company. Being listed on the CNCF landscape or being backed by a large member company tells you none of this.

Now flip the scenario. A teammate proposes a project you discover is at the Sandbox level. That does not mean the project is bad; it means the CNCF considers it early-stage and experimental. Sandbox gives promising ideas a neutral home and room to innovate, with the understanding that some sandbox projects will change dramatically or never advance. Evaluate it with more caution and expect less stability.

An Incubating project sits between those signals: independent adopters are using it, its contributor base is healthy, and it is on the path to graduation but has not yet cleared the full bar. To judge how far any project is from the next level, compare it against that level's evidence in the table above rather than against its popularity or its backers.

The CNCF landscape is an interactive map of the cloud native ecosystem. It catalogs the projects the CNCF hosts, alongside related open source projects and commercial products, and organizes them into functional categories so you can see at a glance what exists in each problem space. The landscape is famous for its sheer size; it contains a very large and constantly changing number of entries, which is itself a lesson in how broad the cloud native ecosystem has become. Do not memorize counts, because they change; understand the categories.

The categories group tools by the job they do. Broad groupings include areas such as application definition and development, orchestration and management, runtime, provisioning, observability and analysis, and platforms. Within those sit the familiar functional buckets: scheduling and orchestration (where Kubernetes lives), service mesh, container runtimes, container registries, cloud native storage, cloud native networking, continuous integration and delivery, and monitoring and logging under observability.

For each CNCF-hosted project, the landscape also displays its maturity level, which makes it a practical tool for the evaluation scenarios described earlier. When you are comparing options in a category, the landscape tells you which candidates are Graduated, which are Incubating, and which are Sandbox experiments.

For KCNA, you should recognize what the landscape is, that it groups the ecosystem into categories of tooling, and that it reflects both CNCF-hosted projects and the wider ecosystem around them. Questions stay at that recognition level; you will not be asked to place a specific obscure tool into its exact category.

The CNCF requires its projects to practice open governance: public, documented decision-making open to participation, so that no single vendor controls a project's direction. Two roles anchor every project. Contributors are everyone who helps: writing code, improving documentation, triaging issues, reviewing pull requests or helping users. Maintainers are the trusted leaders who review and merge changes, set technical direction and answer for the project's health. Maintainers can work for any organization, and contributions are judged on their technical merits under the project's public process, whoever the contributor's employer is; the company that donated a project gives up control of it.

How a contributor becomes a maintainer. Each project's own governance document sets the process. Normally a contributor with a sustained record of reviews and merged changes is nominated and approved by the existing maintainers. The TOC, CNCF staff and employers do not appoint maintainers, and no certification grants the role.

Kubernetes organizes this at scale. Special Interest Groups (SIGs) each own a long-lived area of the project, such as SIG Network, SIG Storage, SIG Node or SIG Security, and own the code in that area, with public meetings, mailing lists and a backlog. A change to how Kubernetes handles cluster networking, for example, goes through SIG Network, the group that owns that code.

Community behavior is governed too. The CNCF Code of Conduct applies across CNCF projects, meetings and events. It sets the expectation of a respectful, harassment-free environment and explains how to report a problem; adopting it is also one of the criteria a project must meet to graduate. Do not confuse it with the CNCF IP Policy, part of the CNCF Charter, which covers licensing and intellectual property (for example, that project code is released under an approved open source license), or with a project's CONTRIBUTING guide and OWNERS files, which explain how to submit changes and who approves them in each directory.

Beyond the roles inside a project, KCNA expects you to recognize the personas of the wider community. Contributors and maintainers you have met. Around them sit several more.

End users are organizations that run cloud native technology to power their own business rather than to sell it: retailers, banks, media companies and many others. The CNCF cultivates an end user community deliberately, because adopter feedback is the evidence the TOC weighs when projects apply to advance. Vendors and member companies build products and services on cloud native technology. They fund the foundation through membership, employ many maintainers and sell support, distributions and managed services around the projects, without owning the projects; that separation is the point of vendor neutrality. Two vendor programs are worth recognizing: Kubernetes Certified Service Providers are companies vetted to offer Kubernetes support and consulting, and Kubernetes Training Partners are vetted training providers. Both are vendors, not end users.

CNCF Ambassadors are people the CNCF formally recognizes for community advocacy: organizing meetups, speaking, writing and teaching. A Kubestronaut is something different: a recognition for an individual who holds all of the CNCF's Kubernetes certifications. Neither title grants any authority over projects.

The cloud native community is intentionally easy to join. Development happens in the open on GitHub, where CNCF projects keep their code, issues and pull requests public; Kubernetes changes, including documentation fixes, go in as GitHub pull requests (Kubernetes does not use Gerrit). Contributing does not have to mean code: documentation, bug reports, issue triage and answering user questions are valued first contributions, and most projects label beginner-friendly issues, often as "good first issue".

Conversation runs on two kinds of channel. Slack (the Kubernetes Slack and the CNCF Slack) is the real-time channel, with channels for projects and SIGs; it is usually the fastest way to ask a quick question. Mailing lists, one per SIG and project, are the asynchronous channel for announcements and longer discussions. SIG meetings are public and recorded, so anyone can attend or catch up later.

Events come at two scales. KubeCon + CloudNativeCon is the CNCF's flagship conference, held in several regions each year, where maintainers of many projects, end users and vendors meet for project updates, talks and face-to-face work. Kubernetes Community Days (KCDs) are smaller, local events organized by community volunteers with CNCF support.

Structured on-ramps exist for newcomers. LFX Mentorship, run on the Linux Foundation's LFX platform, gives a mentee a time-boxed term of real project work with named mentors who guide and review their progress; Google Summer of Code works similarly. The Kubernetes New Contributor Workshop, by contrast, is a one-off session, often held at KubeCon, that walks newcomers through the contribution process. Recognize GitHub, Slack, mailing lists, KubeCon + CloudNativeCon and LFX Mentorship as the canonical ways to engage.