CNCF 毕业项目与孵化项目的治理差异是什么

CNCF 的“孵化”和“毕业”不是两套由基金会统一规定的公司式管理制度。更准确的理解是：孵化项目正在证明稳定性、采用度和社区治理能否持续；毕业项目则需要把治理与 committer 流程明确写出来，并拿出组织多样性、技术成熟度、安全和采用者等更完整的证据。日常技术决策仍由项目维护者负责，TOC 主要负责成熟度评估、指导和必要的冲突协调。

官方资料入口：https://www.cncf.io/projects/

判断一个 CNCF 项目是否适合采用，不能只看“毕业”两个字；应重点看治理规则是否被实际使用、单一组织退出后项目能否继续，以及公开证据是否覆盖你的生产风险。

先分清：等级变化不等于换一套“官方管理制度”

CNCF 的项目生命周期把孵化视为从实验走向稳定的阶段，项目要逐步证明核心能力、版本化接口和生态采用正在形成。毕业则代表项目在稳定性、功能完整度、社区参与、安全和生产采用方面达到了更高的成熟度。它是一个成熟度信号，不是 CNCF 替项目任命技术负责人。

CNCF 不要求所有托管项目使用同一种治理模型。项目可以采用维护者委员会、指导委员会或其他适合自身规模的安排，但到了毕业阶段，治理和 committer 的职责、选任、决策与退出方式必须足够清晰，让贡献者和采用者能够理解“谁能决定什么”。

治理差异主要体现在四个可观察面

把两个阶段放在一起比较时，最有用的不是寻找一条“毕业后必须改成某种组织架构”的规则，而是检查证据是否从“有规则”变成“规则长期有效”。

因此，“孵化项目治理较弱、毕业项目治理统一”都是过度简化。一个孵化项目可能已经有很成熟的维护者制度；一个毕业项目也可能在规模扩大或关键公司退出后重新面对治理集中问题。

用一张检查表判断项目是否更接近毕业

如果你正在评估某个 CNCF 项目，可以沿着下面四组证据阅读它的仓库和公开讨论。重点是“是否发生过”，而不是“是否写过一句口号”。

• 项目内部运行：能否找到维护者职责、审查权限、贡献者晋升标准，以及真实发生过的提名、接任或决策记录？
• 组织与继任：核心维护者是否来自多个组织？如果最大贡献组织暂时停止投入，项目是否还有独立的技术和治理承接者？
• 范围与边界：项目包含的子项目、插件或参考实现是否有清楚的成熟度、进入和退出规则？不要把主仓库的治理文件自动当成所有子项目都已覆盖。
• TOC 评估证据：申请升级时是否准备了技术审查、治理审查和采用者访谈？毕业申请还要关注安全审查及高风险发现的处理状态。

CNCF 的流程要求项目提交自评技术审查、自评治理审查，并准备 5—7 位愿意接受访谈的采用者。TOC 的 Due Diligence 会把这些材料与公开仓库、发布流程、治理实践和项目范围放在一起看。它回答的是“项目是否达到该成熟度的预期”，不是替采用者做全部技术选型。

对采用者来说，孵化和毕业该怎么选

孵化项目适合技术方向明确、团队愿意承担验证成本的试点。引入前要重点确认版本兼容、维护者响应、升级路径和关键依赖，不要把 CNCF 托管误认为稳定性承诺。

毕业项目通常能提供更强的成熟度信号，适合把评估重点转向具体的生产约束：安全响应是否透明、发布节奏是否符合你的变更窗口、组织均衡机制是否真的覆盖代码维护，以及项目的治理规则是否与你的合规和长期参与方式相容。

最后保留一条项目级复核：成熟度等级缩小了筛选范围，却不能代替你查看目标版本、依赖链、运维能力和退出方案。对关键基础设施，治理证据与技术证据应该一起进入采购或架构评审。

常见疑问

毕业项目是不是由 CNCF 直接管理？

不是。项目维护者负责日常项目管理和技术决策，CNCF TOC 负责成熟度流程、评估和必要的指导。基金会的成员身份也不等于对项目决策拥有控制权。

孵化项目一定不能用于生产吗？

不一定。孵化表示项目仍在证明更广泛的稳定性、采用度和治理成熟度。是否进入生产要结合版本、团队能力、回滚方案和业务风险判断。

有 GOVERNANCE.md 就代表治理成熟了吗？

不能。文档只是入口，还要看选任、决策、继任和组织均衡机制是否被实际使用，并且权限、代码审查规则和公开记录是否与文档一致。

一句话总结：孵化到毕业的核心变化，不是换成一套 CNCF 统一模板，而是治理从“有规则”走向“规则被持续执行，并能经受组织变化、外部审查和真实采用者检验”。