AWS计划将新项目作为Elasticsearch的分支

作者：Paul Dix / 公司，开发者
2019年3月12日

昨天，亚马逊（AWS）在其博客文章“Open Distro for Elasticsearch”中发布了自己的配套网站。在另一篇名为“Keeping Open Source Open”的博客文章中，他们提出了项目背后的动机和创建100%开源版Elasticsearch的愿望。新的开源版本直接针对Elastic的商业版本，包括安全、监控和SQL执行在内的三个主要特性。在本文中，我将论证AWS绝对有意分叉Elastic社区。我还会探讨这对Elasticsearch社区和Elastic公司的含义，并思考这对其他商业开源供应商可能意味着什么。

AWS是值得信赖的开源公民吗？

根据对AWS博客文章的随意阅读，看起来他们只有最好的意图。他们提供免费的开源版本功能，这些功能之前仅在Elastic的专有版本中可用。他们还在回应客户对Elastic在存储库中将商业许可代码与Apache 2.0许可代码混合的担忧。他们提出了开源需要开放和可用的论点。他们甚至声称这并不是分叉的意图，他们将会尝试向上游贡献他们的更改。

虽然我同意他们关于商业代码与开源代码混用是问题的观点，但我觉得这里有很多地方是不诚实的。他们不可能一时相信Elastic会接受他们的上游更改。显然，Elastic不会接受他们的贡献，因为这些贡献不在开源项目的范围内，而只在他们商业产品范围内。

除此之外，AWS还为这个项目创建了专门的网站，其中包含社区和贡献标签。他们还微妙地指责Elastic在开源项目方面表现不佳，同时在社区中玩弄花招。

...客户必须能够相信开源项目保持开放。开源项目的维护者有责任保持源代码对所有人的开放，并在中途不改变规则。当AWS和我们的客户依赖的重要开源项目开始限制访问、更改许可条款或混合开源和专有软件时，我们将投资以维持开源项目和社区。

他们的帖子试图将他们的努力置于保护开源的神圣之地，同时把Elastic（公司）推向了水坑。从所有这些来看，他们显然有意让这成为具有自己生命的分支。你不会通过发布一篇指责他们对自己用免费代码和创作培养的社区不利行为的博客文章来获得项目所有者的合作和接受你的pull请求。如果他们实际上并不打算让它成为分支，他们展示的方式非常奇怪。

更令人惊讶的是，他们选择了在项目名称中使用“Elasticsearch”。我预测他们很快就会为新项目选择一个新名称。这可能是由于Elastic的禁令或他们团队的更清晰思考。不选择一个新且独特的名称实际上是对社区的损害，因为它混淆了事情，这正是他们关于Elastic的XPack代码在公共仓库中的主要抱怨。

虽然AWS上从事这项工作的人员可能相信他们在这里所做的工作，但整个项目都被AWS明显的商业野心所玷污。以下是关于他们对开源信念的帖子中的引用：

在AWS，我们相信开源项目的维护者有责任确保主要开源分发保持开放和免费，不含专有代码，以便社区可以自由地构建项目，分发不偏袒任何一家公司。

从字面上看，许多开发者会同意这种观点。然而，AWS确保开源版本实际上确实偏袒了某一家供应商。通过开源Elastic的所有商业功能，任何能够以规模购买硬件、带宽和数据中心的公司都将比其他公司具有优势。AWS在这里比Elastic具有明显的优势。

这就像微软在90年代免费赠送Internet Explorer，声称这是为用户做正确的事情。他们利用Windows平台的垄断地位来扩大浏览器软件的分布，以取代Netscape。在这里，AWS利用他们在托管基础设施和服务中的市场领先地位，将其足迹扩展到更多的托管服务（Elasticsearch）。他们使用领导地位带来的利润来投资于构建免费软件，这在正常情况下是不切实际的。如果你结合他们的现有客户群和IAM等事物来看，这是一个垄断行为。

在亏损的情况下投资开源软件，以沉积领导者并使软件商品化，这正是谷歌在Kubernetes上所做的事情。谷歌云需要一种方式来与市场领导者AWS竞争。Kubernetes代表了在免费平台上商品化数据中心软件的完美策略。领导该平台的发展意味着谷歌能够首先推出稳固的Kubernetes产品。虽然拥有开源的Kubernetes对广大开发者来说可能是一个净正面，但谷歌仍对其开发有商业动机。顺便说一句，GKE仍然是运行Kubernetes的最佳方式，我相信他们已经通过开源策略吸引了大量客户。

最后，为什么是AWS开源这个项目？去年他们推出了DocumentDB，这是一个针对MongoDB用户的云数据库服务。它与MongoDB兼容，但并非MongoDB。因此，他们创建了一个全新的实现。为什么这个实现不是开源的，以鼓励一个健康和发展的MongoDB社区呢？我的内心怀疑家说，这是因为没有这个必要。

对所有这些，对亚马逊来说都是一笔好生意，所以这是完全合理的。然而，我更希望他们团队对这个项目的真实性质有一个更诚实的方法和现实的观点：这是Elasticsearch的一个分支。

这对Elastic和社区意味着什么？

当然，所有这些可能只是酸葡萄心理。只要AWS将所有东西都公开在Apache 2下，谁在乎他们的动机是否纯洁呢？也许吧，也许不是。我们必须考虑这可能会对Elasticsearch社区以及更广泛的开源供应商社区产生什么影响，他们将对开源和闭源的内容进行深思熟虑。

假设这会在一定程度上流行起来。这将有效地分裂社区。一旦AWS为这个项目选定一个真正的名称，你将看到关于Elasticsearch或OpenDistroES（或他们选择的任何名称）的博客文章和Stack Overflow上的问题。你将看到由Elastic和其他社区成员组织的会议，为OpenDistro（因为它几乎肯定不会在Elastic的活动上得到报道）。

在早期，社区分裂不会很大。API仍然是相同的，所以一切看起来都是一样的。然而，随着两个项目的分歧越来越大，会发生什么呢？你会得到不同的API，不同的操作能力和行为，最终是两件不同的事情。虽然这可能也不错？为软件之神提供更多软件！但这确实为那些以这些工具为职业的开发者创造了一个问题。更大的社区意味着更多的职位和展示你专业知识的机遇。

更有趣的问题是，Elastic现在将如何应对这一局面。如果他们不采取任何行动或接受所有的上游变更，我预测他们的业务将受到严重影响。我的猜测是，Elastic将转向在闭源中提供更多和更多的功能，并旨在以本地化或更可能的方式作为云仅服务或核心开源产品的附加组件提供这些功能。

到那时，那些推动愿景、功能和平台前进的Elastic开发者将主要关注闭源。然后，Elastic社区将希望AWS推动功能开发。大型项目的管理工作不仅仅是代码方面的一个重大努力。AWS真的会努力为社区提供所有可能的帮助，还是只为它的托管服务客户服务呢？

在那个时刻，AWS 做正确的事情应该是将他们新的分支贡献给像 CNCF 或 Apache 这样的基金会，以便继续发展。从长远来看，这可能对社区是最好的，但这对 Elastic 来说显然是毁灭性的，这将在 Elasticsearch 社区中引起大量的不确定性。

这对商业开源软件意味着什么？

我对这将对选择何种许可证的商业参与者产生什么影响感兴趣，以及它可能如何影响他们的筹资前景和商业可行性。从许可证的角度来看，我认为这加强了我的论点，即开源和版权许可证对社区是一种不利。我认为有必要明确区分什么是开放的，什么是商业的，商业项目应该是封闭源代码。AWS 的论点之一是代码混合是这次行动的主要动机。

还有一件非常有趣的事情，就是看看这将对基础设施空间中的其他开源初创公司产生怎样的影响。开源供应商在保留封闭代码方面是否会变得更加积极？我预测他们会的。

这一切与我们在 InfluxData 内部关于 InfluxDB 2.0 的讨论有些巧合。因为我们正在更新主要版本，我们正在重新审视一些功能，以确定我们能否将其更多地纳入开源项目。我们希望在尽可能多的地方开放，同时继续构建不断增长的业务。然而，我们希望有一条清晰的分界线，使我们的社区明白，而不造成混淆。

这场辩论的大部分内容都集中在如何构建一种商业产品，这种产品可以为我们提供某种对抗 AWS 或其他供应商的护城河，同时拥有一个提供真正价值的开源产品。当然，InfluxDB 并不像 Redis、MongoDB 或 Elasticsearch（所有这些项目和供应商都受到了 AWS 的冲击）那样历史悠久或受欢迎，但随着我们构建社区和扩大业务，我们成为一个更具吸引力的目标。

我可以肯定地说，InfluxDB 2.0 将至少像 InfluxDB 1.x 一样开放。我们已经发布了 alpha 版本，并写了关于我们试图通过 InfluxDB 2.0 实现什么的文章。我们还将我们的脚本和查询语言 Flux 从 InfluxDB 项目中分离出来，并使用 MIT 许可，以便它有自己的生命。从哲学上讲，我们倾向于为我们的开源工作选择自由许可证，并希望尽可能多地将其发布出去。

与此同时，我希望 AWS 为他们的分支选择一个新名字。如果它变得流行，我希望他们决定将其贡献给 Apache 软件基金会或其他类似的组织。这两者对 Elastic 公司来说都不会太好，但在这个时候，猫已经从口袋里出来了。Elastic 可能不得不回到起点，构建一个新的具有差异化商业提供的产品。