写点什么

3 年后,Elasticsearch 再次开源,还与 AWS 成为关系牢固的“伙伴”!网友:OpenSearch 怎么办?

  • 2024-09-01
    北京
  • 本文字数:4195 字

    阅读完需:约 14 分钟

大小:1.94M时长:11:17
3 年后,Elasticsearch 再次开源,还与 AWS 成为关系牢固的“伙伴”!网友:OpenSearch 怎么办?

“大家熟悉的 Elasticsearch 又回来了,真是太棒啦!”Elastic 创始人兼 CEO Shay Banon 在当地时间 8 月 30 日激动地宣布:Elasticsearch 与 Kibana 已经再次回归开源怀抱。简单来讲,Elastic 将在未来几周内提供除 ELv2 和 SSPL 之外的 AGPL 许可证选项。

“Elastic 从来没有放弃过开源”?

 

当初更改许可证就是个错误,现在 Elastch 又主动反悔了?Banon 对此表示否认。

 

“三年前,我们更改许可证的行为显著缓解了市场上的混乱局面。受我们行动的影响,很多事情都发生了变化。现如今的形势已经完全不同,我们不再生活在过去,而希望能为用户创造更美好的未来。可以说,正是因为有当初更改许可证的行动,我们才有能力在今天宣布重新回归开源。”Banon 说道。

 

事情要从 2021 年说起。当年 1 月 15 日,Banon 宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

 

这是一次主要针对云服务提供商的修改。SSPL 是由 MongoDB 制定的源代码许可,旨在充分体现开源代码原则,同时要求云服务提供商在未对项目做出贡献的情况下,不得发布自己的开源产品即服务。而 Elastic License 的核心条款是如果将产品作为 SaaS 使用则需要获得商业授权。

 

这个决定自然在开源社区以及技术界引起了轩然大波,有人理解这是为了应对云厂商“白嫖”开源的措施,也有人认为这是对开源的“背叛"。Elastic 也表示,这两个项目改了许可证之后就不再是开源项目,但是它们依然具有一定的开放性,比如依然可以访问源码、可以参与协作。

 

当时,在 Elastic 宣布改变开源协议的 5 天后,Banon 解释了变更许可协议的理由:AWS 和 Amazon Elasticsearch Service。”自 2015 年以来,他们一直在做一些我们认为完全不能接受的事情,而且情况只会变得越来越糟。作为一家成功的公司和市场领导者,如果我们现在不站出来与他们抗争,那还有谁呢?“

 

“亚马逊云科技于 2015 年基于 Elasticsearch 推出自己的服务,还将其称为 Amazon Elasticsearch Service,这是很明显的商标侵权行为。NOT OK。”

 

“我在 2011 年借了一笔个人贷款来注册 Elasticsearch 商标… 看到商标如此公然地滥用,我特别痛苦。亚马逊问题迫使我们提起诉讼。NOT OK。”

 

“商标问题让用户感到困惑,以为是 Elastic 和亚马逊之间有合作,这不是真的。NOT OK。”

“… 多年来这种困惑仍然存在。NOT OK。”

 

“亚马逊云科技针对 Elasticsearch 的 Open Distro 分支,进一步分裂了我们的社区,引发了相当多的混乱。NOT OK。”

 

“… 最近,我们发现了更多挑战道德底线的例子。我们已经在专有功能方面上与众不同,现在这些设计却被视为来自亚马逊的灵感。NOT OK。”

 

可见当时的 Banon 多么气愤。对此,亚马逊云科技则表态,将在仍为开源状态的 Elasticsearch 和 Kibana( 7.10 版本)创建分支并进行维护,做到真正的开源。三个月后,亚马逊云科技便推出了 OpenSearch 项目。

 

亚马逊云科技表示,OpenSearch 虽然时基于 Elasticsearch,但是删除了其中和 Elastic 有关的商业许可证限制、代码、商标等,在采用了 Apache License 2.0 之后,OpenSearch 可以让每个用户都毫无负担的构建和创新,而不用再担心一些贡献之外的问题。该项目获得了包括红帽、SAP、Capital One 和 Logz.io 等多个组织和厂商支持。

 

在功能上,OpenSearch 和 Elasticsearch 无明显差异,随着 Adobe 等企业用 OpenSearch 取代 Elasticsearch,OpenSearch 进入 DB-Engines 数据库流行度排名前五十,因此有人认为这次分叉是成功的。如今也有人认为,OpenSearch 品牌比 Elastic 更有价值。

 

在宣布再次开源后,Banon 为这一改变做出了解释:

 

在之前饱受争议的许可证更改决定后,我们一直在努力考虑并维持开源社区的运作状态。但如今我们重拾获得 OSI 批准的 AGPL 许可证,代表着 Elasticsearch 已经正式回归开源阵营,彻底消除了人们可能抱有的任何戒心或者疑虑。

 

其实我们在 Elastic 从来就没有放弃过开源,也一直坚信开源就是软件行业的正确发展方向。我本人在开源领域的贡献周期已经有 25 年,可以说是铁杆开源卫士。既然如此,三年之前又为什么有此一变?

 

因为亚马逊云科技闹出了问题,他们的产品造成了市场混乱。因此在尝试了我们所能想到的一切手段之后,最终我们选择更改许可证,想要借此让 Elasticsearch 的不同分叉能有独立的名称和发展轨迹。总之这事一言难尽,想想都是泪……

 

好消息是虽然决定做得艰难,但却切实奏效了。三年之后,亚马逊全面投资建立起自己的分叉,市场混乱也在很大程度上得到了解决,我们与亚马逊云科技之间的合作关系比以往任何时候都更加牢固。我们甚至被亚马逊方面评为年度合作伙伴。而我们的目标也正是如此——等待一段足够长的时间,最终让我们能够放心回归开源社区。现在,时机终于到了。

 

这个解释比较模糊,反而让网友们更加疑惑:什么原因让 AWS 放弃 OpenSearch 并重新转向仅销售 Elastic?有网友分析称:“它奏效了”可能意味着 Elastic 认为这些问题已经解决或不再相关。

 

这个解释比较模糊,反而让网友们更加疑惑:是不是 AWS 放弃 OpenSearch 并重新转向仅销售 Elastic?AWS 对 InfoQ 表示项目会继续。有网友分析称:“它奏效了”可能意味着 Elastic 认为这些问题已经解决或不再相关。

 

这是真开源吗?

 

对于选择回归开源的路径,Elasticsearch 的做法就是增加了其他许可选择。

 

“我们希望让用户的生活能够尽量简单一点。我知道有些用户非常喜欢 ELv2(受 BSD 启发的许可证),也有些人选择了 SSPL 许可证(通过 MongoDB)。正因为如此,我们决定继续保留这两个选项,并额外添加新的许可证。”Banon 表示。

 

之所以选择 AGPL 而非其他许可证,Banon 解释是因为希望与 OSI 的合作能够推动开源许可领域出现更多选择。“另外,AGPL 好像跟 SSPL 和 AGPL 的韵脚对得上,念起来更加上口。不管怎么说,AGPL 对于我们这样的基础设施软件已经足够了,而且自从我们更改许可证以来,很多情况已经发生了变化(比如 Grafana 就从 Apache2 转移到了 AGPL)。”

 

但对于 AGPL 许可,有专家解读称,如果不公开代码,即使公司内部也不可以用。这实际上对一些开发者来说变得更加严格。

 

对于”AGPL 不是真正开源”的说法,Banon 的解释是,“AGPL 是 OSI 批准的许可证,而且得到广泛采用。例如 MongoDB 就曾经使用 AGPL,Grafana 现在就在使用 AGPL。总而言之,AGPL 绝不会对软件项目的使用体验和受欢迎程度造成影响。我们之所以选择 AGPL,是因为相信这是与 OSI 共同为世界上更多开源项目铺平道路的最佳方式。”

 

也有网友表示,“我对此非常满意,因为他们保留了使用 Elastic 许可证的选项。现在每个人都开心了。对我来说,AGPL 比 Elastic 许可证更‘开源’这一点很奇怪。AGPL 要求你在对产品进行任何更改时发布所有源代码;Elastic 许可证只是说,不要使用我们的代码与 Elasticsearch 直接竞争。”

 

有网友对此解释,“对产品的更改”是指对服务本身的更改,“发布所有源代码”是指特定服务,而不是您构建的所有内容。如果你修补了 ES 服务,则将修补程序公开,但你无需将任何调用 ES 的服务公开。这对你而言是相当静态和可控的。另一方面,“直接竞争对手”可能会随着时间的推移而发生变化,因此,如果 Elastic 购买了我产品的竞争对手或重新解释了竞争对手的含义,那么我使用该软件的方式就会发生变化。比如你很早就涉足 ML 领域并在 ES 之上构建了一个 RAG,ES 可能很快就会将其作为一项服务提供(如果他们还没有提供的话),所以现在您是竞争对手,而您的业务没有任何变化。

 

有网友表示,“对我来说,无法与项目所有者竞争比 AGPL/GPL 的限制少得多。”

 

这次宣布再次开源后,看得出 Banon 很激动。"这个激动人心的消息在 Elastic 内部快速传递,因为开源既是每位参与者的追求、也被深深刻进 Elastic 的 DNA 当中。能够再次见证 Elasticsearch 成为开源项目,无疑是个令人振奋的重要里程碑。"Banon 如是说道。

 

再改许可,对公司有什么影响?

 

不少愤世嫉俗的网友肯定会这么看,毕竟之前软件开发商 Elastic 曾经顶住压力将项目的开源许可证替换成了专有许可证,如今再改回去必然要遭到嘲讽。

 

Banon 也有预料。“Elastic 回归开源许可证,是因为他们感觉项目快不行了。”Banon 提前回应了这个问题。

 

“首先我想强调一点,我们对 Elastic 的现状比以往任何时候都更加乐观。我为自己的产品及团队执行力感到无比自豪。我们为生成式 AI 用例提供了无状态 Elasticsearch、ES/QL 以及一系列向量数据库/混合搜索改进。我们在日志记录和可观察性方面与 OTel 密切协同。我们的安全 SIEM 产品不断引入令人惊叹的功能,也成为市场上增长最快的产品之一。用户的积极反应也令人感到欣慰。总之如同股市总是有起有落,我可以向大家保证的是,Elastic 一直在着眼于长远,而此次调整就是长远战略中的组成部分。”他说道。

 

随着许可证变更的讨论再度被点燃,随之而来的是这样的疑问:从开源许可证转为专有许可证之后,公司的财务状况到底有没有得到实质性改善?

 

对此,RedMonk 高级分析师 Rachel Stephens 做了专业的分析。

 

下图为各家公司的收入随时间变化的结果,蓝色竖线代表更改许可证的时间。X 轴和 Y 轴保持不变以便于比较,体现的是公司上市之前有多少可用财务数据。从这套数据集中可以看出,许可证更改之后收入确实有所增加,但增长率跟许可证更改之前似乎并无实质性差异。



市值是衡量企业价值的重要指标。研究发现,MongoDB 在许可证变更之后迎来了公司市值的大幅增长。Elastic 同样实现了增长,但速度要平缓得多。HashiCorp 则一直举步维艰,其估值甚至在许可证变更之后有所下降。

 


最后值得注意的是,这些公司都还没有盈利。也就是说,公司的估值主要由未来现金流的预期增长所驱动。

 


总体看,通过这项研究可以观察到,许可证变更之后收入有所增长的情况,但具体增长率似乎并未出现显著变化。更改许可证对于公司估值的影响其实也是好坏参半,而且从开源转向专有许可证跟提升公司估值之间好像也没有什么明确的因果关系。

 

那么,你对这次 Elasticsearch 再次开源有什么想法?欢迎评论区留言讨论~

 

参考链接:

https://www.elastic.co/cn/blog/elasticsearch-is-open-source-again

https://redmonk.com/rstephens/2024/08/26/software-licensing-changes-and-their-impact-on-financial-outcomes/

https://www.infoq.cn/article/aipBQM4Q5dw6Gi3lVpc4?utm_campaign=geek_search&utm_content=geek_search&utm_medium=geek_search&utm_source=geek_search&utm_term=geek_search

2024-09-01 12:039212

评论

发布
暂无评论
发现更多内容

TiDB v5.4.0 与 v6.0.0 的 sysbench 性能对比

TiDB 社区干货传送门

性能测评 6.x 实践

一次SSD磁盘寿命耗尽导致的TiDB集群写入变慢问题处理

TiDB 社区干货传送门

故障排查/诊断

一次断电故障引起TiDB无法启动的问题带来的几点思考

TiDB 社区干货传送门

管理与运维 故障排查/诊断

6.0体验:TiKV 重启后 Leader 均衡加速

TiDB 社区干货传送门

管理与运维 新版本/特性解读 6.x 实践

基于 TiDB v6.0 部署两地三中心

TiDB 社区干货传送门

实践案例 6.x 实践

TiDB Lightning在数据迁移中的应用与错误处理实践

TiDB 社区干货传送门

迁移 管理与运维 6.x 实践

TiDB HTAP特性的应用场景简析

TiDB 社区干货传送门

数据库架构设计

TiCDC系列分享-02-剖析同步模型与基本架构

TiDB 社区干货传送门

迁移 备份 & 恢复 大数据场景实践 实时数仓场景实践 数据中台场景实践

TiCDC系列分享 Open API与业务系统集成

TiDB 社区干货传送门

应用适配 6.x 实践

TiDB中如何查看database级别的QPS

TiDB 社区干货传送门

监控

TiDB多活方案

TiDB 社区干货传送门

实践案例 集群管理 数据库架构选型 数据库架构设计

TiDB 查询优化及调优系列(四)查询执行计划的调整及优化原理

TiDB 社区干货传送门

我和 TiDB 的故事 - 2020~2022

TiDB 社区干货传送门

基于tidbV6.0探索tiflash在多标签组合场景下的使用

TiDB 社区干货传送门

实践案例 6.x 实践

tiflash 6.0 on K8s 扩容与新特性实践

TiDB 社区干货传送门

版本测评 安装 & 部署 新版本/特性解读 扩/缩容 6.x 实践

TiDB 6.0: 统计信息优化改进

TiDB 社区干货传送门

管理与运维 新版本/特性解读 6.x 实践

TiDB库表设计和使用规范

TiDB 社区干货传送门

管理与运维

TiFlash 源码阅读(二)计算层概览

TiDB 社区干货传送门

TiDB 查询优化及调优系列(三)慢查询诊断监控及排查

TiDB 社区干货传送门

TiDB 6.0 Book Rush | TiDB 和 Python 的 CRUD 应用开发实践

TiDB 社区干货传送门

6.x 实践

文件数据导入到TiDB的实践

TiDB 社区干货传送门

这一年,我和 TiDB 的故事

TiDB 社区干货传送门

基于tidbV6.0探索索引优化思路

TiDB 社区干货传送门

实践案例 6.x 实践

离线安装 TiSpark v2.5.1

TiDB 社区干货传送门

6.x 实践

TiDB Sysbench 性能对比测试报告 - v5.1.4 对比 v6.0.0 DMR

TiDB 社区干货传送门

6.x 实践

TiKV 节点重启后业务恢复速度(leader 平衡速度)v6.0 vs v5.1.2对比测试

TiDB 社区干货传送门

版本测评 6.x 实践

TiDB 和 C# 的简单 CRUD 应用程序

TiDB 社区干货传送门

6.x 实践

MySQL正常执行的SQL在TiDB中变慢了

TiDB 社区干货传送门

管理与运维 故障排查/诊断

TiDB 6.0: 让 TSO 更高效

TiDB 社区干货传送门

实践案例 性能测评 新版本/特性解读 6.x 实践

TiDB与MySQL的模糊查询大小写

TiDB 社区干货传送门

开发语言

TiSpark v2.4.x 升级到 TiSpark v2.5.x

TiDB 社区干货传送门

实践案例 6.x 实践

3 年后,Elasticsearch 再次开源,还与 AWS 成为关系牢固的“伙伴”!网友:OpenSearch 怎么办?_开源_褚杏娟_InfoQ精选文章