<em id="yr4vk"></em>
<strong id="yr4vk"><track id="yr4vk"></track></strong>
  • <nav id="yr4vk"></nav>

  • 開源商業模式是萬惡之本?

    ——

    打印本文              

    開源商業模式是萬惡之本?


    免費軟件!免費領??!超級便宜!

    最近幾個月里,由于 Mongo、Redis Labs 和 Confluent 近來的舉動,所謂“開源商業模式”的話題又火了。單獨來看,每個案例都有獨特的情況,值得進一步分析,卻又無法依據個別情況得出結論。然而,總體來看這些單獨的行為卻又呈現出一個明顯的趨勢——以開源為基礎構建產品的各大公司紛紛轉向更為專有的路徑。雖然各個公司的情況各異,但實際上他們都宣稱:開源方法不足以產生足夠的收入來獲取投資者所尋求的投資回報。我認為這是因為開源商業模式這個獨特的類型將這些公司推向了一個狹隘的決策矩陣,從而限制了他們在未來進行方向調整的可能性。

    需要明確的一點是,在商業環境中利用開源軟件的方法有很多種,但并沒有獨立的開源商業模式,而對這種模式的追求極有可能限制未來的發展。

    Open Core 1.0

    為了研究專有解決方案的動向,我們先來看看其發展的歷史軌跡?;厮荻皇兰o初期,開源異軍突起,出現了一種社區認可的建立開源公司的方式,我們稱其為 Open Core 1.0:

    1. 建立一個成功的開源項目;

    2. 聘請其核心開發人員;

    3. 在其上創建一個產品(通常是專有的);

    4. 說服那些頑固且習慣占便宜的客戶購買更好的專有產品;

    5. 創造利潤!

    然而,很多原因導致這種方法具有缺陷。對于創業公司來說,這種方法相當于將所有免費軟件使用者都預設為“潛在客戶”,同時假設免費的東西都沒有內在價值,無法滿足潛在客戶的“胃口”。為了實現這一目標,這些公司通常都會保持對代碼的完全控制,強制公司獨占版權分配,如此他們才能向付費客戶發布開源和專有代碼的商業許可。眾所周知的是,這種方法最后走向了失敗,只有 MySQL 一個例外——Sun Microsystems 將其從絕望中解救了出來,并轉向了盈利。

    證明這種模式并不可靠的原因如下:

    Open Core 1.0 壓制了開發者社區的發展,阻滯了創新。這些創業公司為了從軟件的商業化中獲利,放棄了更開放的方法。但有意思的事情發生了:當社區淪落為將“愛占便宜”的用戶轉化成付費用戶的手段之后,也相繼迎來了凋零。此外,由于這些公司往往基于蓬勃發展的社區建立他們的整個商業模式,所以社區的凋零導致他們無法達成期望的銷量和收入。如果能夠在幾年內打造良好的品牌,并出售公司,投資者就能收獲豐厚的回報。如果做不到這一點,前進的道路將布滿荊棘。那些期望獲取十倍回報的投資人常常會對他們的開源產品感到失望,部分原因是因為開源公司面臨著更為嚴苛的審判,而且開源方法似乎局限于投資人們苦苦追求的“曲棍球棒曲線”式的增長(指經歷某個轉折點后呈指數型增長)。但我認為,曲棍球棒曲線只是曇花一現,而且無論軟件許可如何,其在任何情況下都幾乎無法實現,但是這些人都聽不進我的話,所以……

    我需要在這里對 MySQL 這個例外做個特別說明:他們在開源之前就建立了一個偉大的免費增值產品,而且他們從未失去這個產品——這就是他們的優勢。雖然其他創業公司試圖利用現有的開源社區,將其轉換為免費增值產品,在開源許可發展強勁之時,MySQL 只開放了它的軟件,將其作為支持開源許可的手段。MySQL 沒有必要將其社區轉換為免費增值方式 ,它始終存在,并融入了他們的模型中。盡管如此,他們在轉換用戶方面也遇到了很大的困難,但無論如何他們的成功仍然是個例外。

    值得一提的是,MongoDB 始于 Open Core 1.0 的末期,你可以在其基本業務模型中看到這一點。我們稍后再詳細介紹。

    Open Core 2.0 的出現

    隨著 Open Core 1.0 的巨大失敗,各種更為現實的新方法紛紛涌現。開源核心方法演變成了所謂的“混合方法”:利用協作開發的開源平臺作為構建大型企業專有系統管理框架的基礎。 Cloudera 就是一個最好的例子,它利用廣泛的 Hadoop 社區作為其軟件基礎,但還有其他產品。Apache Spark 開發出了 Databricks;Apache Kafka 開發出了 Confluent。這些混合模型的一個問題在于,很難確定是先有軟件項目還是先有公司。RedisLabs 是一家密切關注舊式開源內核模型的公司,但是他們也在嘗試盡可能獨立地運行 Redis 項目,并從先前的反面模式中吸取經驗。在一眾存活了下來并蓬勃發展的公司中,Mongo 可能是如今最接近 Open Core 1.0 時期統治風格的公司。

    但是,許多公司在商業模式方面都遇到了困難,我們從最近諸多試圖開源與專有兼得的軟件許可策略中就可以看出這一點。MongoDB 更換開源協議至SSPL(Server Side Public License),以期借此抓住其軟件用戶。Confluent 也正式變更其平臺部分開源組件的開源許可協議,從 Apache 2.0 切換到 Confluent 社區許可(Confluent Community License,CCL),允許免費下載、修改和重新發行代碼,但不允許將這些軟件作為 SaaS 產品提供給用戶,防止其他人在未經 Confluent 許可的情況下將 KSQL 作為服務運行。

    當然,真正引發這場爭議的公司還是 RedisLabs,他們更改了部分 Redis 插件的許可,添加了與 CCL 類似的 Commons Clause,也是為了防止未經授權的公司將其軟件用作服務。那么是什么導致這些公司將其部分軟件從開源生態系統轉移到自己的專有軟件中呢?我相信這些決策都是由大家對開源商業模式的錯誤信念引發的。

    沒有開源商業模式

    如果你的出發點是“我需要一個開源商業模式”,那么你就會走入一個誤區,即“我需要通過項目賺錢”,而非“我需要構建一個能夠帶來價值的產品”。乍一看,這兩者似乎并沒有什么區別,但這會最終會讓你得出“許可變更合乎邏輯”的結論。沿著這條路走下去,會限制你對業務與產品目標的轉變能力。我相信,如果你專心構建能夠為客戶的核心業務帶來價值的產品,那么是否選擇為軟件強加許可就不那么重要了,或者根本就不打緊了。

    Cloudera 案例

    下面讓我們以 Cloudera 為例進行說明。他們曾經一度以“利用 Hadoop 賺錢”為目標。他們很幸運,因為他們將業務委托給了他們之中最聰明的一個人——Mike Olson,很快他們就走上了“我們能為客戶提供什么價值”的道路,并創建了這樣的產品。當初 Cloudera 是“Hadoop 公司”,但是如今他們已是擁有大量數據分析和數據科學解決方案的“企業數據云”。你再也看不到 cloudera.com 說他們打算“利用 Hadoop 賺錢”,或者“利用 Spark、Kafka 或其他開源項目賺錢”—— Cloudera 是一家提供產品和解決方案的公司,他們向客戶銷售有價值的東西,他們不關心軟件的來源。你可能覺得這是對開源的不敬與冒犯,但是我不這么認為。

    假設當初 Cloudera 決定繼續做個“Hadoop 公司”。那么我們來想想如今的 Cloudera 會怎樣:他們買了一個域名 hadoop.com,并注冊了一個公司 Hadoop,Inc.(當然,我知道 Apache Hadoop 由 ASF 管理,絕不允許別人摻和他們的項目,所以這里我們只是做這個假設而已)。Cloudera 一下子就從專注于為客戶提供價值,轉變為還要同時繼續高舉 Hadoop 大旗。這在 Hadoop,Inc. 的決策樹中又將如何體現?

    對于創業公司來說,現在他們的成功已經與 Hadoop 項目的命運聯系在一起,他們與 Hadoop 的成敗緊密相關,如果 Hadoop 未能成功,那么他們未來的發展也幾乎沒有回旋余地。而且這也會引發其他令人不安的問題和決定:如果 Hadoop“過于成功”,導致 Hadoop,Inc. 黯然失色,結果會怎樣?Hadoop,Inc. 會不會是 Hadoop 項目不易使用的原因?如果其他公司想在 Hadoop 上構建產品怎么辦?他們應該付錢給 Hadoop,Inc. 嗎?如果他們不想給錢或沒有那么多錢,該怎么辦?這是否意味著 Hadoop,Inc. 在質疑那些不愿花錢買企業產品“愛占便宜”的人呢?一些剛剛畢業的 MBA 會說:“我知道了!我們應該尋找一些比較流行的 Hadoop 組件,然后做成專有軟件!如此一來,那些愛占便宜的人就不得不付錢給我們了!”于是,惡性循環開始了,每項新技術或新項目都開始考慮這項技術是“核心”技術,還是“附加”技術,是應該開源還是專有。這個充斥著變化與悔恨的惡性循環將無休無止。曾經被當作“核心”的東西可能變成“附加”,反之亦然,結果只會導致蕭條與本末倒置,而其根本原因就在于“我們必須利用 Hadoop 賺錢”。

    對于這一點,你可能會認為: Cloudera 的管理產品不是專有的嗎?沒錯,是專有產品,但我有兩點想說:

    1. 因為開源項目和 Cloudera 產品領域之間有明顯的分離,所以二者不存在混淆。在創建 Cloudera 解決方案時,還沒有關于其是否是開源核心的無休止的爭論。Cloudera 開發的所有東西都屬于產品,產品經理可以專注于提供價值。

    2. Cloudera 選擇讓開源之上“附加”的管理軟件成為專有。我認為底層軟件的許可并不重要,而這正是我與 Olson 意見分歧的地方。

    上述第 2 點的重要之處在于:這是 Cloudera 的選擇,因此與它對 Hadoop 的影響完全無關。他們的管理產品使用專利還是開源對 Hadoop 社區的影響很小,Hadoop 社區仍然是開發人員的龐大生態系統,各個公司依此構建了大量開源項目。我可以理解為什么商業人士可能不愿意公開購買你使用的所有代碼,但需要考慮一點:如果你是客戶,你需要一個可行可靠的解決方案,你是否真的愿意以你的團隊內部開發的解決方案為基礎建立你的業務呢?

    恰好有一家以銷售開源產品為生的公司,他們也在開源軟件之上建立了管理解決方案,他們所有產品都是通過開源組件構建的。而且賺了很多錢。這家出類拔萃的公司就是 Red Hat。就像我說的那樣,沒有人可以逆向解析或重新實現 Red Hat 模型。Cloudera 與其在概念上非常接近,但在很多重要的方面他們的實現各異。與 Cloudera 一樣,Red Hat 通過向需要現成解決方案的客戶銷售許可來賺錢。但與 Cloudera 不同,Red Hat 的所有軟件都是開源的,因為他們希望通過軟件協作獲得加速創新帶來的價值,而這并沒有成為他們的絆腳石。為什么?因為 Red Hat 很早就搶在眾人之前明白了一個道理:客戶的價值與底層軟件的許可無關,而與整體解決方案的固有價值有關,即它是否實現了自己的承諾。

    亞馬遜“問題”

    在利用開源軟件無需任何費用構建產品的公司之中,亞馬遜和 Google 最具有代表性,讓我們認真分析一下:亞馬遜和 Google 并不會原封不動地使用你的軟件,特別是你的管理軟件,不管你的軟件是否專有。他們構建了自己的管理用戶體驗和用戶界面,因為他們有自己的特殊需求需要滿足,他們使用現有的平臺 API 來構建產品。

    與普通的企業客戶相比,他們的可擴展性要求太過于龐大,絕大多數供應商甚至無法想象如何滿足他們的要求。這就是為什么引入許可的“把戲”來解決“AWS 問題”的不是一個創業公司,而是問題的解決方案。這就是為什么引入許可“把戲”來解決“AWS 問題”是行不通的,這是一個“尋找問題”的解決方案。你不可能通過對本質針對業務模型問題的許可解決方案進行反向工程,來解決自己的業務錯誤。你真的相信 Amazon 在引入內存數據庫服務時會使用 RedisLabs 的管理實現嗎?

    事實是,無論你使用了 Mongo、RedisLabs、Confluent 還是其他任何產品,你都可以使用 IaaS 平臺(包括亞馬遜或 Google)向客戶出售你的解決方案。事實上,Mongo 已經做到了這一點,并且大多數人都認為他們在這方面做得非常成功。

    如果你想創辦一家公司,那么就不要因小失大。以“我如何才能為客戶創造價值”為出發點,然后倒推回來。接下來,將你需要的開源組件組合在一起,為你的終極解決方案提供價值,并構建你的軟件供應鏈。屆時,你可以像 Red Hat 一樣,決定利用協作開發的好處,或者你也可以像 Cloudera 一樣,決定讓其中一些完全在你的掌控之下。關鍵是你可以做出這樣的選擇,而不用為“利用某某技術賺錢”所累。如此你才會為自己的選擇而感到高興。


    上一篇 如何選擇最適合你的需求的開源數據庫
    下一篇