When an open source project grows past the initial maintainer-group phase, a common question surfaces: should we move to a foundation? The usual answer is "yes, for neutrality," but the foundation landscape is not undifferentiated. The Cloud Native Computing Foundation, the Linux Foundation (parent of CNCF but also its own direct projects), the Apache Software Foundation, and the Eclipse Foundation each have distinct governance models, distinct IP frameworks, distinct community norms, and distinct fee structures. Picking the wrong one for a project's needs is expensive to undo. This post is the evaluation framework I walk project maintainers through when they ask.
What "foundation-neutral" actually buys
Four things, in rough order of importance:
- IP clarity. The foundation holds the trademark, the domain, the signing keys. If the maintainer group dissolves or has internal conflict, the project continues.
- Governance predictability. Dispute resolution, contribution policies, maintainer succession — all follow the foundation's established procedures rather than ad hoc negotiations.
- Credibility signal. Enterprise adopters and downstream consumers perceive foundation-hosted projects as lower-risk dependencies.
- Operational support. Infrastructure (CI, signing, release), legal (trademarks, licenses), marketing, events.
The relative weight of these depends on the project. A small consolidated-maintainer project cares about (3). A project with many contributing organisations cares about (1) and (2). A project planning heavy infrastructure needs cares about (4).
CNCF: the cloud-native default
Launched in 2015, hosted under the Linux Foundation, CNCF is the default home for cloud-native infrastructure projects. The governance model has three stages:
- Sandbox: early-stage projects. Low barrier to entry. Indicates project has met basic alignment criteria but is not yet battle-tested.
- Incubating: project has production users, demonstrated governance, and meaningful contributor diversity. This is where most "serious" CNCF projects sit for years.
- Graduated: mature project with demonstrated stability, security processes, and maintainer breadth. Graduation is a meaningful signal.
The CNCF TOC (Technical Oversight Committee) evaluates promotion between stages. The process is documented, consistent, and takes time (typically 18-36 months from sandbox to graduated).
CNCF specifically values cloud-native relevance. Projects that don't fit the cloud-native story (for example, pure data-science tools) are not a good CNCF fit regardless of quality.
Fees: CNCF membership for corporations funds operations. Hosted projects do not pay directly but depend on member funding. For consumers, projects remain free.
Linux Foundation (direct projects)
The Linux Foundation hosts CNCF but also hosts projects directly without the CNCF maturation ladder. OpenSSF (Open Source Security Foundation), Hyperledger, and SPDX are examples. Direct LF projects work well for cross-industry collaborations that don't fit a specific sub-foundation's focus.
Governance is project-by-project. Each LF-hosted project negotiates its own governance charter. This makes the evaluation less formulaic than CNCF but more flexible for unusual project needs.
Apache Software Foundation: the long-standing standard
Apache has hosted projects since 1999. The incubator-to-TLP (Top-Level Project) path is the longstanding standard for projects that value strong community norms, merit-based governance, and clear IP handling.
The Apache Way emphasises:
- Community over code
- Meritocratic contributor promotion
- Consensus-based decision making
- Long-term sustainability over rapid growth
ASF projects tend to have stronger community governance than CNCF projects on average. They also tend to move slower. For a project whose primary concern is longevity and community health, ASF is the default. For a project whose primary concern is rapid adoption, CNCF is often a better fit.
Fees: ASF runs on donations from members and sponsors. Projects don't pay. For consumers, projects remain free.
Eclipse Foundation: the European complement
Originally focused on Eclipse IDE ecosystem, now hosts a broad range of projects including Jakarta EE (post-Java-EE-transfer from Oracle) and various automotive and IoT projects. Eclipse has a stronger European centre of gravity than the other foundations.
Governance involves committer elections, project management committees, and the Eclipse Development Process. The documentation is detailed.
Eclipse specifically handles the case of commercial-vendor-led projects well. Jakarta EE's governance balances commercial member contributions with community input in a way ASF's pure meritocracy might not.
Fees: Eclipse has a tiered membership model. Member companies contribute. Individual contributors do not pay.
Evaluation framework
When a project maintainer group asks which foundation to consider, I ask five questions:
- Is the project cloud-native infrastructure? → CNCF is the default.
- Is the project primarily commercial-vendor-led with community input? → Eclipse is the better fit.
- Does the project value slower, community-first governance over rapid adoption? → ASF.
- Is the project cross-industry security or policy collaboration? → Linux Foundation direct.
- Does the project need non-US legal structure? → Eclipse has European advantages.
A project that matches multiple categories usually has a dominant one; that's the starting point.
The cost of moving
Foundation adoption is not free from the project's perspective. Trademark transfer is negotiable but non-trivial. Contributor License Agreement (CLA) requirements may require re-signing. Release infrastructure migration can be six months of engineering effort.
The reason to do it anyway is that the alternative — maintaining IP clarity and governance discipline on your own — is harder and more expensive long-term than delegating to a foundation.
Foundation-less alternatives
Some projects thrive without a foundation. Linux itself is Linus's trademark; the kernel has resisted foundation ownership. SQLite is public domain with a consulting-led development model. PostgreSQL has a community governance model that works well without a foundation wrapper.
These are exceptions rather than templates. For most projects growing past the initial-maintainer phase, a foundation is the right move; the question is which one.
Post-adoption work
Joining a foundation is the beginning, not the end. Projects that thrive post-adoption invest in:
- Active governance participation (attending TOC meetings, voting on issues, engaging with foundation staff)
- Clear contribution pathways (documented maintainer progression, explicit decision-making processes)
- Cross-foundation collaboration (working groups spanning CNCF, ASF, LF)
Projects that treat foundation adoption as a branding exercise get marginal benefit. Projects that engage with the foundation's processes get the full value.
How Safeguard Helps
Safeguard tracks foundation status for every open source component in the dependency graph and flags projects whose governance status has changed — move from single-maintainer to CNCF sandbox, sandbox to incubating, graduated to archived. Griffin AI surfaces projects in the dependency tree that have meaningful governance risk (solo-maintainer projects, projects in transition between foundations, projects whose TLPs have been sunset) as elevated supply chain risk. For organisations whose dependency posture relies on project governance quality, Safeguard makes the foundation signal a first-class input to risk assessment rather than a detail only visible on project README pages.