沒有企業(yè)希望他們從自己創(chuàng)造的產(chǎn)品中獲得的收益比依賴該產(chǎn)品的其他企業(yè)要少幾個數(shù)量級。 

為應(yīng)對云服務(wù)提供商，Elastic 近日對其 Elasticsearch 數(shù)據(jù)庫的官方 Python 客戶端（Elasticsearch-py）做出了修改，使其無法與各分叉版本相兼容，之后又粗暴地關(guān)閉了 GitHub 上的話題評論。這一行為引起了廣大開發(fā)者激烈討論。

Elasticsearch 是一款數(shù)據(jù)庫管理器與分析引擎，在行業(yè)內(nèi)被廣泛使用。官方客戶端在 Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby 和許多其他語言中都是可用的。根據(jù) DB-Engines 的排名顯示，Elasticsearch 是最受歡迎的企業(yè)搜索引擎，其次是 Apache Solr。

Elasticsearch-py 旨在為 Python 中一切與 Elasticsearch 相關(guān)的代碼提供共識，目前客戶端的下載量已經(jīng)超過 20.2 萬次。Elasticsearch-py 一直堅持以中立性與高可擴展性作為基本定位，而負責(zé)運行 Elasticsearch 查詢的高級庫 Elasticsearch DSL，也將 Elasticsearch-py 以庫的形式來使用。

這次代碼修改也是 Elastic 與 AWS 矛盾激化的體現(xiàn)。

作為一款開源產(chǎn)品，Elasticsearch 在今年 1 月份調(diào)整了其開源許可證，將之前的 Apache 2.0 許可授權(quán)改為雙重許可模式（即 SSPL 1.0 和 Elastic 許可），用戶可以選擇適合自己的許可方式。促使 Elastic 做出該決定的最大原因便是，以此應(yīng)對公有云平臺（特別是 AWS）上發(fā)生的不公平使用情況。

“隨著很多公司不斷向 SaaS 轉(zhuǎn)型，有些云服務(wù)提供商使用了開源產(chǎn)品，并在不向社區(qū)提供任何回饋的情況下，將其作為一項對外提供的服務(wù)。這種做法轉(zhuǎn)移了本可以再投資到產(chǎn)品上的資金，損害了用戶和社區(qū)的利益。”Elastic 在 聲明 中寫道，“社區(qū)逐漸認識到，開源公司只有更好地保護自己的軟件，才能保持高水平的投資和創(chuàng)新。”

為了應(yīng)對這一變化，AWS 搶在許可證變更之前對 Elasticsearch 進行了分叉，構(gòu)建起 Open Distro for Elasticsearch，之后逐漸演變?yōu)?OpenSearch，并在上個月發(fā)布了 1.0 版本。

根據(jù) AWS 介紹，OpenSearch 是一個社區(qū)驅(qū)動的開源搜索和分析套件，源自 Apache 2.0 許可的 Elasticsearch 7.10.2 和 Kibana 7.10.2。它包括一個搜索引擎守護進程 (OpenSearch)、一個可視化和用戶界面 (OpenSearch Dashboards)，以及用于彈性搜索的 Open Distro，包括安全、警報、異常檢測等功能。

根據(jù)亞馬遜網(wǎng)絡(luò)服務(wù)副總裁 Adrian Cockcroft 的說法，發(fā)行說明和文檔未能闡明什么是開源的、什么不是，這讓企業(yè)開發(fā)人員面臨這樣的情況：他們會在無意中使用到可能會在未來造成財務(wù)或法律問題的代碼。AWS 的介入可以確保其客戶可以繼續(xù)運行 Elasticsearch，而不必擔(dān)心他們的計費周期可能會中斷。不過有開發(fā)者表示，OpenSearch 社區(qū)活躍度還有待提高。

如今，開發(fā)者們注意到，Elasticsearch-py 的源代碼已經(jīng)被悄悄更改，其會單獨檢查數(shù)據(jù)庫屬于 Elastic 還是分叉產(chǎn)物。更新說明中提到，“如果響應(yīng)當(dāng)中沒有 X-Elastic-Product HTTP 標(biāo)頭，或者 X-Elastic-Product HTTP 標(biāo)頭的值不是 Elasticsearch，就會引發(fā)錯誤。”

“神仙打架、凡人遭殃”。這場企業(yè)間的對抗深深傷害了曾為 Elasticsearch 做出貢獻的開源開發(fā)者們。在數(shù)據(jù)搜索管理開源項目 Invenio 產(chǎn)品經(jīng)理 Lars Holm Nielsen 看來，Elastic 是在逼迫普通開發(fā)者站隊。

“我們開發(fā)了一款開源產(chǎn)品，能夠輕松與 Elasticsearch 或者 OpenSearch 配合使用，而用戶再根據(jù)自己的需求選擇到底使用 Elasticsearch 還是 OpenSearch……Elastic 的種種行為確實沉重打擊了我們對該公司及其旗下產(chǎn)品的信心。別把鍋都甩給 Amazon，Elastic 之前已經(jīng)修改過服務(wù)器許可證了，根本沒必要再把其他分叉版本拒之門外。”Nielsen 表示。

Elastic 公司高級工程技術(shù)經(jīng)理 Philip Krauss 則回應(yīng)稱，“Amazon OpenSearch 是另外一款不同的產(chǎn)品。雖然與 Elasticsearch 有些淵源，但二者之間的諸多差異必然導(dǎo)致大量問題甚至混亂。”

目前該話題在 GitHub 上的評論功能已被關(guān)閉，后續(xù)留言也被刪除。

做出修改的不止是其官方 Python 客戶端，Elasticsearch 的.NET Connector 也沒能幸免，同時開始出現(xiàn)諸如“客戶端發(fā)現(xiàn)服務(wù)器不是受支持的 Elasticsearch 發(fā)行版”等錯誤提示。

面對用戶的抱怨，Elastic 高級軟件工程師 Steve Gordon 回應(yīng)稱：“建議大家升級到 Elasticsearch 的最新默認發(fā)行版，此版本可以在 Elastic License v2 下免費使用……我們將此次修改視為增強功能，因為它只會影響到不受支持的客戶端與服務(wù)器組合。在受支持的配置中，變更不會給業(yè)務(wù)造成任何影響。這次調(diào)整的目的是通過快速失敗的方式聲明不兼容性，避免消費者錯誤地認為可以在未經(jīng)測試、且可能無法達成預(yù)期效果的配置下長期運行負載。”

此外，還有一個變化：Elasticsearch 的 Java 客戶端也已切換為 Elastic License。這個問題已經(jīng)在 OpenSearch 社區(qū)中引發(fā)用戶們的焦慮。

“OpenSearch 要怎么處理當(dāng)前可用的各種編程語言所對應(yīng)的多種 connector 和 binding？根據(jù)報道，其中很多已經(jīng)集成了反競爭機制。”有開發(fā)者提出疑問。

許可約束跟產(chǎn)品檢查還不是一回事。Elastic 公司表示，“我們的客戶端庫仍然遵循 Apache 2.0 許可證，但其中不包括 Java 高級 Rest 客戶端（Java HLRC）。Java HLRC 依賴于 Elasticsearch 核心，因此該客戶端庫將采用 Elastic License。隨著時間推移，我們會逐步消除這種依賴性，并將 Java HLRC 轉(zhuǎn)移至 Apache 2.0 許可。”

如果在代碼層面阻止連接，那么遵循 Apache 2.0 許可證的這些客戶端（包括 Python 與.NET 客戶端）將無法與 OpenSearch 協(xié)同使用。當(dāng)然，各客戶端的分叉與修改難度并不高，應(yīng)該還是會有解決辦法。

云的興起給基礎(chǔ)軟件公司和開源公司提供了很好的分發(fā)渠道，能夠更好地構(gòu)建競爭壁壘，還可以迅速將開源用戶發(fā)展到云上來。在云上統(tǒng)一部署，省去了企業(yè)要給每一個用戶安裝、部署甚至定制化的高成本。但這對傳統(tǒng)的開源軟件企業(yè)的商業(yè)模式形成了沖擊。

近年來，云廠商與開源廠商之間的矛盾日益顯著。早在 18 年底，圖數(shù)據(jù)庫 Neo4j 便宣布，從 Neo4j 3.5 版本開始，企業(yè)版僅在商業(yè)許可下提供，不再提供源代碼。近幾年，Confluent、MongoDB、Kafka、Redis 等也紛紛修改開源協(xié)議，限制云廠商從中牟利卻不做貢獻的行為。

針對兩個陣營之間的紛爭，開發(fā)者們的觀點也不相同。

“我個人也受不了 Elastic，因為他們收取企業(yè)級的支持費用，然后提供開源級別的支持。你在遇到一個問題時，得到的回應(yīng)通常是‘為什么要嘗試這樣做?’，或者‘請參考這個自 2016 年以來就不新鮮的問題’。”有代碼貢獻者分享了自己使用 Elastic 的感受。

隨著競爭的加劇，開源軟件背后的商業(yè)公司可能不得不考慮如何進化自己的服務(wù)和商業(yè)模式。

不過，Open UK 首席執(zhí)行官兼首席政策官 Amanda Brock 認為，開源是多種多樣的，但它不是一種商業(yè)模式。像 Elastic 這樣對云提供商使用其代碼方式感到不滿的公司并沒有完全理解開源許可證的含義。“根據(jù)我的經(jīng)驗，云提供廠商正在以開源許可范圍內(nèi)可接受的方式使用它。”

當(dāng)然，也有開發(fā)者表示理解 Elastic 開源廠商的做法：

如果 Elastic 在 ElasticSearch 上取得成功，那么完全可以預(yù)想到，其他公司也會加入這一風(fēng)口，并嘗試從中獲利。作為創(chuàng)造產(chǎn)品的公司，可能并不是能從中獲利最多的公司，企業(yè)應(yīng)該計劃獲得足夠的利潤。但事情變得復(fù)雜的地方在于，沒有企業(yè)希望他們從自己創(chuàng)造的產(chǎn)品中獲得的收益比依賴該產(chǎn)品的其他企業(yè)要少幾個數(shù)量級。 

開源軟件企業(yè)們沒有預(yù)見到，云服務(wù)提供廠商的出現(xiàn)，最大限度地降低了他們的價值主張。亞馬遜可以投入大量資源，甚至可能比 Elastic 本身還要多。有人可能會爭辯說，亞馬遜濫用了他們在云服務(wù)領(lǐng)域的壟斷地位，提供了 Elastic 永遠無法與之競爭的捆綁式 ElasticSearch 體驗。 

即使他們開發(fā)了替代的內(nèi)部產(chǎn)品，它看起來也與當(dāng)年 Microsoft 將 Internet Explorer 與 Windows 捆綁在一起的情況完全相同。即使在今天，如果企業(yè)愿意開發(fā)一個開源或免費的軟件產(chǎn)品，一旦足夠成功，便很可能會成為大型企業(yè)的利用目標(biāo)。公司始終可以選擇重新許可內(nèi)部編寫的代碼，以及由適當(dāng)?shù)呢暙I者許可協(xié)議 (CLA) 的簽署人提交的任何代碼。 

利益分配問題確實是開源廠商和云廠商之間最大的爭論點，這個問題或許還是要從商業(yè)角度解決，看誰能在兩者之間的博弈中占據(jù)上風(fēng)。

參考鏈接：

https://www.theregister.com/2021/08/09/elasticsearch_python_client_change/

本文來自微信公眾號 “InfoQ”（ID：infoqchina），作者：褚杏娟、核子可樂，36氪經(jīng)授權(quán)發(fā)布。