引子：一场「功劳归谁」的争执
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）