瞰见｜从电厂螺蛳里看 Elastic 与亚马逊云的恩怨情仇

​

 上善若水，水善利万物而不争。—— 老子《道德经》

作者 | 狄安

Nov. 25, 2021

4200 字 | 大约需要 8 min

有利益的地方就有江湖，有江湖的地方就有恩怨。在开源界发生的关于 Elastic 和亚马逊云之间的恩怨，开源圈的人大多知道已经有一段时间了。染于苍则苍，染于黄则黄。

​

  广场，阿尔贝托贾科梅蒂 1947-48 青铜

Elastic 是在对开源的捍卫，还是在对开源的背叛？ 这是今天我们要讨论的话题。但，开始之前，先和大家分享一个与软件无关，但可能和开源有关，却是一道风味美食的故事：电厂螺蛳。

0

  陈长青和他的电厂螺狮

话说，在江西新余有个分宜的县城，县城下有个横溪村，村边有个国营电厂，九十年代初随着电厂的没落，村里有个叫陈长青的，迫于生计在电厂生活区开了大排档，为了吸引顾客，开发了一道特色炒螺蛳的排挡宵夜菜。

不曾料到的是，他的这道菜一做就是三十年，竟然做成了在当地远近闻名的电厂螺蛳，引来八方食客。随后当地居民也纷纷模仿起来，开出了各色专卖电厂螺蛳的小店，而对此他也毫不介意和大家分享经验，结果电厂螺蛳变成了当地一大特色，领导一看形势大好，直接搞起了一年一度的电厂螺蛳节，并把美丽乡村建设成了一个特色的螺蛳小镇，带动了当地一大片人的共同富裕。

​

作为一个资深吃货，在某讯视频里的美食纪录片《向着宵夜的方向》第 12 集里看到这个故事的时候，对于陈长青的电厂螺蛳我当然心有所念，但更让我念念不忘的却是在片子里的一段采访，记者问他怎么看待其他人跟风模仿他开店的事？他是这样说的：

 “人家说，同行家就是冤家。如果我去注册了电厂螺蛳商标，看起来是防止了竞争，我就封闭了。

对于那些模仿者，实际上我要感谢他们，这些一起来做电厂螺蛳的人，没有他们的帮助，我的生意也不会像现在这么好，名气也不会像现在这么大。”

老实说，他的回答是让我大吃一惊的，吃惊的是一个炒螺蛳出身的他竟然有如此高级开放的认知。而，这不就是我们这些所谓高级的开源人常说的开源精神吗？他这哪是在做一道螺蛳，开个大排档啊？这不就是用咱们开源的方法，玩了个开源项目吗？只不过他的项目就是那道菜：电厂螺蛳而已。

​

在开源的电厂螺蛳下，又如何来保持自己的竞争力呢？陈长青用自己朴素的事实做了更简单和直接的回答：我要做得比别人好吃。是的，其他卖电厂螺蛳的店，谁都会做这道菜，谁都能卖，甚至还用了他的招牌。但实际上，螺蛳加工是一个很讲究功夫的活，而陈长青保持了做电厂螺蛳这道菜中对于每一个细节的追求。他是这样描述自己做螺蛳的整个过程的：

每次原生的螺蛳清洗干净后，我都会自己手工切螺蛳尾巴，切只切到第二纹，第三个纹就太大了，新鲜的螺蛳一切一刀，水就会出来，可以感觉到很光滑，而死的螺蛳就没那么光滑，这样就可以剔除，切完尾巴，让螺蛳吐砂 5-6 个小时。然后起油锅，放小米辣，豆瓣酱，再加些十全麻辣粉是自己秘制的，最后收汁出锅，菜成。

从陈长青的描述来看，这道菜不就是一个我们开源里常用的 OpenCore 模式嘛：开源菜谱 ➕ 秘制十全麻辣粉。

​

好，到此，故事讲完。玩开源的同行们大概会明白通过这个故事我要表达什么？先暂且不表我的什么想法，回归正题。那么，Elastic 公司 到底和 AWS 发生了什么样的纷争？Elastic 又是一家什么样的公司呢？

1

 Elastic 是谁

Elastic 是业内知名的开源搜索引擎 Elasticsearch 及开源数据可视化分析平台 Kibana 基础上进行商业化的公司，它创建了一组强大的商业化软件产品 Elastic Stack，以帮助各类企业及客户构建自己的搜索引擎，同时也和数据及应用结合形成一系列解决方案如应用程序搜索、站点搜索、日志记录、指标分析等。 

​

而 Elastic 公司的成功则是完全依赖于开源的 Elasticsearch 和 Kibana 建立了一套完整的业务运营模式，基于其部署方式的不同产生了两种商业收费方式：软件产品服务订阅制 和 SAAS 云服务。Elastic 公司正是充分利用了开源社区的优势，让 Elastic 公司在过去几年的业务飞速增长，并在 2018 年成功上市于纳斯达克。

2

 Elastic 和 AWS 的情仇与恩怨

Elastic 为了适配 SAAS 云服务的模式，就发布了自己的 Elastic Cloud 产品，并利用第三方公有云的基础设施来完成了 SAAS 化的部署，然后和公有云合作向客户提供ＳＡＡＳ服务。获得收入后，再各自分得各自的利益，本来这就是通行的公有云和独立软件产品供应商之间的合作模式。而偏偏亚马逊觉得在其基础设施上也需要提供自有的搜索应用功能，于 2015 年 AWS 就在开源的 Elasticsearch 上发布了自己的 Amzon Elasticsearch Service 的云服务。

从 Elastic 最近公开的财务报表可以看到它的收入在最近二个季度都连续保持了近 40%的增长，其中 Elastic Cloud 的 SaaS 订阅收入则贡献了大部分的增长。于是，这就动到了 Elastic 的奶酪，还是 Elastic 极其重视的奶酪。正是这不断增长的 SAAS 业务和未来的潜力导致了 Elastic 和 AWS 的纷争。

​

对于亚马逊来说，他们的所作所为事实上却并没有违反任何规则。如果有侵犯的话，最大的侵犯就是在部署其自己的基于 Elasticsearch 的公有云服务时，一是以自行开发的方式来替代那部分原本需要向 Elastic 购买的付费功能，蚕食了 Elastic 的市场。二是在服务部署时顺带采用了 Elasticsearch 的名称，有侵犯商标之嫌。

所以实质上，Elastic 和 AWS 之间爆发的冲突，并不是开源社区和公有云的冲突，而只是两个商业公司之间商业利益的冲突？说穿了，这就是关于一个字的问题：钱。　

在这样的矛盾冲突下，Elastic 扛起社区的大旗，向 AWS 发起了自己的反击。首先在 2019 年以 AWS 产品中侵犯 Elastic 商标权的名义将 AWS 告上了法庭。而 AWS 的逻辑是：好吧，既然你不允许，那我就改名称。AWS 顺顺水推舟就将自己产品名称改成了 Open Distro for Elasticsearch。Elastic 的这一招显然没有阻止 AWS 在云上继续提供其自有的服务。

​

到了 2021 年的 1 月 Elastic 又出了新的一招：更改 Elasticsearch 和 Kabina 的开源许可证。因为 Elastic 发现在原来社区使用的 Apache 2.0 的许可证下，AWS 完全有合法的权利来继续基于 Elasticsearch 的开源代码开发自己的 SAAS 产品，于是 Elastic 借鉴了之前 MangoDB 用于防御公有云的做法，将 Apache 2.0 的许可证改成了服务端公用许可证协议（Sever Side Public License）即 SSPL。

SSPL 协议就是 MangoDB 为了防止公有云竞争而自行发布的一种社区级开源许可证，它的本质就是在许可证中加入了一些严格的条款让一般公有云厂商无法在开源代码上进行开发后再发布成其自有的公有云 SAAS 服务产品。SSPL 里因为存在一些歧视性的条款而被开源促进联盟（OSI）认为有违开源精神而并不予以承认， 所以 SSPL 只能作为社区级的开源许可证，而 SSPL 也被真正信仰开源的人蔑视为一种 Fauxpen 许可，即仿开源协议。

​

所谓，“道高一尺，魔高一丈。” AWS 在面对 Elastic 公司修改了开源许可之后，紧接着就官方宣布了对 ElasticSearch 社区进行分叉。AWS 这次的逻辑是：既然你通过开源许可的变更来限制我在公有云上的自有 SAAS 产品服务的发布，那么我就在你 Apache2.0 协议许可下已经发布的开源代码基础之上再衍生成立一个新的分叉社区，同时把新社区起名叫 Opensearch，大家从此互不干涉，海阔太空。AWS 的产品就可以在 Opensearch 社区上以开源方式来继续新的发展。

而下一步，双方还将产生怎样的纷争，犹未可知。究其本源，Elasticsearch 社区实际上是由 Elastic 公司控制的，为了对付 AWS 的竞争，Elastic 公司在开源社区里采取了有利于自己商业化公司的许可规则修改来阻止这种竞争的发生，从公司的角度来说无可厚非。但我们要问的是 Elastic 在这个过程中，到底代表了谁的利益？实际上他担心的并不是社区的利益受损，而更多的只是自己商业化公司的利益受损。它的做法最后让原本的社区分叉成两个。而从社区的角度来说，这好像本无此必要。

​

而这样的分叉，对开源社区此造成的影响也是显而易见的：

更加强了商业化公司对于社区的掌控

虽然 Elastic 承诺保护社区的利益，但它的做法却让社区的开放性进一步受到了限制和损失，它只是牢牢保障了社区大众在社区里产生的贡献首先为其所用，这种做法无疑是自私的。但如果社区本来是由商业化公司建立掌控并置于商业化公司之下的，我们又能对它进行什么样的批判呢？

社区分叉导致了社区力量的分散

社区的分叉让社区的用户以后只能在两者之间做出选择，这无疑减弱了社区的力量。

唯一可以欣慰的是，AWS 在宣布了分叉的同时，明确了新的 Opensearch 社区许可将继续沿用 Apache2.0 协议。那就意味着，Openserarch 社区在继承了 Elasticsearch 社区协议变更前的那些既有开源代码后。虽然未来再也无法来获得来自 ElasticSearch 社区的后续代码更新，但是它默认了 Elasticsearch 可以毫无障碍的吸收来自 opensearch 社区的代码更新分享。从这点上来说，AWS 无疑是慷慨的。

只是不知道，在不久的将来，Elasticsearch 和 Opensearch 这两个开源社区，到底是各奔前程下的相互成就，还是本是同根生下的相煎何太急？

​

3

纷与争， 分与合

分叉的结果，对于社区来说是一个结束。但，对于商业化公司 Elastic 和 AWS 来说，分叉可能也只是下一次纷争的开始。而像 Elastic 和 AWS 这样的纷争一定还会在未来的一些开源社区继续上演。对于正在投入开源，或者将要投入开源的人们来说，值得参考的是以下两点：

参与开源社区的大众：

需要明白和清楚地了解你所在开源社区的属性，它是一个真正去中心化的社区还是一个非去中心化的社区？它是一个真正商业中立的，还是一个非商业中立的？而你又愿意将自己的开源贡献置于何处？

开源创业的企业：

需要想明白和确认你的创业是基于商业利益优先的创业精神，还是基于公共利益优先的开源精神？哪一个是你的目标？哪一个又是你的手段？

对以上的各项选择，我无意于做出任何道义上的评判。因为，这个世界的存在本来就是光谱式的，不是简单的黑和白。所以，选择，往往也就没有正确和错误之分。所谓的错误，在我看来，往往不是结果的错误，只是自己对于原先假定的错误或者是对于自己原先假定的误解。而一切事后的辩解和说明，最多也只是对于当初的那个自己所认为的哪个假定或前提的维护而已。

最后，开源是一切美好的起点，也应是一切美好的终点。

犹如 Elasticsearch，听说这是一个浪漫创业故事。十多年前，那个名叫 Shay Banon 的创始人带着新婚妻子去伦敦生活，为了方便自己的老婆在网上寻找菜谱，于是他就自己动手写了一个搜索程序，然后把它变为了一个开源软件并取名 Elasticsearch，不料成为了 Github 上最活跃的开源项目之一。

也犹如我们一开始的电厂螺蛳创始人陈长青，他可能是因为生活所迫开始了电厂螺蛳的经营生涯，却不料因此和小小的螺蛳结缘，并以朴素的开源方法和开源态度成就了自己的人生。

所以，我也宁愿相信，无论出于什么样的前提，实际上正是人性中最美好的那部分——也就是对美好本身的向往，才是让我们在这个金钱的世界里最值得珍视的东西。

不由想起那句世俗的话：当你紧握双手试图去抓住掌心里的一切时，可能什么也没有抓住；但当你放松五指、摊开掌心的那一刻，你却已经拥有了全世界。

注：封面图和文中引用图片均来源于网络，侵删。本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。

/// 关于作者 ///

狄 安

OpenTEKr 创始人 & 开源布道者

企业级软件领域的连续创业者，开源领域的独立研究者。现从事开源和数字化领域的文化研究和理念布道，及开源和商业结合的探索与实践。

/// 关于 OpenTEKr ///

OpenTEKr 是一家以推广开源软件和开放硬件技术为核心的开放式非营利组织，致力于构建一个可持续发展的开放科技生态圈。基于“众有、众享、众治”的信念，我们依循「自由与规则同在，免费与商业共生」的原则，憧憬科技普惠的美好未来，帮助个人和组织通过变革性技术创新来成就非凡自我。