开源软件一边被吸X,一边喊别停.结果

本期播客

AWS 和 Elastic 的故事

今天说一个故事, 故事的主角是 AWS 和 Elastic, 关于这两家公司在技术、利益、协议与“背叛”的现代商业大战。

如果给这个故事起个名字，可以叫作《开源世界的圈地战争》。

背后的逻辑发人深省.

为什么云厂商被视为开源公敌? 为什么开源意味着死路一条? 到底有没有解法?

第一幕：蜜月期 —— 开源的理想国

故事的开始，主角是 Elasticsearch（以下简称 ES）。它诞生于 2010 年，凭借卓越的搜索能力迅速风靡全球。它的开发者 Shay Banon 坚持使用 Apache 2.0 协议 —— 这在开源界相当于“绝对的自由”，任何人都可以拿去用、去改，甚至去赚钱。

此时，AWS（亚马逊云） 登场了。作为全球最大的云服务商，AWS 发现客户非常喜欢 ES，于是顺水推舟，在 2015 年推出了“Amazon Elasticsearch Service”。

那是一段甜蜜的时光：

• 对于用户： 点点鼠标就能用，不用自己配置服务器。
• 对于 AWS： 赚到了丰厚的托管费。
• 对于 Elastic 公司： 虽然没直接分到 AWS 的钱，但 ES 的知名度被带向了巅峰。

第二幕：裂痕 —— 谁动了谁的奶酪？

好景不长，Elastic 公司发现了一个残酷的现实：虽然我是源码的亲生父母，但钱都被云厂商卷走了。

AWS 利用其规模效应，提供的 ES 托管服务比 Elastic 公司自己的云服务更便宜、更稳定。Elastic 觉得自己成了 AWS 的“免费研发部”。

为了反击，Elastic 开始在开源的核心外围包裹一些闭源的高级插件（如安全、监控功能）。

火药味开始变浓：
2019 年，AWS 觉得 Elastic 越来越不“慷慨”了。于是，AWS 联手 Netflix 和 Expedia，推出了 "Open Distro for Elasticsearch" 。
这相当于在官方版 ES 的门外，自己盖了一个功能更全、而且完全免费的“样板间”。双方的关系降到了冰点。

第三幕：决裂 —— 协议的死亡判官

2021 年 1 月，Elastic 公司终于祭出了“大招”：改协议。

Elastic 宣布，以后所有的 ES 版本不再使用 Apache 2.0 协议，转而使用 SSPL。

SSPL 的潜台词是： “云厂商们，你们可以用我的代码，但如果你们拿它封装成云服务卖钱，你们就必须把你们整个云平台的代码也开源！”

这招“毒丸计划”直接戳中了 AWS 的肺管子。AWS 绝不可能开源自己的底层系统，这意味着它无法再合法地使用新版本的 ES 代码。

第四幕：诞生 —— OpenSearch 的“分家”

面对 Elastic 的绝杀，AWS 做出了一个让业界震惊的决定：既然你不让用了，那我就自己养。

2021 年 4 月，AWS 宣布从 Elasticsearch 处于 Apache 2.0 协议的最后一个版本（7.10.2 版）进行 “分叉”（Fork） 。

• 动作： 删掉所有 Elastic 公司的闭源商业代码，清理掉所有带有“Elasticsearch”商标的字样。
• 结果： 一个全新的、真正遵循 Apache 2.0 的开源项目诞生了 —— 这就是 OpenSearch。

从此，江湖上一分为二：

• Elasticsearch： 由原厂维护，技术更前卫，但带有商业限制。
• OpenSearch： 由 AWS 和 Linux 基金会背书，追求纯粹的自由开源，在云端天然适配。

尾声：这就结束了吗?

OpenSearch 的诞生，标志着开源界进入了一个 “后共识时代” 。它不再是单纯的技术共享，而是商业巨头之间通过代码进行的法律博弈。

现在的 OpenSearch 已经不仅仅是 ES 的替代品。它在 2026 年的今天，已经演化出了自己的 AI 搜索能力和分布式架构，走出了属于自己的路。而 Elastic 也因为这场危机，变得更加敏捷，不仅重回了部分开源阵营，还通过极致的性能表现保住了领头羊的位置。

这场战争告诉我们： 在商业的世界里，代码是免费的，但权力和利益从来都不是。

AWS 给 Elastic 带来的创伤

OpenSearch 的诞生对 Elastic 公司（下称 Elastic）而言，是一场涉及商业模式、品牌信誉、市场份额以及技术演进的全方位地震。

这场由 AWS 开启的“强制分叉”给 Elastic 带来了以下四个深远后果：

1. 商业护城河的被迫重塑（协议战争）

OpenSearch 出现的直接诱因是 Elastic 更改了协议（从 Apache 2.0 变为 SSPL）。这导致 Elastic 面临极其尴尬的舆论和市场处境：

• 丧失“纯开源”标签：Elastic 被踢出了 OSI（开源促进会）定义的开源阵营。这让许多有“开源纯度”要求的政府和大型企业开始转向 OpenSearch，因为后者坚持 Apache 2.0 协议并交由 Linux 基金会管理。
• 被迫重回开源（2024 年的妥协） ：在 OpenSearch 的竞争压力下，Elastic 在 2024 年 9 月宣布增加 AGPLv3 许可选项。这被业界视为一种“投降式回归”，试图重新赢回那些因为协议变更而流失的开发者和社区信任。

2. 云市场收入的直接流失与博弈

在此之前，AWS 每年通过托管 Elasticsearch 服务获取巨额利润，而 Elastic 只能分到极少一杯羹。

• AWS 的彻底“断供” ：AWS 将原有的托管服务全面更名为 Amazon OpenSearch Service。这意味着 AWS 的新客户默认进入的是 OpenSearch 生态，Elastic 失去了来自全球最大云厂商的“天然导流”。
• 迫使 Elastic 转型 DBaaS：Elastic 不得不投入海量资源建设自己的 Elastic Cloud，在 AWS、Azure 和 GCP 上与云巨头直接展开存量客户争夺战。

3. 技术发展的两极分化（性能与 AI）

为了应对 OpenSearch 的威胁，Elastic 采取了 “技术压制” 战略：

• 研发加速与性能鸿沟：Elastic 投入了大量研发资金优化核心代码。根据 2024-2025 年的多项基准测试（如 Elastic 官方发布的报告），Elasticsearch 在向量搜索（Vector Search） 和日志分析上的性能比 OpenSearch 快 40% 到 140%，向量搜索甚至快 2-12 倍。
• AI 功能差异化：Elastic 将最先进的 AI 模型（如 ELSER） 、自动化运维（Autoscaling）和高级安全审计功能放在了其商业版中。而 OpenSearch 虽然也在追赶，但在“开箱即用”的高级功能上通常滞后半年到一年。

4. 生态系统的彻底撕裂

原本统一的 ELK 生态现在分化为两个不兼容的阵营：

• 工具链脱钩：Elastic 旗下的 Kibana、Logstash、Beats 开始对 OpenSearch 进行功能性兼容屏蔽（例如增加版本检测提示），迫使 OpenSearch 开发了 OpenSearch Dashboards 等替代工具。
• 人才池分裂：招聘市场上现在明确区分“Elastic 专家”和“OpenSearch 运维”，增加了企业的人才选型成本，但也促使 OpenSearch 建立了自己的认证体系，削弱了 Elastic 认证的权威性。

总结：后果评估表