从 PostgreSQL 到 Kubernetes：开源的护城河，从来不写在代码里 - 张善友
内容提要
PostgreSQL的成功源于其2000年确立的社区治理原则，即版权分散、无单一控制者，确保无法被收购。.NET虽受益于Oracle对Java的压制，但版权集中于微软，存在“开放核心化”风险，2021年Hot Reload事件暴露此问题。开源护城河在于纠偏成本，而非代码本身。
延伸解读
版权结构决定开源项目的命运
文章指出，PostgreSQL 的成功关键在于其版权分散、无单一控制者的结构，使得任何主体都无法单方面出售项目。相比之下，MySQL 因版权集中而被收购，.NET 的版权集中于微软，存在“开放核心化”风险。这种结构差异是开源项目能否抵御外部控制的关键。
.NET 的治理风险与纠偏机制
.NET 的版权高度集中，但许可证宽松，降低了 fork 成本。2021 年 Hot Reload 事件暴露了单一大雇主控制的风险，社区舆论迫使微软回滚。文章强调，.NET 的免疫力来自制度约定和社区威慑，而非结构性保障，因此需要持续警惕治理退化。
开源治理光谱：从工匠行会到宪政制度
文章对比了 Linux、Python、PostgreSQL 和 Kubernetes 的治理模式，指出 Kubernetes 是唯一将防厂商控制制度化、常态化运行的项目，通过章程、选举和流程实现纠偏。这种“宪政式”治理比依赖个人魅力或结构偶然更可复制，是开源项目长期健康的关键。
Q&A
PostgreSQL 社区在 2000 年确立了哪些治理原则？
2000 年 3 月，PostgreSQL 核心组在旧金山第一次面对面会议上确立了六条原则，其中包括“非排他的合作关系”和“对项目方向的掌控权”，核心是确保版权分散、无单一控制者，从而无法被收购。
为什么 PostgreSQL 无法被收购？
因为 PostgreSQL 从不要求贡献者签署版权转让协议，版权分散在成百上千人手中，没有一个中央法人持有整份代码，因此没有任何人有资格把 PostgreSQL 卖掉。
.NET 的版权结构是怎样的？它与 PostgreSQL 有何不同？
.NET 的版权高度集中，核心 runtime 的版权归 Microsoft 一家所有，.NET Foundation 项目通常要求贡献者签署 CLA 将版权转让给基金会。而 PostgreSQL 的版权分散在众多贡献者手中，无单一控制者。
2021 年 Hot Reload 事件说明了什么问题？
Hot Reload 事件中，微软一度将 Hot Reload 从开源的 dotnet watch 中移除，打算留给 Visual Studio 独占，引发社区强烈反对后回滚。这证明了 .NET 存在“开放核心化”的结构风险，单一大雇主握着版权和发布管道，厂商控制不需要收购就能发生。
PostgreSQL 和 .NET 在治理上的根本区别是什么？
PostgreSQL 的免疫力来自结构上不存在能卖掉它的主体，是架构性的；.NET 的免疫力来自制度约定和社区舆论的威慑力，是治理实践。前者不易退化，后者可能因人事变动而退化。
Kubernetes 在治理上有什么独特之处？
Kubernetes 是唯一一次主导厂商（Google）主动放弃控制权的案例，它被捐赠给 CNCF，并通过章程、选举和流程将防止厂商控制常态化，例如 Steering Committee 定期选举并设厂商配额，任何公司不能占多数。
作者认为开源项目的护城河是什么？
作者认为开源的护城河不在于代码本身，而在于当厂商行为越界时，社区的纠偏成本有多低。它写在谁有资格签字、谁有权说不、以及说了不算之后社区掀桌子的成本里。
