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

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

昨天，亚马逊 (AWS) 在一篇博客文章中发布了 Open Distro for Elasticsearch，以及其配套网站。在另一篇题为保持开源开放的博客文章中，他们论证了该项目背后的动机以及创建 100% 开源 Elasticsearch 版本的愿望。新的开源版本直接针对 Elastic 的商业版本，具有三个主要功能，包括安全性、监控和 SQL 执行。在这篇文章中，我将论证 AWS 绝对有意分叉 Elastic 社区。我还将探讨对 Elasticsearch 社区和 Elastic 公司 的影响，并思考这对其他商业开源供应商可能意味着什么。

AWS 是正直的 OSS 公民吗？

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

虽然我同意他们对商业代码与开源混合的问题的看法，但我认为这里有很多虚伪之处。他们不可能相信 Elastic 会接受他们的上游更改。Elastic 显然不会接受他们的贡献，因为它们不在开源项目的范围内，而只在他们的商业产品的范围内。

此外，AWS 为该项目设立的网站还设有单独的社区和贡献选项卡。他们还不太委婉地指责 Elastic 是开源项目的糟糕管理者，并对社区进行了诱骗和转换

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

他们的帖子试图将他们的努力置于保护开源的神圣地位，同时将 Elastic（公司）抛在脑后。从这一切中可以清楚地看出，他们完全有意使它成为一个拥有自己生命的分支。你不会通过发布一篇博客文章来指责项目所有者对其免费代码和创作所培育的社区造成损害，从而让项目所有者与你合作并接受你的拉取请求。如果他们实际上不打算将其作为分支，那么他们的表现方式非常奇怪。

更令人惊讶的是，他们选择尝试在项目名称中使用“Elasticsearch”。我预测他们很快就会为此选择一个新的名称，这要么是受到 Elastic 的停止和终止函的驱动，要么是他们的团队更清晰的思考。不选择新的且独特的名称实际上是对社区的不尊重，因为它混淆了事情，而这正是他们对 Elastic 的 XPack 代码在开放存储库中的主要抱怨。

虽然在 AWS 从事此工作的个人可能相信他们在这里所做的事情，但整个事情都被 AWS 明确的商业野心所玷污。以下是帖子中关于他们对开源信仰的引述

在 AWS，我们认为开源项目的维护者有责任确保主要的开源分发保持开放且没有专有代码，以便社区可以自由地在项目的基础上构建，并且该分发不会使任何一家公司优于另一家公司。

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

这就像 90 年代微软免费赠送 Internet Explorer，并声称这是为他们的用户做的正确的事情。他们利用其 Windows 平台垄断地位来扩大其浏览器软件的分发范围，以击败 Netscape。现在，AWS 正在利用其在托管基础设施和服务领域的市场领导地位，将其足迹扩展到其他托管服务（Elasticsearch）。他们正在利用来自领导地位的利润来投资构建免费软件，这在正常情况下是不可行的。如果你将此与他们现有的客户群以及 IAM 等事物结合起来看，这是一种垄断行为。

以亏损投资开源软件以排挤领导者并使软件商品化，这正是 Google 对 Kubernetes 所做的事情。Google Cloud 需要一种与市场领导者 AWS 竞争的方式。Kubernetes 代表了一种完美的策略，可以在免费平台上使数据中心软件商品化。领导该平台的开发意味着 Google 是第一个推出可靠 Kubernetes 产品的公司。虽然在开源中拥有 Kubernetes 可能对广大开发者来说是净收益，但 Google 仍然有其商业动机来开发它。顺便说一句，GKE 仍然是运行 Kubernetes 的最佳方式，我相信他们已经通过其开源策略获得了许多客户。

最后，为什么这是 AWS 正在开源的项目？去年，他们推出了 DocumentDB，一项针对 MongoDB 用户的服务。它在 API 上兼容，但它不是 MongoDB。因此，他们创建了一个全新的实现。为什么该实现也没有开源，以鼓励健康且不断增长的 MongoDB 社区？我内心的愤世嫉俗者说，这是因为没有必要这样做。

所有这一切对于亚马逊来说都是良好的商业行为，因此完全有道理。但是，我更希望看到一种更诚实的方法以及他们的团队对这个项目的真实面貌的现实观点：Elasticsearch 的一个分支。

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

当然，所有这一切都真的只是酸葡萄心理。只要 AWS 将所有内容公开并根据 Apache 2 许可发布，谁会在乎 AWS 的动机是否纯正呢？也许是，但也可能不是。我们必须考虑这可能对 Elasticsearch 社区以及更广泛的开源供应商社区意味着什么，他们将认真思考他们开源什么以及闭源什么。

假设这种情况继续流行。这将有效地使社区一分为二。一旦 AWS 为该项目选择一个真正的名称，你就会在 Stack Overflow 上看到博客文章和问题，这些问题要么是关于 Elasticsearch，要么是关于 OpenDistroES（或他们选择的任何名称）。你将看到由 Elastic 组织的会议，以及由社区成员为 OpenDistro 组织的会议（因为它几乎肯定不会在 Elastic 的活动中得到报道）。

早期，社区分裂不会造成太大的影响。API 仍然相同，所以一切都差不多。但是，随着两个项目越来越分歧，会发生什么？你将获得不同的 API、不同的操作功能和行为，以及最终两种不同的事物。虽然也许这也不错？更多的软件献给软件之神！但这确实给那些在这些工具上建立职业生涯的开发者带来了问题。更大的社区意味着更多的工作和展示你的专业知识的机会。

更有趣的问题是，Elastic 现在会做什么，因为这种情况已经发生了。如果他们什么都不做或接受所有这些上游更改，我预测他们的业务将受到重大负面影响。我的猜测是，Elastic 将转向在闭源中拥有越来越多的功能，并旨在在本地或更可能地，作为仅限云的服务和核心开源产品的附加组件来提供这些功能。

届时，推动愿景、功能和平台前进的 Elastic 开发者团队将主要专注于闭源。然后，Elastic 社区将期待 AWS 来推动功能开发。大规模项目的管理是一项重要的工作，不仅仅是代码方面的事情。AWS 真的会努力为社区交付一切，还是仅仅为其托管服务的客户？

届时，AWS 应该做的正义的事情是将他们的新分支贡献给像 CNCF 或 Apache 这样的基金会，以便它可以继续发展下去。从长远来看，这可能是对社区最好的事情，但这显然会对 Elastic 造成毁灭性的打击，这将给 Elasticsearch 社区带来大量不确定性。

这对商业 OSS 意味着什么？

我感兴趣的是，这会对商业参与者在选择什么许可证方面产生什么影响，以及它可能如何影响他们的融资前景和商业可行性。从许可的角度来看，我认为这印证了我的论点，即源代码可用和 Copyleft 许可证对社区是一种损害。我认为在开源和商业之间进行明确区分是必要的，商业项目应该是真正的闭源。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 可能不得不回到绘图板并构建一个新的差异化的商业产品。