【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

换协议、改代码,Elastic 要逼开发者二选一?

  • 2021-08-11
  • 本文字数:3245 字

    阅读完需:约 11 分钟

换协议、改代码,Elastic要逼开发者二选一?

为应对云服务提供商,Elastic 近日对其 Elasticsearch 数据库的官方 Python 客户端(Elasticsearch-py)做出了修改,使其无法与各分叉版本相兼容,之后又粗暴地关闭了GitHub上的话题评论。这一行为引起了广大开发者激烈讨论。

 

剑指云厂商

 

Elasticsearch 是一款数据库管理器与分析引擎,在行业内被广泛使用。官方客户端在 Java、.NET(C#)、PHP、Python、Apache Groovy、Ruby 和许多其他语言中都是可用的。根据 DB-Engines 的排名显示,Elasticsearch 是最受欢迎的企业搜索引擎,其次是 Apache Solr。

 

Elasticsearch-py旨在为 Python 中一切与 Elasticsearch 相关的代码提供共识,目前客户端的下载量已经超过 20.2 万次。Elasticsearch-py 一直坚持以中立性与高可扩展性作为基本定位,而负责运行 Elasticsearch 查询的高级库 Elasticsearch DSL,也将 Elasticsearch-py 以库的形式来使用。

 

这次代码修改也是 Elastic 与 AWS 矛盾激化的体现。

 

作为一款开源产品,Elasticsearch 在今年 1 月份调整了其开源许可证,将之前的 Apache 2.0 许可授权改为双重许可模式(即 SSPL 1.0 和 Elastic 许可),用户可以选择适合自己的许可方式。促使 Elastic 做出该决定的最大原因便是,以此应对公有云平台(特别是 AWS)上发生的不公平使用情况。

 

“随着很多公司不断向 SaaS 转型,有些云服务提供商使用了开源产品,并在不向社区提供任何回馈的情况下,将其作为一项对外提供的服务。这种做法转移了本可以再投资到产品上的资金,损害了用户和社区的利益。”Elastic 在声明中写道,“社区逐渐认识到,开源公司只有更好地保护自己的软件,才能保持高水平的投资和创新。”

 

为了应对这一变化,AWS 抢在许可证变更之前对 Elasticsearch 进行了分叉,构建起 Open Distro for Elasticsearch,之后逐渐演变为 OpenSearch,并在上个月发布了1.0版本

 

根据 AWS 介绍,OpenSearch 是一个社区驱动的开源搜索和分析套件,源自 Apache 2.0 许可的 Elasticsearch 7.10.2 和 Kibana 7.10.2。它包括一个搜索引擎守护进程(OpenSearch)、一个可视化和用户界面(OpenSearch Dashboards),以及用于弹性搜索的 Open Distro,包括安全、警报、异常检测等功能。

 

根据亚马逊网络服务副总裁 Adrian Cockcroft  的说法,发行说明和文档未能阐明什么是开源的、什么不是,这让企业开发人员面临这样的情况:他们会在无意中使用到可能会在未来造成财务或法律问题的代码。AWS 的介入可以确保其客户可以继续运行 Elasticsearch,而不必担心他们的计费周期可能会中断。不过有开发者表示,OpenSearch 社区活跃度还有待提高。

 

如今,开发者们注意到,Elasticsearch-py 的源代码已经被悄悄更改,其会单独检查数据库属于 Elastic 还是分叉产物。更新说明中提到,“如果响应当中没有 X-Elastic-Product HTTP 标头,或者 X-Elastic-Product HTTP 标头的值不是 Elasticsearch,就会引发错误。”

 

逼开发者站队?

 

“神仙打架、凡人遭殃”。这场企业间的对抗深深伤害了曾为 Elasticsearch 做出贡献的开源开发者们。在数据搜索管理开源项目 Invenio 产品经理 Lars Holm Nielsen 看来,Elastic 是在逼迫普通开发者站队。

 

 “我们开发了一款开源产品,能够轻松与 Elasticsearch 或者 OpenSearch 配合使用,而用户再根据自己的需求选择到底使用 Elasticsearch 还是 OpenSearch……Elastic 的种种行为确实沉重打击了我们对该公司及其旗下产品的信心。别把锅都甩给 Amazon,Elastic 之前已经修改过服务器许可证了,根本没必要再把其他分叉版本拒之门外。”Nielsen 表示。

 

Elastic 公司高级工程技术经理 Philip Krauss 则回应称,“Amazon OpenSearch 是另外一款不同的产品。虽然与 Elasticsearch 有些渊源,但二者之间的诸多差异必然导致大量问题甚至混乱。”

 

目前该话题在GitHub上的评论功能已被关闭,后续留言也被删除。

 

做出修改的不止是其官方 Python 客户端,Elasticsearch 的.NET Connector 也没能幸免,同时开始出现诸如“客户端发现服务器不是受支持的 Elasticsearch 发行版”等错误提示。

 

面对用户的抱怨,Elastic 高级软件工程师 Steve Gordon 回应称:“建议大家升级到 Elasticsearch 的最新默认发行版,此版本可以在 Elastic License v2 下免费使用……我们将此次修改视为增强功能,因为它只会影响到不受支持的客户端与服务器组合。在受支持的配置中,变更不会给业务造成任何影响。这次调整的目的是通过快速失败的方式声明不兼容性,避免消费者错误地认为可以在未经测试、且可能无法达成预期效果的配置下长期运行负载。”

 

此外,还有一个变化:Elasticsearch 的 Java 客户端也已切换为 Elastic License。这个问题已经在 OpenSearch 社区中引发用户们的焦虑。

 

“OpenSearch 要怎么处理当前可用的各种编程语言所对应的多种 connector 和 binding?根据报道,其中很多已经集成了反竞争机制。”有开发者提出疑问。

 

许可约束跟产品检查还不是一回事。Elastic 公司表示,“我们的客户端库仍然遵循 Apache 2.0 许可证,但其中不包括 Java 高级 Rest 客户端(Java HLRC)。Java HLRC 依赖于 Elasticsearch 核心,因此该客户端库将采用 Elastic License。随着时间推移,我们会逐步消除这种依赖性,并将 Java HLRC 转移至 Apache 2.0 许可。”

 

如果在代码层面阻止连接,那么遵循 Apache 2.0 许可证的这些客户端(包括 Python 与.NET 客户端)将无法与 OpenSearch 协同使用。当然,各客户端的分叉与修改难度并不高,应该还是会有解决办法。

 

利益之争

 

云的兴起给基础软件公司和开源公司提供了很好的分发渠道,能够更好地构建竞争壁垒,还可以迅速将开源用户发展到云上来。在云上统一部署,省去了企业要给每一个用户安装、部署甚至定制化的高成本。但这对传统的开源软件企业的商业模式形成了冲击。

 

近年来,云厂商与开源厂商之间的矛盾日益显著。早在 18 年底,图数据库 Neo4j 便宣布,从 Neo4j 3.5 版本开始,企业版仅在商业许可下提供,不再提供源代码。近几年,Confluent、MongoDB、Kafka、Redis 等也纷纷修改开源协议,限制云厂商从中牟利却不做贡献的行为。

 

针对两个阵营之间的纷争,开发者们的观点也不相同。

 

“我个人也受不了 Elastic,因为他们收取企业级的支持费用,然后提供开源级别的支持。你在遇到一个问题时,得到的回应通常是‘为什么要尝试这样做?’,或者‘请参考这个自 2016 年以来就不新鲜的问题’。”有代码贡献者分享了自己使用 Elastic 的感受。

 

随着竞争的加剧,开源软件背后的商业公司可能不得不考虑如何进化自己的服务和商业模式。

 

不过,Open UK 首席执行官兼首席政策官 Amanda Brock 认为,开源是多种多样的,但它不是一种商业模式。像 Elastic 这样对云提供商使用其代码方式感到不满的公司并没有完全理解开源许可证的含义。“根据我的经验,云提供厂商正在以开源许可范围内可接受的方式使用它。”

 

当然,也有开发者表示理解 Elastic 开源厂商的做法:

 

如果 Elastic 在 ElasticSearch 上取得成功,那么完全可以预想到,其他公司也会加入这一风口,并尝试从中获利。作为创造产品的公司,可能并不是能从中获利最多的公司,企业应该计划获得足够的利润。但事情变得复杂的地方在于,没有企业希望他们从自己创造的产品中获得的收益比依赖该产品的其他企业要少几个数量级。

 

开源软件企业们没有预见到,云服务提供厂商的出现,最大限度地降低了他们的价值主张。亚马逊可以投入大量资源,甚至可能比 Elastic 本身还要多。有人可能会争辩说,亚马逊滥用了他们在云服务领域的垄断地位,提供了 Elastic 永远无法与之竞争的捆绑式 ElasticSearch 体验。即使他们开发了替代的内部产品,它看起来也与当年 Microsoft 将 Internet Explorer 与 Windows 捆绑在一起的情况完全相同。

 

即使在今天,如果企业愿意开发一个开源或免费的软件产品,一旦足够成功,便很可能会成为大型企业的利用目标。公司始终可以选择重新许可内部编写的代码,以及由适当的贡献者许可协议 (CLA) 的签署人提交的任何代码。

 

 

利益分配问题确实是开源厂商和云厂商之间最大的争论点,这个问题或许还是要从商业角度解决,看谁能在两者之间的博弈中占据上风。

 

2021-08-11 14:356484

评论

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

工具:Juypter Notebook

正向成长

Jupyter Notebook

双11大促 | 消息推送资源包6折购!一键集成华为、小米等多厂商推送通道

蚂蚁集团移动开发平台 mPaaS

消息推送 push mPaaS 双11 促销

揭秘 MatrixDB 数据库内核技术,可编程的数据库!

YMatrix 超融合数据库

数据库 时序数据库 分布式时序数据库 MatrixDB 超融合时序数据库

可观测性架构实践

郑印

机器人存在的问题挑战

crm的核心是什么?CRM对企业的核心作用是什么?

低代码小观

企业 企业管理 CRM 管理系统 CRM系统

如何 30 分钟搭建一个语聊房

融云 RongCloud

移动App应用进入存量竞争阶段,如何全维度洞察用户体验?

博睿数据

全项指标第一,腾讯V265与新一代VAV1自研编码器登顶MSU视频编码器大赛

科技热闻

JavaScript 解构赋值 5 个常见场景和实例

devpoint

JavaScript 大前端 ES6 11月日更

“极速、统一、开放”,StarRocks开启企业数据分析新局面

看完电影《门锁》感觉脊背发凉,智慧园区给你安全感!

ThingJS数字孪生引擎

可视化

GaussDB (for Cassandra) 数据库治理:大key与热key问题的检测与解决

华为云开发者联盟

数据库 分布式数据库 key GaussDB (for Cassandra) 数据库治理

hadoop nameNode/datanode 稳定性&性能改进点

Clarke

万字长文聊哈希

程序厨

面试 哈希 哈希表

语聊房高质量音乐伴奏的实现

融云 RongCloud

语聊房 音乐播放

【架构设计总结】

Ryoma

DDD战术设计实践

郑印

DDD

BoCloud博云完成 E 轮融资

BoCloud博云

云计算 云原生 博云

AI 算法在视频可分级编码中的应用

融云 RongCloud

人工智能 音视频 编解码

糟糕程序员的20个坏习惯

Kaito

架构 程序人生 后端 编程修养

活动日程首公布|Apache ShardingSphere Dev Meetup 亮点新揭秘

SphereEx

ShardingJDBC ShardingSphere 技术沙龙 SphereEx

crm软件有哪些比较好?国内目前好用的crm系统推荐!

低代码小观

CRM 管理系统 企业管理系统 CRM系统 客户关系管理系统

浅谈微信朋友圈架构设计

张平

架构实战营

彻底理解 AQS我是懂了,你呢?

何小事儿

Java 多线程 并发

10月书讯 | 跟着泰拉去冒险

图灵教育

编程 程序员 书单

优先队列一些记录以及解题思路

数据结构 Go 语言 优先队列

FabEdge 和 SuperEdge 联合在边缘 K8s 集群支持原生 Service 云边互访和 PodIP 直通

BoCloud博云

云原生 边缘计算 superedge FabEdge

Hudi 在字节实践记录

Clarke

40多场面试,凝聚成了这篇文章!

程序厨

面试 面试技巧 秋招

[架构实战营] 模块二作业

张祥

架构实战营

换协议、改代码,Elastic要逼开发者二选一?_大数据_褚杏娟_InfoQ精选文章