開源成長的痛苦：Open Core會是答案嗎？

上周，AWS公布了Open Distro for Elasticsearch之後，引發了口水戰，這是開源公司日益增長的痛苦的最新例證。雖然過去一年中，新的開源許可證數量激增，但這個陳舊的開放核心模型真的能證明保持開源是一個可行的更好選擇嗎？

幾年前，在我們一篇文章中，我們提出了一個問題：開源是否能夠成為企業軟體領域新的默認商業模式？現在僅僅過去了幾年，但是回顧過去，考慮到Redis、MongoDB、Confluent最近的行動，這個問題現在已經看起來有點古怪了，現在Elastic擔心亞馬遜這樣的雲巨頭，MariaDB的首席執行官Michael Howard表示，要「條帶式」開源。

最新一輪的截擊發生在上周。正如Steven J. Vaughan-Nichols報道的那樣，在激烈的口水戰中，Elastic和亞馬遜都試圖佔領高地。

這真是無風不起浪。

很少有人質疑開源是如何改變軟體環境的。在我們所在的紐約地區，我們已經看到了開源技術是如何開闢技術「疆土」的。感謝華爾街，紐約一直是一個技術城市，但是在開放源代碼之前，很多技術都是鎖定的，每一家企業都不得不自己為IT軟體基礎架構開發基礎支柱，從高性能消息傳遞到計算網格和資料庫，都是如此，因為現成的軟體無法被破解。沒有人和別人討論。

華爾街公司越來越多地尋求開源，因為他們不想重新發明輪子，尤其是核心基礎設施軟體或機器學習演算法；他們獨特的知識產權在價值鏈上的地位要高得多。而且他們不想失去那些喜歡開源的優秀人才，因為他們希望讓自己的技能變得更加便攜。而華爾街的公司不介意他們的員工是否出去公開談論他們的見解，甚至創立他們自己的開源項目；城裡幾乎沒有哪個晚上沒有聚會，從業者在這些聚會上分享他們的創新。

開源公司今天所感受到的成長痛苦與他們的開源項目受歡迎的程度直接相關。MongoDB不希望看到其他人從它所賺取的3億美元中獲利。正如我們上周所說，模仿可能是最真誠的奉承形式，但對於開源公司而言，它也是對未來收益的威脅。開源參與者希望避免成為他們自己成功的犧牲品。

這就是為什麼像MongoDB和Redis這樣的公司，其項目吸引了大量的粉絲社區，感到受到威脅，而像Cloudera這樣的項目吸引力較小的公司卻沒有的原因。這也就是為什麼Cloudera將AWS和Azure視為競合對手而不是吸血鬼的原因。

Matt Asay經常評論正在展開的傳奇故事。在他最近的帖子中，他認為大多數下載或使用開源的開發人員都不會花時間搞亂代碼或者為它做貢獻，因為他們還有日常工作要做。因此，許可證的變化——特別是禁止第三方運行SaaS服務——對他們來說無關緊要。這是非常有道理的。

在當前的爭吵中，亞馬遜通過與Netflix和Expedia等客戶共同推出新的Open Distro for Elasticsearch項目，開闢了一條新戰線，這些客戶將把所有這些內容回饋給這個開源項目。它這樣做的理由是Elastic正在攪渾水，模糊開放源代碼和專有代碼的界限。而Elastic則堅持表示自己反對的是亞馬遜，而不是所有的雲供應商。

從一開始，Elastics的商業模式的基礎就是開源和專有軟體的結合。核心Elastic堆棧包括Elasticsearch，Kibana、Logstash和Beats都採用了Apache 2.0開源許可。爭論在於Elastic Stack Features（擴展或插件），以前被稱為X-Pack，可以處理安全性、警報、監控、報告、圖形分析和機器學習。它們以前被當作封閉式專有軟體，這種做法最初使該組合成為經典的開放核心產品，其中一些功能是免費提供的，而另一些功能只能通過付費訂閱獲得。專有軟體部分不開放代碼供查看，我們相信這是他們留了一手的地方。而且，由於這些功能是專有的，毫不奇怪，它催生了第三方生態系統的替代品。

Elastic在去年發生了變化，因為它發現開放核心模型具有分裂性。Elastic首席執行官Shay Banon年前在一篇博客文章《Doubling Down on Open》中表示，付費和免費的分裂會破壞社區。他提到了各種分裂，不僅僅是在功能廣度方面，還包括測試方面的不連續性。他有一個觀點——如果這些功能交織在一起，那麼將代碼分開就像把城市一分為二一樣難以想像。

但是，挑戰在於通往混亂的道路是由良好的——更確切地說，是高度理想化的——意圖鋪就的。在令人欽佩的舉動中，Elastic隨後開放了Elastic Features的源代碼並可供下載，但是限制了第三方將其用於商業SaaS服務。但正如AWS所說的那樣，可下載文件夾中的文件最終包含了Apache 2.0和Elastic許可代碼的混合體。讓事情變得很混亂。Elastic表明存儲庫中的Elastic許可證和Apache許可證代碼位於不同的文件夾中，而且差異非常明顯。對我們來說，差異非常微妙。儘管如此，即使Elastic在Apache和Elastic許可代碼之間建立了一個更大的長城，也無法保證阻止亞馬遜前進。

在此期間，MongoDB和Confluent都在努力推進自己的計劃。由於雙方無法達成一致意見，MongoDB在退出Open Source Initiative之後正在推進SSPL。它涵蓋了4.0平台的所有方面。Confluent正在推進Confluent Community License，其中包括觸及（但不包括）Apache Kafka的組件：KSQL、Confluent Connectors、REST Proxy、Control Center和其他幾個組件。

同時，Redis去年夏天為Redis Modules發布了Commons Clause（不是資料庫本身），後來在一個名為Redis Source Available License（RSAL）的新條款下放鬆了一些限制。這裡的好消息是，Redis實驗室非常磊落：它並沒有假裝RSAL是一個開源許可證。

每一個參與者面臨的挑戰都是真實的。和傳統專有軟體相比，開源打開了市場，提供了打造重要大眾社區的絕佳機會，並且有望通過它形成自己的安裝基礎。但是，對於你自己的利益來說，如果你的項目變得太受歡迎，這就成了一把雙刃劍。開源提供商面臨的經典挑戰是如何保持競爭優勢。如果你有一個更快的管道升級到新版本是一回事，但是如果你的競爭對手趕上了它就是另一回事了。例如，AWS過去常常會在讓EMR支持最新的Hadoop版本方面動作遲緩，但是此後，它已經在最新的Apache穩定版本發布後的30天內就採取行動了。從這個角度看，時間已經不再是你的殺手鐧。

另一個風險就是技術分叉，這就會分裂支持項目的社區。這是一個風險，特別是對於由供應商而非社區控制的開源項目來說更是如此，MongoDB就是一個最好的例子。MongoDB將在最新版本之外構建新功能，而亞馬遜和Percona等第三方則開發出不受SSPL約束的早期版本。代碼將分叉，問題是這是否最終會破壞社區。毫不奇怪，將社區分裂正是Elastic的Banon所關注的問題，他正在呼籲用戶放棄使用付費企業版本而使用免費開源版本。

開源公司需要可防禦的知識產權。到目前為止，Red Hat（即將成為IBM的一部分）仍然是規則的例外，即基於社區主導項目的、純粹的開源公司可以成功。與此同時，Cloudera希望突破並成為下一個例外。對於生態系統的其他部分，新的開源變體許可證會是答案嗎？危險在於客戶方負責法律和合同合規的人員可能會對審核許可證感到壓力。

也許是時候認真考慮這件事了。不要一邊堅持使用著名的開源許可證，一邊又讓你的忠誠基礎滋生懷疑。繞開它，開發獨特的內容為開源項目增加價值。保持增值組件足夠抽象，但也是獨特的，並針對開源內容進行了優化。你可以繼續向前，發布有限制的專有代碼，但不要假裝它是開源的。沒有人說這很容易。開放核心模型太老了，也許它需要做點什麼，以便再次煥發青春。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！