Elastic使客户端库与亚马逊主导的开源分支不兼容以回击OpenSearch

在搜索和分析引擎Elasticsearch的制造商Elastic重新授权其核心产品使其不再是开源之后，亚马逊领导了一个社区努力对其进行分支。2021年7月，该项目的贡献者宣布了OpenSearch 1.0的第一个普遍可用性 (GA) 版本，这是Elasticsearch 7.10.2和Kibana 7.10.2的Apache 2.0许可分支。

似乎是对开源分支的回击，Elastic已开始使其客户端库与OpenSearch不兼容。Python客户端已更新为执行API请求，该请求将验证与Elasticsearch的连接并在未收到正确响应时引发错误。在讨论停止之前，PR收到了来自社区的40个“不赞成”的反应和一轮简短的批评。

“看到这一点令人失望，” Invenio产品经理Lars Holm Nielsen说。“你在迫使我们作为旁观者在战斗中选边站。我们开发了一个开源产品，可以轻松地与Elasticsearch或OpenSearch一起使用，然后用户可以自己选择是否需要Elasticsearch或OpenSearch。

“现在，如果我们想要OpenSearch或Elasticsearch，我们可能必须为所有用户做出选择。Elastic的这种行为和其他行为确实没有让我对Elastic以及您将来可能会做的事情有任何信心。不要把这一切都归咎于亚马逊——你已经更改了服务器许可证，你不必再采取行动。”

Elastic高级工程经理Philip Krauss在关闭对讨论的评论之前做出了回应。

“亚马逊OpenSearch是一种不同的产品，”克劳斯说。“虽然有一些共同的历史，但已经存在许多导致真正混乱和问题的差异。”

Elastic还修改了其用于Elasticsearch的.NET 连接器，以包括“首次使用前的pre-flight检查”，用户认为这不是增强功能。

Elastic高级工程师Steve Gordon表示，此更改并未破坏受支持的配置，其目的是“通过快速失败来避免消费者错误地假设他们在未经测试且可能无法按预期运行的受支持配置中明确显示这种不兼容性。”

上周，OpenSearch回应了Elastic最近导致许多客户端不兼容的变化，承诺创建一组新的客户端库，使应用程序可以轻松连接到任何OpenSearch或Elasticsearch集群：

许多在其应用程序中使用Elasticsearch和OpenSearch的开发人员也使用Elastic 维护的开源客户端库，这些库为几种流行的编程语言提供了方便的高级接口。在过去的几周里，Elastic 向其中几个客户端添加了新逻辑，这些客户端拒绝连接到OpenSearch集群或运行Elasticsearch 7开源发行版的集群，甚至那些由 Elastic自己提供的集群。虽然客户端库仍然是开源的，但它们现在只允许应用程序连接到 Elastic 的商业产品。

OpenSearch发布了一份包含十几个客户端的列表，贡献者计划为这些客户端创建分叉，以保持与所有Elasticsearch发行版的兼容性，即使是那些由Elastic制作的发行版。

“我们不建议将任何由Elastic维护的客户端更新到最新版本，因为这可能会导致应用程序中断，”OpenSearch维护者在最新的项目更新中敦促用户。

Elastic 阻止官方客户使用开源分支的决定进一步削弱了该公司在重新获得Elasticsearch许可后剩余的商誉。

“看起来Elastic已经吸取了开源带来的所有好处，现在正在吐槽，”OSI标准和政策总监Simon Phipps说。

ElasticPress.io服务的制造商10up是WordPress生态系统中最著名的Elasticsearch驱动产品之一，它仍在考虑在Elasticsearch放弃其开源许可后的下一步行动。该公司并不急于选边站。10up平台和系统副总裁Vasken Hauri表示，这场争端“不是我们在短期内（未来 2-3 年）担心的事情。”

升级到Elasticsearch 7.11+需要在继续使用Elastic的专有产品或切换到开源分支之间做出选择。Hauri表示，该公司“几乎没有利用Elasticsearch现在提供的大部分功能”，并预计当前的路线图“可能会再运行几年，而无需从Elasticsearch获取新功能。” 目前，ElasticPress WordPress 插件的6,000多名用户和ElasticPress.io服务的客户没有什么可担心的，因为Elastic与亚马逊重新开战。