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.