Open Source Isn't Open Governance

When I watch teams evaluate open source projects, I notice most of them check two things: the license, and whether the project looks active. Commits in the last month, responsive maintainers, a reasonable release cadence, stars and contributors trending the right way. Both of those signals matter - a project without an OSI-approved license carries a different risk profile than one that has one, and a project that hasn't been committed to in a year is probably not a safe bet.

But those two signals, even taken together, don't tell you much about who actually controls the project, who gets to decide its direction, or what happens if the company behind it changes its mind. That's governance, and it's the signal most evaluations skip - not because people don't care, but because it's harder to check than licensing or commit activity, and nobody has really taught them where to look.

This post focuses on the CNCF and friends - the CNCF specifically, the Linux Foundation umbrellas nearby (LF Edge, NeoNephos), and a couple of LF projects that share governance DNA. That's the neighborhood I'm invested in at the moment. There are plenty of good governance stories in other foundations and in projects outside any foundation at all, but a full tour would make this post much longer than I want it to be. The questions I end up with transfer; apply them wherever you're evaluating.

What governance actually is, and why it matters now more than ever

Governance is the set of rules determining who makes decisions about a project. Who merges code. Who decides the roadmap. What happens if maintainers disagree, or if the company behind the project is acquired or changes direction. These procedural questions are what determine whether software you depend on will still be serving you in five years.

Distributed governance - multi-vendor, auditable, with decisions made in public - has real benefits. The project outlives any one company's interest. Decisions get made by people with different perspectives, which generally produces better technical outcomes. You get a legible, predictable path for raising issues and having them addressed. And you get something harder to name: the quiet confidence that you're not betting your platform on one CEO's roadmap.

Concentrated governance - typically single-vendor, often implicit, usually fine right now - has its own benefits. Decisions are faster. Direction is clearer. There's no committee. A small team that knows what it's doing can move a project forward quickly, and plenty of excellent software has been built this way. The trade-off is that you're betting on that team's continued interest, alignment, and financial health. When those align with your own interests, it's a great bet. When they don't, you have limited recourse.

Neither are right or wrong. They are just different models that have different pros and cons in this context.

What has changed recently is that the volume of code available is about to increase dramatically. AI-assisted development is going to produce a lot more code - and a lot of that code will be published as open source by individuals or small groups who haven't put any governance structure in place, because there hasn't been time to. At the same time, existing open source projects are going to see more contributions flowing in than their maintainers can realistically review. In both cases, governance is the thing that helps. For new projects, governance is what distinguishes "published as open source" from "maintained as open source." For existing projects, the right governance structures are how you absorb a surge of contributions without losing the quality bar.

That shift is what makes governance checking more load-bearing now than it was a few years ago. "It's open source" used to carry an implicit governance signal - if something was open source, there was probably a person accountable to a community somewhere. As the total pool of open source code grows faster than the pool of accountable maintainers, that implicit signal weakens. Foundations are one of the more reliable ways to tell the difference between "open source with real stewardship" and "open source with whoever is around."

That's the context this post is set in.

CNCF project governance, explained

The CNCF hosts projects at one of three maturity levels: Sandbox, Incubating, and Graduated. All three carry the same "CNCF project" label, but they represent different stages of governance development, and understanding the difference is most of what governance evaluation at this foundation comes down to.

Let me describe what each of them represents, less as a CNCF process description and more as what it means for you if you're adopting.

Sandbox is the entry rung. Getting into Sandbox is not nothing. You donate your code and IP to a vendor-neutral foundation. You accept the CoC, the trademark policy, the whole framework. That's a real signal - the project is saying, in public, "we want to play the governance game." Most projects that start private never make it this far, and most that get to Sandbox are genuinely trying.

What Sandbox doesn't tell you is whether the hard work has happened yet. And the hard work is getting other companies involved - people from different places with merge rights and accountability, actually shaping the project's direction. That work is harder than it sounds. It's always easier for a company to consume something and trust it'll stay maintained than to put engineering time into maintaining it themselves. The famous xkcd 2347 about modern infrastructure depending on some random project that one person has been maintaining for years describes this perfectly, and the dynamic that produces it is the same dynamic that makes multi-vendor maintainership expensive.

So when you adopt a Sandbox project, in practice you're in bed with the company maintaining it. There's nothing intrinsically wrong with that - it's a bit like the benevolent dictator model, and plenty of excellent software has been built that way. But you should be clear with yourself that it is that model. The maintaining company's priorities are going to shape the project. If they pivot, so does it.

Incubation is where that picture starts to change. The TOC runs a real due diligence process. Adopters get interviewed. Governance gets reviewed. A project doesn't reach Incubation without showing that multiple organizations care about it enough to contribute maintainers and use it in production. This is the level where "single-vendor" starts to become "single-vendor by habit rather than by structure" - the scaffolding is there for more than one company to matter.

Graduated is where the picture has fully changed. Third-party security audit, formal governance review, sustained production adoption across diverse organizations, full TOC due diligence. Kubernetes is graduated. Kyverno graduated in March 2026, as announced by the CNCF. When you see a project at this level, somebody who doesn't work for the sponsoring company has checked the work.

None of the three levels are wrong, and neither is adopting at any of them. What matters is knowing which model you're getting, because they have genuinely different trade-offs. The question isn't "is this project mature enough" - it's "which model of governance am I willing to get in bed with, and what am I trading off in exchange for what."

And then there's the landscape

It gets more confusing than that. The CNCF Landscape is a separate thing from the list of CNCF projects. The landscape is a categorical map of the cloud-native ecosystem, and it includes CNCF-hosted projects and vendor products and other open-source projects that are not hosted by the CNCF but have a place on the map.

To the CNCF's credit, the landscape does encode the distinction visually. CNCF-hosted projects appear in large boxes with colored frames indicating their maturity level, non-hosted open source projects appear in small white boxes, and proprietary products appear in gray boxes. The landscape guide explains all of this.

The problem isn't that the distinction doesn't exist. The problem is that most practitioners never read the guide. They see a familiar logo on a page that says "CNCF" at the top, and they assume everything on that page is under CNCF governance in some form. It's not. Box size and frame color are visual cues that require prior knowledge to decode, and the unaware visitor doesn't even realize there's a distinction to decode.

The landscape is trying to serve two audiences - people looking for CNCF projects specifically, and people wanting a broader ecosystem map. A more prominent label, a filter on by default, or separate URLs would help the first group.

Why this matters at the OS layer, specifically

When we say "Linux," we actually mean two different things. There's the kernel, which is genuinely the same everywhere - the same code that Linus merges is the same code that eventually lands on your servers, regardless of distribution. Then there's the distribution, which is a set of package choices layered on top of that kernel: which init system, which libc, which package manager, which userspace utilities, which defaults, which patches. The kernel is a technical artifact. The distribution is a governance artifact. And the distribution is what you actually run.

Historically, the distinction was small enough to gloss over. Debian, Fedora, openSUSE, Arch - opinionated on packaging, but all in the mix-and-match tradition. Components were swappable, the init system was replaceable, and the distribution was opinionated without being load-bearing.

That's not true for all modern OSes. Some are more like Android than Linux. Android runs on the Linux kernel, but the parts that matter in practice - Google Play Services, the proprietary framework - are vendor-owned and close to impossible to remove. "Android is built on Linux" is technically true and practically misleading. You're running Google's OS on top of a kernel that happens to be open.

The same pattern shows up in cloud-native operating systems. Some projects genuinely inherit the mix-and-match tradition - you can replace components, swap the orchestrator, change the base distribution. Others bundle vendor-specific choices so tightly that the open-source kernel underneath is almost decorative. Both patterns can be fine depending on what you're trying to do, but they represent fundamentally different bets. In the first case, you're adopting a piece of open infrastructure that happens to have a company maintaining it. In the second case, you're adopting a company's product that happens to have an open kernel underneath. Those are not the same thing, and governance is the lens that tells you which one you're actually looking at.

This matters more at the OS layer than at higher layers because Android-style bundling is hardest to see at the OS layer. A policy engine is bounded - you know what it does, you can swap it. An OS spans thousands of packages, boot paths, and defaults. The cumulative effect of one vendor's choices can reshape "using this OS" in non-obvious ways.

And on top of that, there's an empirical observation: OS evaluation is underpracticed. Most platform teams reach into policy engines, observability stacks, ingress controllers - they've built pattern-matching instincts for those layers. Fewer teams reach into the OS, so when they do, they tend to fall back on the shallowest signals more heavily than they would for a layer they evaluate regularly.

Those two things together - the Android-vs-Linux ambiguity at the distribution level, and underpracticed evaluation - are what make governance checking at the OS layer matter more in practice than at most other layers, even if it isn't uniquely important in theory.

Where cloud-native is going, and why that amplifies the governance gap

There's one more thing worth naming, because it changes the stakes of this whole conversation.

Cloud-native, until now, has mostly been a public-cloud, single-cloud story. The CNCF landscape grew out of an environment where most people were deploying into one hyperscaler at a time, and many of the projects we rely on carry assumptions that quietly reflect that environment. This is why people who try to run cloud-native stacks in a sovereign cloud, or at the edge, or across multiple providers, keep running into seams - pieces that work beautifully on the happy path and awkwardly off it.

That's going to change. Sovereign cloud pressure is real and accelerating, driven by geopolitics and regulation. Edge is going to expand dramatically, driven by AI workloads moving closer to where the data is and by latency requirements that can't be served from a faraway region. Cloud-native is going to stop being "running on one cloud" and start being "running across a federation of environments that didn't necessarily coordinate with each other." That's the direction of travel, and the signals are already visible.

In that future, distributed governance isn't just philosophically preferable - it's structurally aligned with where the workloads are going. A project whose maintainers come from multiple organizations, deploying into multiple environments, will accommodate that diversity naturally because it reflects their own reality. A project whose decisions live inside one vendor will, over time, optimize for that vendor's environment - not out of malice, but because the people making decisions are solving their own problems. The exception is a vendor whose commercial posture is itself distributed, and those vendors exist but are rare. For everyone else, concentrated governance means the project is going to fit the single-cloud past better than the federated future.

The operating systems currently in the CNCF

At the time I'm writing this, there are three operating systems hosted by the CNCF. Three.

A note before I list them: I'm a Kairos maintainer, so I'm biased. What follows is my personal view, not the view of my employer or of the Kairos team - I'm speaking for myself. I'll try to be fair about all three projects, and where I can't be neutral I'll say so.

I'm listing them in the order they joined the CNCF, because one of the things we're going to talk about checking is intention, and intention is partly revealed by how early a project committed to this path in the first place.

• Kairos - Sandbox (accepted April 13, 2024), and the first operating system project accepted into the CNCF, as listed on the CNCF project page. Kairos is the underdog of this lineup - it's backed by a smaller company rather than a hyperscaler. Big-tech backing cuts both ways: it brings resources and influence, but those companies also retire or deprioritize projects when strategy shifts, and their weight on a project's direction is proportional to their size. An underdog project that's still here and still growing is telling you something about the conviction of the people maintaining it. Kairos is showing several of the signals the TOC looks for at Incubation; the public writeup of the current state is in the Become a Kairos adopter for CNCF Incubation post.
• Flatcar Container Linux - Incubating (accepted October 2024). Flatcar is the first operating system distribution to reach CNCF Incubation in the foundation's history, according to the CNCF announcement. Microsoft is the primary steward via the Kinvolk acquisition, with contributions from Cisco, Equinix, Wipro, and others. Flatcar cleared the Incubation bar, which means adopter interviews happened, governance got reviewed, and the project held up to external scrutiny.
• bootc - Sandbox (accepted January 2025). A Red Hat-led project for bootable OSes delivered as OCI images, building on the ostree and composefs machinery already used by Fedora CoreOS and RHCOS. Its current status is reflected on the CNCF project page. At Sandbox, the governance trajectory beyond Red Hat hasn't yet been externally validated.

All three of these projects are in the special-purpose operating system space, and I have genuine admiration for the technical work in all three. I'm looking narrowly at what their current CNCF status says about how far the multi-vendor governance process has developed. One of them has been through Incubation due diligence. Two of them haven't. That's what the shared CNCF label can flatten if you don't look past it.

The ones just outside, and what their situations teach

Part of what makes the CNCF list short at the OS layer is that several of the OSes practitioners encounter live somewhere else. Looking at the broader landscape is useful because it shows the range of governance patterns that an OS project can end up in.

• Garden Linux is built by SAP as the base for the Gardener ecosystem. Gardener was donated to the NeoNephos Foundation, a Linux Foundation initiative aligned with European cloud-sovereignty efforts, as described on the Gardener site. Being in NeoNephos is a positive signal - there's real intent there. My honest expectation is that anything claiming to be sovereign should eventually have distributed governance, because concentrated sovereignty from a single vendor is a contradiction in terms. That takes time, and that's fine; the point is that the structural direction is set up to support it.
• EVE-OS sits under LF Edge, a Linux Foundation umbrella for edge projects, as shown on the LF Edge project page. The foundation wrapper is real, but in operational practice the maintainer roster is heavily Zededa-affiliated - which is the company that donated the project. This is a common LF Edge pattern and it's not a knock on the project; it's a reminder that foundation membership at the Stage level EVE is in is a different kind of signal than CNCF Incubation.
• Talos - Sidero Labs' OS - is listed in the CNCF Landscape as a non-hosted project, in the same category of entry where commercial offerings also appear. This is exactly the situation the landscape section above describes: present on the landscape page, not under CNCF governance. The distinction is easy enough to see once you know to look for it, and easy to miss if you don't. Talos Linux itself is MPL 2.0 open source; its companion management plane Omni is source-available under BSL 1.1.
• Bottlerocket is AWS-maintained, Apache 2.0 licensed, not in any foundation. My read is that it's essentially designed for internal AWS use - which is fine; it does that job well - but the posture is closer to "internal OS with open source code" than "open source project with external contributors." It's similar in shape to Google COS, just with better visibility: a website, docs, a public repository, a changelog.
• Google COS is Google-maintained, proprietary, used inside Google Cloud across multiple services (including as the default for GKE, but not limited to it). The extent to which it's used beyond what's publicly documented is hard to say from outside Google, which is itself a governance observation. When a widely-deployed OS has almost no public surface, the governance conversation can't really start.

One observation about this whole list: neither LF Edge nor NeoNephos publishes a maturity model equivalent to the CNCF's Sandbox/Incubating/Graduated tiers. That's unfortunate, because it means the governance state of projects under those umbrellas is harder to read at a glance - you have to do the work yourself, case by case. Whatever criticism the CNCF deserves about the landscape, the maturity tiers themselves are a real contribution, and it would help the whole ecosystem if other foundations adopted something similar.

None of these are wrong. Several are serving real users in production. But when you line them up next to the three CNCF OSes, the spectrum of governance patterns becomes visible - Incubating at the CNCF, Sandbox at the CNCF, inside an LF umbrella at the NeoNephos or LF Edge level, pure single-vendor open source, single-vendor proprietary. All of them are available to you as a platform team. The question is which one you want under your workloads, for which reasons, with what expectations about what happens in five years.

What to actually look for

If you're evaluating any OS - CNCF-hosted or not - these are the signals I'd check after the license:

• Adoption. Who is actually using this in production, and are those adopters diverse enough that the project isn't serving one company's internal needs? If the only serious users are the company that maintains it, the project might be great - but you're essentially adopting their internal tool. That's a different bet.
• Supporting companies and individuals. How many organizations are contributing meaningfully, and how many people are in the maintainer role? A project with maintainers from one company isn't necessarily worse than one with five - but the structural fragility is real, and you should know which you're getting.
• Public records, not just code. It's not enough for the code to be open. Decisions, governance changes, maintainer onboarding, votes - the auditable parts of how the project is run should be visible too. GitVote is one mechanism. Public maintainer meetings with published minutes are another. The point is that an interested person can reconstruct how decisions got made without having to ask anyone privately.
• Intention to keep growing. Maturity isn't a static state; it's a direction. A Sandbox project with a dated, public trajectory toward Incubation is in a different place than one that's been at Sandbox for three years without visible movement. Ask projects about their next governance milestone - not just their next feature.

Apply those to Kairos if you're evaluating Kairos. Apply them to Flatcar if you're evaluating Flatcar. Apply them to Bottlerocket or Talos or Garden Linux with context-appropriate adjustments. The signals are the same; only the scenery changes.