The CNCF by the Numbers: Over 200 Projects and Growing

▶ Watch (1:39)

The CNCF’s mission is to make cloud-native computing ubiquitous. The numbers behind that mission are worth pausing on. Over 200 projects, hundreds of thousands of contributors, and hundreds of member organizations now sit under the CNCF umbrella, which itself falls under the Linux Foundation. That structure gives projects a neutral home, a documented governance structure, and a better shot at surviving beyond any single maintainer or vendor. The project count has grown sharply over the last five years, which explains why the landscape feels so large.

Maturity Levels: Sandbox, Incubating, and Graduated

▶ Watch (3:49)

Every CNCF project carries a maturity label. Sandbox is where experimentation begins. Projects move to incubating once they show momentum, more contributors, and evidence of sustainability. Graduated projects must demonstrate committers from multiple organizations, a documented governance structure, proven neutrality, and compliance with Linux Foundation Core Infrastructure Initiative best practices. Both incubating and graduated projects are considered stable and production-ready. Projects that stall can also be archived. The graduation process is slow by design. It is a marathon, not a sprint.

Reading the Landscape: Filters and the Excel Download

▶ Watch (5:36)

The landscape at first looks like a wall of logos. The filters change that. You can narrow by maturity level, category, and where a tool fits in your stack. Graduated projects like Helm and Kubernetes appear quickly. One less obvious feature: a button in the top corner lets you download all projects as an Excel file. That file shows the last time each project received a security audit. Druckman admitted it took her years of using the landscape before she noticed it.

CLOMonitor: Scoring Project Health

▶ Watch (8:22)

CLOMonitor gives each project a score based on documentation, community, security, and code practices. It turns a vague question about project health into a number. A red mark on a criterion is not a reason to discard a project. Druckman framed red marks as contribution opportunities. If a project you depend on is missing a public roadmap, that gap is a place where you can add value. CLOMonitor is also listed directly from each project’s entry on the landscape, so you can reach it without a separate search.

A Five-Step Process for Evaluating Any Project

▶ Watch (11:11)

Start by defining the problem. What part of your stack needs help? Then use the landscape filters to narrow by maturity and category. Third, check project health with CLOMonitor and OpenSSF Scorecard, and manually inspect the issue queue and security audit history. Fourth, test in a staging environment. Fifth, get involved. Opening issues counts. Small pull requests count. Then revisit, because projects evolve and the landscape changes fast. Once you depend on a project, you own it a little bit, so that ongoing review matters.

Notable Quotes

it’s more than just popularity, right? It’s it’s you have to show that this project is stable and is hopefully going to be here for the long haul. Katherine Druckman · ▶ 05:06

I like to look at the red X’s as opportunities. It’s an opportunity where maybe something in that project could be improved and maybe the person to do that improvement is one of you. Katherine Druckman · ▶ 09:09

once you take once you use a project and you depend on it, you kind of own it a little bit. Katherine Druckman · ▶ 11:28

Key Takeaways

  • Filter the CNCF landscape by maturity and category before evaluating individual projects.
  • CLOMonitor scores documentation, security, and community health in one place.
  • Red marks in CLOMonitor signal contribution gaps, not reasons to reject a project.