數年前，在科技網站ZDnet的一篇文章中，作者提出了一個問題：開源是否增長成為企業軟件默認的全新業務模式。雖然僅過去了幾年時間，但現在回頭看來，這個問題似乎有點奇怪，因為Redis、MongoDB與Confluent等公司正在蓬勃發展，沒有人再懷疑開源的價值。

但是，如今的開源中具有諸多的爭議，比如MariaDB CEO Michael Howard就批評這些云計算巨頭會通過“露天開采”來掠奪各種開源資源。無風不起浪，最近一波爭議起于上周，引爆點便是AWS宣布它推出了增強的Elasticsearch開源發行版，正如ZDnet 記者 Steven J. Vaughan-Nichols 報道的那樣，在競爭激烈的文字大戰中，Elastic和亞馬遜都試圖占據輿論制高點。

對于開源如何改變了軟件領域，我們不必在此進行贅述。比如紐約，雖然憑借著華爾街，“大蘋果”一直被視為是一座“科技之城”，但在開源出現之前，由于技術的被封鎖，各家公司都必須去獨立開發包括從高性能的信息傳遞到計算網格與數據庫在內的IT基礎設施及軟件，沒有人愿意與別人進行互動。

而后，華爾街公司們意識到必須要將開源放在首位，因為它們不想重新再去自我創建各種獨立的系統，尤其是在核心基礎設施軟件或機器學習算法方面，它們獨有的知識產權其實具有更高的價值。它們不再會失去那些使用開源軟件的優秀人才，因為它們希望自己的技術能夠更加便于移植。至此，華爾街公司不再介意員工公開討論他們的開源見解，甚至鼓勵他們去創造自己的開源項目：幾乎每晚該城市中都會舉辦各類聚會，開源從業者們會在那里分享他們的創新成果。

但是，開源公司會發現：他們的項目越受歡迎，自己就面臨著更多的“成長煩惱”，就像MongoDB不會希望有人分走它獲得的3億美元投資。對于這些開源公司而言，別人的模仿可能是一種真正地學習與致敬，但這也是對它們未來收益的極大威脅。沒有哪個開源玩家希望自己成為別人的墊腳石或犧牲品。

這就是像MongoDB和Redis這樣的公司感到威脅的原因，因為它們的項目吸引了大量的追隨者;而Cloudera這樣的公司則完全沒有這種感覺，因為它們的項目吸引力較小。因此Cloudera會認為AWS和Azure更像是合作伙伴，而不是吸血鬼。

Adobe開發者生態主管Matt Asay經常對近期熱點事件進行評論，在他最近的帖子中，他表示，大多數下載或使用開源的開發者都不會花時間搞亂代碼或者為它做貢獻，因為他們已經有了日常工作。因此，許可證的變化 ，特別是那些禁止運行第三方SaaS服務的許可證 ， 對他們來說無關緊要。

在當前的爭奪中，亞馬遜開辟了一條新的戰線，它與Netflix和Expedia等客戶共同為Elasticsearch項目開發了一個新的開放發行版，這將為這個開源項目貢獻所有的資源。它這樣做是基于它的論點，即Elastic正在通過引入開放源代碼和專有代碼來混淆視聽。Elastic則堅稱，它與亞馬遜存在分歧，而不是與所有云提供商都存在分歧。

從一開始，Elastics的商業模式就基于開源和專有軟件的結合。其核心的產品，包括Elasticsearch、Kibana、Logstash和Beats都是基于Apache 2.0開源許可的。爭論的焦點是以前稱之為X-Pack的Elastic Stack Features(擴展或插件)，這些功能負責處理安全、警報、監視、報告、圖形分析和機器學習。在過去，它們會被被視為是封閉的專有軟件，最初的目的旨在使程序集成為一個經典的開放核心產品，其中一些功能可以免費獲得，而其他功能只能通過付費訂閱獲得。而由于這些功能都是專有的，因此催生出了一個第三方生態系統來替代這些功能，這并不奇怪。

去年Elastic做出了一些改變，因為它發現開放核心(Open Core)模式存在分歧。一年前，Elastic CEO Shay Banon在一篇博客文章中表示，如果將開放時間延長一倍，那么明確有償與免費的分界線將會破壞社區。他指出連接的斷開不僅會出現在在功能廣度上，也在測試中帶來不連貫性。他有一個觀點 - 如果這些特征交織在一起，那么分割的代碼就像分開的城市一樣難以想象。

挑戰在于，通往混亂的道路是由良好的，或者更恰當地說，是高度理想主義的意圖鋪成的。Elastic的做法令人欽佩，它將Elastic特有的源代碼公開并提供下載，這限制了其他第三方將其作為商業SaaS服務提供的可能性。但是，正如AWS所主張的那樣，可下載文件夾中的文件混合了Apache 2.0和Elastic的許可代碼，這會讓事情變得很復雜。

Elastic堅稱Elastic許可證和Apache許可證代碼位于不同的文件夾中，并且差異非常明顯。但在我們看來，差異是非常微妙的。而且，即使Elastic在Apache和Elastic授權代碼之間建立了一堵長城以制造明顯差異，也不能保證亞馬遜會止步不前。

在此期間，MongoDB和Confluent也加緊實施自己的計劃。由于雙方無法達成一致意見，MongoDB退出了開源倡議，之后開始推進SSPL，它涵蓋了4.0平臺的所有方面。 而Confluent正在推進Confluent社區的許可，其中包括觸及(但不包括)Apache Kafka的組件：KSQL，Confluent連接器，REST代理，控制中心和其他幾個部分。

此外，Redis去年夏天發布了Redis Modules中的Commons Clause(不是數據庫本身)，后來又在一個名為Redis Source Available License(RSAL)的新條款下對其放寬了限制。這里的好消息是，Redis直言不諱：它并沒有假裝宣稱RSAL是一個開源許可證。

這些都是開源玩家們面臨的挑戰。與傳統的專有軟件相比，開源軟件或項目拓寬了人們的目標市場的寬度，并為構建關鍵的大眾社區提供了***機會，并使得用戶得以使用它建立安裝基礎。但是這把雙刃劍的另一面就是這些項目太受歡迎了。開源提供商面臨的永恒挑戰是如何保持競爭優勢。如果他們有一個更快的新版本發布通道，情況可能尚不糟糕，但但一旦競爭對手趕上來，那就是另一回事了。例如，過去AWS在支持Hadoop版本方面常常滯后，但之后，在***的穩定Apache版本發布30后，AWS就會采取行動。這時，時間不再會是開源供應商的朋友。

另一個風險是分叉(forking)，借助它，廠商要劃分出能夠給予自身項目支持的社區。對于那些非社區控制的開源項目特別是供應商來說，這是一個很大的挑戰，MongoDB就是***的例子。它會在***版本項目的基礎上構建新功能，而Amazon和Percona等第三方會在不受SSPL約束的早期版本的基礎上開發新功能。代碼將會被分叉，問題是這是否會導致社區分裂。毫無疑問，Elastic的Banon所關心的正是如何將使用免費開源版本的用戶與使用付費企業版本的用戶隔離開來。

開源公司需要可用于防御的IP。不過，到目前為止，Red Hat(很快將成為IBM的一部分)仍然是一個例外，即純開源公司的產品基于社區主導的項目可以獲得成功。與此同時，Cloudera也在尋求突破，成為另一個特例。

那么，對于生態系統的其他部分，新的變體開源許可證是解決方案嗎? 這里危險之處在于，客戶一方的法律和合同履行人員可能會對許可證感到厭倦，因此可能會對許可證產生抵觸。

或許對于開源廠商來說，要做的就是不要做任何事情來使用戶對它們產生懷疑，并堅持使用著名的開源許可證。之后圍繞它，開發獨特的內容，為開源項目增加價值。同時保持增值組件的抽象也需要是獨特的，并針對開源內容進行了優化。繼續發布有限制的專有代碼，但不要假裝它是開源的。當然這不會是一件容易的事，畢竟開放核心模型太老了，也許它會再次進行轉變與更新。