当开源社区遇上70亿美元的重型锁链

想象一下，你花十年时间打磨一把万能钥匙，自信能打开任何门锁。结果有一天，一个政府大楼直接给所有门装上了同一把锁，然后花70亿美元请一家公司专门保管钥匙。这就是Oracle与五角大楼这份十年合同给我的第一印象。

这个项目在GitHub上如果有等价物，大概是一个被fork了上万次却从未被merge的PR——不是代码不好，而是决策者选择了最不透明的路径。

先说数字本身。70亿美元，十年，平均每年7亿。作为对比，Oracle在2025财年全年营收约530亿美元，这个合同相当于其年收入的1.3%左右。对五角大楼来说，这笔钱足够买两架F-35战斗机，或者支持整个开源安全审计项目运行二十年。但问题不在钱多钱少，而在于这笔钱锁定了什么。

我做开源项目这么多年，见过太多政府机构从“我们考虑采用开源方案”到“最终选择了商业闭源”的路径。每次的理由几乎一样：合规、安全、支持。但仔细推敲，这三条里没有一条成立。

合规方面，开源协议经过三十多年发展，已经形成了一套成熟的法律框架。GPL、Apache、MIT等协议都比任何商业合同的条款更清晰、更透明。安全方面，开源代码的公开审计能力远超闭源——想想Heartbleed漏洞的发现过程，是学术界和社区共同完成的，而不是靠供应商的定期报告。支持方面，Red Hat、SUSE、Canonical等公司早就证明了开源软件可以拿到企业级SLA。

但五角大楼还是选了Oracle。为什么？答案可能不在技术，而在信任结构。

Oracle的商业模式本质上是一个“责任转嫁系统”：你付钱，他们承担故障责任。开源模式则是“责任共担系统”：你使用社区力量，但需要自己或雇佣第三方来管理风险。对于五角大楼这样一个极度厌恶不确定性的组织，前者显然更“安全”——哪怕这种安全感是虚假的。

这里需要对比两个路线：一条是Oracle的“全栈锁定”路线，另一条是开源社区的“模块化组合”路线。

Oracle的路线很清晰：数据库、中间件、应用、云基础设施，全部用自己的产品。客户一旦选择，就进入了一个精心设计的“生态锁定”——迁移成本高到难以承受。五角大楼的这份合同，很可能继续沿用这个模式：Oracle提供从底层到上层的全套软件，五角大楼只需要每年付钱，不用操心技术选型、集成测试、版本兼容。

开源路线则相反：你可以用PostgreSQL做数据库，用Kubernetes做编排，用Apache Kafka做消息队列，用Prometheus做监控。每个组件都可以独立升级、替换、审计。但代价是，你需要一个技术团队来维护这套“乐高系统”。五角大楼不是没有这个能力，而是不愿意承担“自己组装”带来的政治风险。

从社区治理的角度看，这份合同传递了一个危险信号：在政府采购领域，商业闭源仍然被视为“默认选项”，而开源则被当作“需要额外论证的备选”。这不是Oracle的错，是采购流程的激励机制出了问题。负责采购的官员不会因为选择了开源而被表彰，但会因为Oracle的SLA而获得免责。这种“规避责任”的思维，比任何技术因素都更阻碍开源在政府领域的渗透。

但我也看到一些积极的变化。这份合同是十年期，不是永久绑定。如果五角大楼在十年内逐步建立自己的开源技术能力，他们完全可以在合同到期后转向开源方案。事实上，美国国防部旗下的数字服务团队（比如Defense Digital Service）已经在多个项目中采用开源技术。Oracle的合同更像是“过渡期”的妥协，而不是长期的战略选择。

另外，这个合同金额巨大，但相对于美国联邦政府每年超过6000亿美元的IT预算来说，占比不到0.1%。它不能代表整个政府技术生态的走向。真正值得关注的是，NASA、国防部、能源部等机构中，那些“小而美”的开源项目正在悄悄生长。比如NASA的OpenMCT框架，就是基于开源的前端可视化工具，已经在多个航天任务中使用。

一句话总结核心观点：Oracle拿下的不是技术胜利，而是信任结构的胜利，开源社区需要从“证明技术更好”转向“证明风险更低”，才能撬动政府这个最大的客户群。

原文链接：https://www.cnbc.com/2026/07/23/oracle-wins-10-year-pentagon-software-contract-worth-up-to-7-billion.html