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 project the CNCF hosts sits at one of exactly three maturity levels: Sandbox, Incubating, or Graduated. The levels form a ladder that reflects how adopted, stable, and sustainably governed a project is. There are no other levels; if an exam option mentions a stage like alpha, certified, or archived as a maturity level, it is a distractor.

The ladder is directional. Projects typically enter at Sandbox, apply to move to Incubating as adoption grows, and finally apply to graduate. Kubernetes was the first project to reach Graduated status, followed by Prometheus. Remember the order as a sequence you can recite: Sandbox, then Incubating, then Graduated.

Movement up the maturity ladder is not automatic and is not decided by the project itself. The Technical Oversight Committee (TOC) is the CNCF body that governs project advancement. When a project applies to move from Sandbox to Incubating, or from Incubating to Graduated, the TOC evaluates it against published criteria and votes on whether it advances. The TOC also decides which new projects the CNCF accepts in the first place.

The TOC is a technical body made up of experienced practitioners from across the community, and it exists precisely so that maturity decisions are made on technical and community health grounds rather than commercial ones. Its evaluation of a graduation application looks at signals like whether committers come from more than one organization, whether the project has a defined governance process, whether it has passed security reviews and follows recognized best practices, whether it has adopted the CNCF Code of Conduct, and whether real end users run it in production.

Be careful to separate concerns here, because KCNA likes to probe the distinction. The TOC governs the technical direction of the foundation and the maturity of its projects. It does not run the day-to-day development of any individual project; that is the job of each project's own maintainers. And business matters like budgets and membership are handled by other parts of the foundation, not the TOC. If a question asks which body approves a project's graduation, the answer is the Technical Oversight Committee.

Suppose you read an announcement that a project you rely on has just reached Graduated status. What can you conclude? You can conclude that the TOC voted to graduate it after the project demonstrated broad adoption, contributors and committers spanning multiple organizations, sound open governance, a code of conduct, and attention to security. In practical terms, Graduated is the CNCF's signal that the project is stable and production-ready, and that its survival does not depend on a single company. It is the level Kubernetes, Prometheus, and other core projects hold.

Now flip the scenario. A teammate proposes adopting 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 exists to give promising new ideas a neutral home and room to innovate, with the explicit understanding that some sandbox projects will change dramatically or never advance. You would evaluate it with more caution and expect less stability.

An Incubating project sits between those signals: it has proven itself with real production users and a healthy contributor flow, and it is on the path to graduation but has not yet cleared the full bar. On the exam, expect questions phrased exactly this way: a description of a signal, such as production readiness, experimentation, or growing adoption, with the four options being maturity levels. Match production-ready to Graduated, early and experimental to Sandbox, and growing with real users to Incubating.

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: decision-making processes that are public, documented, and open to participation, so that no single vendor controls a project's direction. Two roles anchor every project. Contributors are everyone who helps the project: writing code, improving documentation, triaging issues, reviewing pull requests, or helping users. Maintainers are the trusted leaders of a project who review and merge changes, set technical direction, and are accountable for the project's health. Maintainers almost always earn that role through a track record of sustained contribution.

Kubernetes, as the largest project, organizes this at scale through Special Interest Groups (SIGs). Each SIG owns a long-lived area of the project, such as SIG Network, SIG Storage, SIG Node, or SIG Security, and runs its own public meetings, mailing lists, and backlog. If you want to change how Kubernetes handles networking, you work with SIG Network. Kubernetes also has smaller, often temporary working groups that tackle topics crossing SIG boundaries. For the exam, the trigger is simple: SIGs are how the Kubernetes community organizes work around specific areas of the project.

Community behavior is governed too. The CNCF Code of Conduct applies across CNCF projects and events and sets the expectation of a respectful, harassment-free, inclusive environment. Adopting it is part of what projects commit to as they mature, and it is one of the signals reviewed on the path to graduation. If a question asks what defines expected behavior in the CNCF community, the Code of Conduct is the answer.

Beyond the roles inside a single project, KCNA expects you to recognize the personas that make up the wider community. Contributors and maintainers you have already met: the people who build the projects and the trusted subset who lead them. Around them sit three more personas worth naming.

End users are the organizations that run cloud native technology to power their own business rather than to sell it: retailers, banks, media companies, and countless others. The CNCF cultivates an end user community deliberately, because production feedback from real adopters is exactly the evidence the TOC weighs when projects apply to advance in maturity. Vendors and member companies are the businesses that build products and services on cloud native technology, from the major cloud providers to small startups. They fund the foundation through membership, employ many maintainers, and sell support, distributions, and managed services around the projects, all without owning the projects themselves; that separation is the point of vendor neutrality.

CNCF Ambassadors are recognized community advocates: people who organize meetups, speak, write, teach, and generally spread cloud native knowledge. Ambassadors are appointed through a CNCF program that recognizes sustained community contribution, not a governance body; an ambassador does not gain any authority over projects.

Exam questions here are matching exercises. An organization that uses the technology in production but does not sell it is an end user. A person trusted to merge changes and steer a project is a maintainer. A recognized community advocate is an ambassador. Keep the personas distinct and the questions become easy points.

The cloud native community is intentionally easy to join, and KCNA expects you to recognize its main collaboration channels. Development happens in the open on GitHub, where every CNCF project keeps its code, issues, and pull requests public. Contributing does not have to mean code: documentation fixes, bug reports, issue triage, and answering user questions are all valued first contributions, and most projects label beginner-friendly issues to help newcomers start.

Day-to-day conversation happens largely on Slack. The Kubernetes Slack and the CNCF Slack host channels for individual projects and SIGs, and they are usually the fastest way to reach maintainers, follow SIG discussions, and ask questions. SIG meetings themselves are public and recorded, so anyone can attend or catch up later.

The flagship events are KubeCon + CloudNativeCon, the CNCF's major conferences held in multiple regions each year. They bring contributors, maintainers, end users, and vendors together for talks, project meetings, and hallway collaboration, and they are where much of the community's face-to-face coordination happens.

Finally, structured on-ramps exist for new contributors. Mentorship programs such as LFX, run through the Linux Foundation's LFX platform, pair newcomers with experienced mentors on real CNCF project work for a defined term. Programs like these, along with Google Summer of Code participation, are the community's deliberate answer to the question of how someone goes from interested outsider to project contributor. For the exam, recognize GitHub, Slack, KubeCon + CloudNativeCon, and LFX mentorship as the canonical ways to engage.