从 PostgreSQL 到 Kubernetes：开源的护城河，从来不写在代码里

引子：一场「功劳归谁」的争执

2026 年 8 月，The Register 刊出了一篇对 Michael Stonebraker 的采访。这位图灵奖得主、伯克利 Postgres 项目的发起者，被问到 PostgreSQL 为什么会赢，给出的答案颇为意外：

我们得感谢 Oracle。因为他们买下 MySQL 之后，所有人都开始担心 MySQL 的去向，而那正是 PostgreSQL 崛起的开端。

话音刚落，PostgreSQL 社区的元老 Oleg Bartunov 就发文反驳，标题毫不客气：《PostgreSQL 早在 2000 年就已经解决了「Oracle 问题」》。

他的证据是一张老照片：2000 年 3 月，PostgreSQL 核心组在旧金山第一次面对面会议，墙上的白纸写着六条原则——

• 分散的责任
• 分散的技术知识
• 非排他的合作关系
• 对项目方向的掌控权
• 保护名称
• 保护声誉

那是 2000 年。Oracle 收购 Sun、顺手拿到 MySQL，还要再等十年。

表面上这是「功劳归谁」的口水战，但它真正问的是一个更值得写的问题：一个开源项目的成功，究竟应该归因于对手的失误、创始人的远见、志愿者的劳动，还是一套从来没写进查询执行器里的制度？

这个问题，拿来照一照 .NET，会照出很多有意思的东西。

同一面镜子：.NET 也是「感谢 Oracle」的受益者

Stonebraker 说 Oracle 收购 MySQL 把用户推向了 Postgres。而 .NET Core 在 2016–2020 年的崛起，很大程度上吃的也是 Oracle 的红利。

Oracle 对 Java API 的版权诉讼、2019 年 JDK 商业许可变更、对 Java 生态的长期高压管控，把一大批企业开发者推得开始认真打量替代品。而那时恰好出现的 .NET Core，MIT 许可、跨平台、性能还猛。

所以「感谢 Oracle」这句话，在 .NET 世界几乎同样成立，甚至更直接——Postgres 接住的是数据库用户，.NET 接住的是整个企业应用栈的开发者。

但接住用户之后，两边用来「留住」用户的结构完全不同。这才是那套分析框架真正锋利的地方。

版权结构：.NET 恰恰站在 MySQL 那一侧

冯若航那篇文章里最硬核的一点是：PostgreSQL 从不要求贡献者签版权转让协议。三十年下来，版权分散在成百上千人手里，没有一个中央法人持有整份代码。

这意味着一件很朴素的事：没有任何人有资格把 PostgreSQL 卖掉。不是「不愿意卖」，是根本不存在能签字的那个主体。

对照组就在故事的另一半。MySQL AB 走的是版权集中路线：贡献者转让版权，公司持有全部权利，因此可以双许可、可以卖。于是它 2008 年被 Sun 买走，2010 年随 Sun 一起落入 Oracle 之手。社区唯一的自救手段是 fork——这就是 MariaDB 的由来。

而 .NET 的版权结构，恰恰更接近 MySQL 那一侧：核心 runtime（dotnet/runtime）的版权归 Microsoft 一家所有；.NET Foundation 旗下的项目，加入时普遍要签 CLA，把版权 assign 给基金会。也就是说，.NET 的版权是高度集中的——「单一主体可以改变游戏规则」的结构前提，真实存在。

差别在于许可证。MIT/Apache 比 MySQL 的 GPL 双许可宽容太多：最坏情况下 fork 的代价很低，而且微软无法把已发布的代码「收回去」。

所以 .NET 的风险不是 MySQL 式的「被卖掉」，而是更微妙的「开放核心化」。

2021 年的 Hot Reload 事件就是预演：微软一度把 Hot Reload 从开源的 dotnet watch 里拿掉，想留给 Visual Studio 独占。社区炸锅，几天之内回滚。那次事件的意义不在功能本身，而在于它证明了结构风险的真实存在：单一大雇主握着版权和发布管道，「厂商控制」不需要收购就能发生，一个 PR 就够了。

治理：「先有组织设计，后有钱」 vs 事后打疫苗

Tom Lane 在播客里回忆过一段往事。1999 到 2000 年间，一家叫 Great Bridge 的公司找上门，想知道怎样「以一种得体的方式」参与 PostgreSQL。

当时 core team 只有四个人。他们的第一反应不是谈条件，而是先扩容——「我们最好多拉几个人进来，这样跟他们谈的时候能代表更广的社区」。于是 Tom Lane 和 Jan Wieck 被加了进来，core 变成六人，然后才去谈。

公司的钱还没到，组织形态先改了。 这就是墙上那两行字——「非排他的合作关系」「对项目方向的掌控权」——在现实中的样子。它不是愿景，是一次针对具体一家公司的组织设计。

后来的事更能说明问题：Great Bridge 雇了 Tom Lane、Bruce Momjian、Jan Wieck，让 Tom Lane 第一次可以全职做 PostgreSQL；然后它在互联网泡沫破裂中倒闭了。

人留下了，项目留下了，公司没了。

.NET Foundation 走的几乎是反序。2014 年成立时，它实质上是微软主导的安排：创始赞助、执行董事来自微软、微软项目在基金会里权重过大。社区的不满在 2021 年集中爆发——Hot Reload 事件前后，独立董事会成员辞职，公开质疑基金会是橡皮图章。之后才有那轮治理改革：董事会改为多数由会员选举产生，微软只保留少量席位。

换句话说：

• PostgreSQL 是 2000 年预见了 Oracle 问题，提前免疫；
• .NET 是 2021 年真实发作了一次「Oracle 问题」——还是自己赞助商引发的——再事后打疫苗。

公平地说，疫苗有效：这几年基金会的独立性和透明度比 2021 年前好了不少。但免疫力的来源不同——Postgres 的免疫力来自「结构上不存在那笔交易」，.NET 的免疫力来自「制度约定 + 社区舆论的威慑力」。前者是架构，后者是治理实践。架构不太会因人事变动而退化，实践会。

生态结构：多星系统 vs 单星系统

Bartunov 那句话描述的是一种 Linux 内核式的多厂商均衡：

公司纷纷进来，投资金，雇佣黑客，有些消失了，但 PostgreSQL 依然存在。

EDB、Crunchy Data、Postgres Pro、Citus（后来进了微软）、Neon、Supabase……没有任何一家能雇佣超过少数核心 hacker，竞争反而供养了公地。

.NET 生态的结构是单星型：核心 runtime、编译器、ASP.NET 的绝大多数全职贡献者，都在微软一家公司。

好处显而易见：投入强度和方向一致性，是 Postgres 做梦都想要的。PG 社区为 JIT、为异步 I/O 争论多年的那种缓慢，在 .NET 里一个 roadmap 就解决了。

代价同样明显：整个生态的「关键人物风险」，集中在一家公司的战略意志上。

Mono/Xamarin 是个有趣的脚注：那是 .NET 世界里唯一一次真正出现「第二家公司养一套独立实现」，最后以被收购收场——多中心实验，回归单中心。

代码架构与社会架构的同构

Bartunov 文章里有一句容易被滑过去的话。他说，2000 年旧金山的黑客们在定义如何保持 PostgreSQL 的自由和分布式时，他和 Teodor Sigaev 正在莫斯科做 GiST，让 PostgreSQL 本身更具可扩展性：

我们在两个架构中构建了相同的理念：社区和代码。

这句话其实是康威定律的正面运用。PostgreSQL 把「可扩展性」同时写进了两个地方：

• 代码：GiST、FDW、hook、自定义类型——任何功能都能以扩展形式插入；
• 组织：任何公司都能以扩展商、云厂商、咨询商的身份插入生态，无需控制核心。

代码的扩展点和组织的扩展点是同构的。所以扩展生态三十年不散：PostGIS 长成了地理数据库的事实标准，pgvector 吃到了 AI 时代最大的一波红利，Timescale、Citus 各自开宗立派。这些都不是核心组「规划」出来的，而是结构允许它们长出来。

用 DDD 的语言说：PostgreSQL 的领域模型里，「社区治理」不是外部上下文，它就是核心域的一部分，而且被显式建模了——那面墙上的六条原则，就是一份写在白板上的 bounded context 划分。

而 .NET 的模型里，「Microsoft」长期是一个没有显式建模的隐式聚合根。2021 年的危机，本质上是一次模型重构：社区要求把这个隐式依赖显式化，加上防腐层。

再从 DAG 的视角看一眼两个生态的工作流投影：PG 的关键路径上，节点分散在多家公司、多个国家，DAG 天然抗单点故障；.NET 的关键路径高度收敛于一个租户，效率高、冗余低。两种拓扑各有取舍，但你得知道自己跑在哪种拓扑上。

把标尺拉远：Linux、Python 与 Kubernetes

只比 PG 和 .NET 还不够公平。把镜头拉远，看看另外几个巨型开源项目，治理这条光谱才算完整。

Linux：版权像 PG，治理靠圣人。

内核的版权结构和 PostgreSQL 同构——没有 CLA，只有 DCO sign-off，版权天然分散在成千上万贡献者手里，同样不存在能签字卖掉它的主体。但治理走的是另一条路：subsystem maintainer 金字塔，塔尖是 Linus 一个人的仲裁权。这是「个人魅力型治理」的巅峰，三十年运转得出奇地好——但它的可继承性始终是个问号。2018 年 Linus 因言行争议暂退、内核社区仓促引入行为准则，就是一次迟到的制度补课：金字塔的塔身（maintainer 梯队）足够厚，塔尖的制度化却拖到第 27 年才开始。

Python：完成了最难得的一次权力交接，却输在了资源结构。

2018 年 Guido 辞去 BDFL，社区没有内乱、没有 fork，而是通过 PEP 8016 和平过渡到五人指导委员会选举制——这是开源史上最平滑的一次创始人退出，这一点它比 Linux 强。但 Python 的软肋在别处：它是 AI 时代最大的受益语言，核心开发却长期依赖志愿者和 PSF 筹款，企业吃掉的红利与反哺的投入严重不成比例；Python 2 到 3 那场绵延十年的迁移，更是治理失误的教科书——技术上正确的决定，治理上灾难性的执行。制度继承了，供养结构没继承。

Kubernetes：唯一一次，主导厂商主动放弃了控制权。

2015 年，Google 在容器编排上占据绝对优势时，把 Kubernetes 捐给了新成立的 CNCF——开源史上几乎没有第二例：一家公司在完全可以自己主导的时候，主动放弃了控制权。对照组是 Docker 公司：死抓编排层的主导权不放，结果 Swarm 落败，整个编排战争输得干干净净。

而 CNCF 接过来之后做的事，是把 PG 墙上那六条原则从工匠行会的默契，升级成了有章程、有任期、有选举的制度工程：Steering Committee 定期选举并设厂商配额，任何一家公司不能占据多数；SIG 和 Working Group 的权责全部文档化；功能演进走 KEP（Kubernetes Enhancement Proposal）公开流程。结果是开源史上罕见的景象——AWS、Azure、GCP、阿里云这些互相厮杀的公司，在同一个公地上按规则协作，Kubernetes 成了继 Linux 之后渗透最快的基础设施层。

所以如果要给这条光谱排个序，我的判断是：Linux 和 Python 是「基本成功」——前者靠圣人和深厚的 maintainer 梯队撑着，后者证明了制度可以继承但没解决供养；PostgreSQL 是「结构性成功」——它不需要圣人，因为结构上不存在能被卖掉的主体；而 Kubernetes 可能是最成功的一个——它是唯一一个把「防止厂商控制」做成常态化例行程序的项目，纠偏不靠危机、不靠圣人、不靠结构偶然，靠的是章程、选举和流程本身。

PG 是工匠行会式的自治，K8s 是宪政式的自治。前者更纯粹，后者更可复制——事实上 CNCF 后来孵化出的整个云原生生态，证明这套宪政模板确实可以批量复制。

结语：纠偏成本

回到文章标题那个问题：PostgreSQL 是 Oracle 的失误喂大的吗？

我的看法是：Postgres 赢，不是靠 Oracle 失误；.NET 开源能走到今天，也不是靠微软开明。所有这些项目拼的是同一件事的不同版本——当厂商行为越界时，社区的纠偏成本有多低。

把这条光谱排开看：

• PostgreSQL 把纠偏成本压到接近零：版权分散、无单一所有者，厂商根本无从越界——这是结构免疫；
• Kubernetes 让纠偏成为例行程序：选举、KEP、厂商配额，异议有常规表达通道，永远不需要走到掀桌子那一步——这是制度宪政；
• Python 证明了制度可以在创始人退出后完成继承，但迟迟没解决「谁为公地付费」——这是和平继承、供养不足；
• Linux 长期依赖塔尖的个人仲裁，2018 年才开始给塔尖补制度——这是圣人治理，缓慢补课；
• .NET 靠 MIT 许可证兜底，加一个已被证明敢掀桌子、也掀得动桌子的社区。Hot Reload 事件三天回滚，就是这套机制的一次实战演习——这是危机之后补打疫苗。

真正需要警惕的，是把「这次纠偏成功了」误认为「结构上不需要纠偏机制」。Postgres 的黑客们 2000 年就懂了这个道理，所以那六条原则写在墙上；Kubernetes 在 2015 年把同样的原则写进了章程和选举；而 .NET 社区的这条原则，是 2021 年用一次真实的危机换来的——

开源的护城河，从来不写在代码里。它写在谁有资格签字、谁有权说不、以及说了不算之后社区掀桌子的成本里。

---

参考与延伸阅读

• 冯若航：《是 Oracle 的失误让 PostgreSQL 赢了吗？》（老冯云数）：https://mp.weixin.qq.com/s/-xbCSmcYT-fIGXgQuQQUow
• The Register: Postgres pioneer credits Oracle with helping his database take over the world（2026-08-19）
• Oleg Bartunov: PostgreSQL solved the Oracle problem back in 2000（LinkedIn）
• Talking Postgres: How I got started as a developer (& in Postgres) with Tom Lane（E20）
• Jolly Chen 转录 Stonebraker 图灵奖演讲片段（pgsql-hackers, 2015）