開源到底是不是商業模式

前幾天，一篇名為《開源商業模式是個偽命題》的文章橫空出世，看似犀利的觀點卻沒有引起激烈的反駁。無論是開發專有軟體的企業，還是重度投入到開源軟體開發的企業，都認同開源本身並不是企業作為軟體及服務提供商的商業模式。

行業當中有這樣的共識並不奇怪。如果你在國際網際網路上搜尋『開源商業模式』關鍵字，其結果從 2016 年起就幾乎被『開源不是商業模式』所統治。本文老調重彈，從開源為什麼不是商業模式，不是商業模式的開源在企業運作中扮演什麼角色，以及圍繞開源軟體存在哪些商業模式做出討論。

開源為什麼不是商業模式

我們從那些宣稱或者暗示開源是商業模式的企業來反證這個觀點。

通常，此類企業一上來不提供收費的商業軟體，而是投入巨大的人力開發一款開源軟體。其創始人往往期待以此開啟名聲，使用者紛至沓來，隨著使用者量的增長，應該自然產生商業訴求，由此轉換為企業的客戶，企業從而增長營收。在這樣的一個假設當中，軟體開源是使用者能夠自由使用，從而自發宣傳病毒式傳播的基礎，因此只要軟體做得好，一經開源贏得足夠大的使用者群，後面的營收就是 autowin 了。

顯然，這個邏輯存在兩個巨大的漏洞。

第一個是使用者不等於客戶，開心使用你提供的開源軟體的企業，不見得在你提供商業支援和服務以後就會採購。

對於絕大多數中小企業來說，一個能從今天的開源軟體市場裡殺出來的軟體，幾乎都是可以直接上手使用的。例如關係型資料庫領域，PostgreSQL 和 MySQL 的成熟方案足以支援一家中型企業的資料儲存和事務操作需求。如果你的開源軟體不比它們好，那麼使用者沒理由使用;如果你的開源軟體比它們更好，使用者只需要用開源版本就可以滿足需求。

第二個漏洞是開源協議給予接收者的自由度，使得公司投入巨大的人力開發出來的軟體，沒有在競爭對手的商業競爭中形成有效的技術壁壘。

潛在甲方企業規模越大，其關鍵任務路徑上的軟體選擇和運維就更加謹慎。如果一款開源軟體在行業內對解決這個問題有比較優勢，這些甲方企業是會存在採購商業支援、軟體訂閱或雲服務的需求的。

然而，由於開源軟體給予接收者自由修改、自由整合和自由分發修改或整合後軟體系統的權力，一旦這樣的需求出現，市場上的競爭者直接拿來原廠開發的開源軟體，投入人力完善企業級需求，完全能夠提供極具競爭力的產品。例如，在 MongoDB 和 ElasticSearch 修改軟體協議之前，雲廠商拿來它們的程式碼，與自己的雲平臺進行整合。在邊際投入遞減的平臺團隊和強大的銷售團隊的支援下，雲廠商提供的服務並不比原廠差。甚至對於使用者來說，雲廠商提供的與雲平臺深度整合的服務更加方便，大廠完善的售前售後體系更加可靠。在這樣的競爭態勢下，原廠投入在軟體核心研發的產出都被競爭對手免費獲取，無法形成有效的技術壁壘，從而在商業競爭中沒有優勢。

可以說，在銷售軟體及服務的賽道里，把自己的核心軟體開源，是一件『苦恨年年壓金線，為他人作嫁衣裳』的事情。開源不僅不是商業模式，還主動放棄了往研發中心投入成本本應形成的技術壁壘。

近年來，相關企業修改軟體協議，也是為了應對上面介紹的這兩個開源模式漏洞。

Elastic 公司選擇 Elastic License 2.0[1] 重新許可核心的 ELK 套件，禁止任何人或組織破解其高階功能或提供同類服務，CockroachLabs 公司選擇 Business Source License 1.1[2] 重新許可資料庫系統核心，並在可選限制上同樣要求任何人不得提供同類(資料庫)服務。值得一提的是，這一型別的新許可並不禁止企業內部自由使用和修改原廠開發的軟體，而是旨在壟斷軟體及服務提供商的地位，即這是對上述第二個漏洞的亡羊補牢。

Lightbend 公司和 MariaDB 公司更進一步。它們不僅僅希望透過協議壟斷軟體及服務提供商的地位，還希望在生產環境使用其軟體的企業都必須取得商業許可。MariaDB 公司的核心產品 MaxScale 的軟體協議禁止使用者部署多節點叢集，而該產品的主要功能就是管理叢集和對外提供代理訪問;Lightbend 公司禁止 Akka 框架部署在任何生產環境上，但是在公司層面為年收入在一千萬美元以下的公司開放申請企業內免費使用的通道。同樣採取禁止生產環境使用的還有 Materialize 等公司。禁止生產環境使用，自然也就消滅了潛在競爭對手提供服務的可能性，這種做法一次性解決了上述兩個漏洞。

當然，這些協議不僅和典型開源協議的條款大相徑庭，也不符合開源定義[3]和其他開源組織的理念。今天，這些協議自己或其採用者會強調這只是公開原始碼的軟體協議，而不是開源協議，將其商用是受限的。

開源在企業運作中扮演什麼角色

開源不是商業模式，企業自研的核心軟體開源將面臨嚴峻的商業競爭，那麼開源在企業運作中就沒有價值了嗎?

顯然不是的。無論是企業主動使用開源軟體、參與開源軟體開發，還是開源共同體自發的創造，都會對企業運作形成可見的影響。

企業雖然缺少將核心軟體完全開放的理由，但是使用其他開源軟體卻是不可避免的。

今天的任何複雜軟體，或多或少都會有開源元件的成分。合規使用開源軟體，排查、跟進乃至修復開源軟體存在的安全風險，是企業作為使用者必須應對的問題。除此以外，當企業產品的質量與某個開源軟體產生密不可分的聯絡的時候，企業參與開源軟體開發的動機就出現了。

成熟的開源軟體定義了領域內的關鍵抽象，提供了歷經打磨和沉澱的實現。但是對於特定企業具體的場景，開源軟體未必能夠提供完美的支援。對於有研發能力的企業來說，內部維護或臨時做一個二次開發的版本非常常見，而如何處理下游版本和上游的關係，就是一個需要評估的問題。

滴滴、騰訊和華為雲都對 Apache Pulsar 有深入的使用的內部定製，Pulsar 上游社群活躍且開放，這些企業要想讓減少升級跟進上游版本的開銷，推動內部修改合入上游就是最佳策略。如果上游選擇另一種方式實現相同需求，內部整合和業務可以響應適配。即使上游不認同提出的更改，至少再做其他設計決策時，能夠考慮到使用者存在這樣的需求，不至於無意間把打補丁的路給堵死了。

如果企業對開源軟體的依賴更深，而且內部開發極其活躍，且無法與上游達成一致，那麼可能 hard fork 就是唯一的出路。PingCAP 的 TiFlash 和位元組跳動的 ByConity 對 ClickHouse 的 hard fork 就是這樣的案例，它們隨後成為了公司產品的一部分。Firebolt 更加徹底，hard fork ClickHouse 作為其雲數倉的執行引擎，並且從未有過再像 TiFlash 或 ByConity 一樣開源出來哪怕部分的想法。這也再次應證了前文提到的開源軟體本身要商業化，容易遇到拿來就用的競爭對手的強力挑戰。

除了使用開源軟體的場景，企業開源不是核心產品的基礎軟體或周邊元件，或是把核心軟體裁剪成一個基礎版本再做開源也不罕見。對於這些場景，在做軟體及其生態的開發者體驗工作時，開源的屬性和開源社群的存在，能夠提供一些優勢和額外的切入點。

典型的是由於開發者能夠接觸到原始碼，所以他可以深入理解軟體的原理，成為高階使用者，並將自己的經驗帶給其他人，提高軟體的影響力。當然，對於原始碼公開的專有軟體來說，這一點也能做到;對於閉源軟體例如 Oracle 來說，透過完善使用者手冊、提供培訓和撰文解釋原理，也能達到不錯的效果。

開源獨特的地方，在於開發者能夠自由地修改原始碼，使得適應他的執行環境和使用場景，且修改後的版本可以自由的使用，從而使得開源軟體能夠跑在許多創始團隊想不到的場合下。這就是開源合作創新理想的樣子。

最後，開源共同體自發的創造本身會影響商業環境。這個世界今天有 PostgreSQL 這樣的軟體，它幾乎做任何工作都有成熟的生態支援。這就意味著你做一個商業資料庫管理系統，必須比開源軟體做的更專業。也就是說，開源雖然不是商業模式，但是商業面臨的開源軟體挑戰是真實存在的。開源軟體因為種種原因存在，實際上提升了商業軟體的基準線，最終是對使用者有利的。

圍繞開源軟體的商業模式

這個話題我在過往的多篇文章裡都做過詳細論述，這裡只做一個簡單的羅列。

第一種是專有核心，開源周邊工具的模式。

例如 Airbyte 修改軟體協議之後，其核心和 UI 是不允許商業競爭的，而 CLI 和 Connectors 則是開放的，鼓勵開發者進行生態整合。這種模式走到極端，就是 GitHub 的服務端完全閉源，但是 API/SDK 開放，甚至有全開源的 GitHub Actions 生態，當然這個生態是繫結在 GitHub 平臺的。

第二種是核心開源，高階功能付費。

例如 GitLab 的開源版和企業版的差異化就做的不錯。通常來說，團隊協同功能、安全加密功能、合規審計功能、雲上的運維和特殊場景的整合，都是高階功能的良好候選。這一模型往往要求企業對軟體有完整的自主產權，或者在中立社群中極強的話語權，否則研發的高階功能有被上游或其他深度參與者釜底抽薪的風險。

第三種是做開源軟體的發行版。

Ubuntu 是 Linux 的發行版，以訂閱模式響應企業使用者的定製和支援請求。Cloudera 的 CDH 是大資料套件的發行版，幫助企業快速啟動一個版本相互相容的大資料平臺，遮蔽大量運維細節。Percona 和 PlanetScale 基於 MySQL 提供的資料庫服務，還有云廠商對一眾開源軟體簡易封裝後提供的服務，其實也可以算是某種發行版。

第四種是基於開源軟體做解決方案。

Databricks 基於 Apache Spark 研發定義了 AI Infra 和 Lakehouse 等產品線，Decoable 基於 Apache Flink 開發了一個實時資料處理平臺，Firebolt 拿幾個開源軟體縫合了自己的雲數倉，還發了篇論文[4]。

這些案例當中，往往企業不是開源軟體的第一作者。哪怕大家都覺得 Databricks 是所謂 Spark 背後的公司，Spark 的核心邏輯其實是在高校實驗室了開發出來的，專案捐贈給中立的 Apache 軟體基金會也發生在公司成立之前。所以這不是 open-source from scratch 的模式，而是普通的有個好的開源軟體拿來用。話語權足夠強的，不需要 fork 開發，否則可以像 Trino 一樣 hard fork PrestoDB 上游。核心商業價值在軟體之外的，不需要 fork 後閉源，否則只要協議允許，可以像 Firebolt 和太多沒有明說的企業一樣，拿到企業內部魔改，而無需公開修改後的軟體。

最後，我想說，目前仍然存在原創核心軟體開源的商業公司。例如，

•Alluxio (Alluxio)•Chef (Chef)•HashiCorp (Terraform)•JuiceData (JuiceFS)•PingCAP (TiDB)•ScyllaDB (ScyllaDB)

這些企業要麼是專注於特定行業場景，細分門檻極高，不是抄個軟體就能搶過客戶的情況;要麼是軟體本身知名度和市場佔有率還不高，競爭對手抄了還要自己幫忙吆喝。前者發展下去，可以透過把握標準和壟斷專門人才來維持市場地位;後者發展下去，則需要和其他供應商形成聯盟，建立合作，否則還會走 MongoDB 和 Elastic 的老路。實際上，MongoDB 和 Elastic 就是透過改變軟體協議，強迫供應商坐下來談合作。

往期文章閱讀

•企業開源的軟體協議模型實踐•駭客與顧客：開源軟體能商業化嗎?•企業實踐開源的動機•免費增值的商業模式

全文最後，看一個 ChatGPT 對“開源是商業模式嗎”的回答：

開源不是一種商業模式，而是一種軟體開發的方法。

開源意味著軟體的原始碼可以公開獲取和使用。這使得更多的開發者可以對軟體進行改進和最佳化，從而提高軟體的質量和穩定性。

雖然開源軟體本身免費使用，但許多開源軟體的維護、支援及其他附帶服務是可以進行商業化的。例如，Red Hat 公司就以 Linux 發行版為基礎提供商業化的支援、培訓和諮詢服務，同時也開發了自己的商業軟體產品。

因此，開源可以為商業模式提供一些有利條件，但它本身並不是一種商業模式。

原文標題《開源不是商業模式》

參考材料

•There is NO Open Source Business Model[5]

•There is Still NO Open Source Business Model[6]

•Open Source Isn't A Business Model, It's A Market Strategy[7]

•Open source is not a business model[8]

•Entrepreneurship for Engineers: Open Source Business Models[9]

•Business models for open-source software[10]

References

[1] Elastic License 2.0:

[2] Business Source License 1.1:

[3] 開源定義:

[4] 論文:

[5] There is NO Open Source Business Model:

[6] There is Still NO Open Source Business Model:

[7] Open Source Isn't A Business Model, It's A Market Strategy:

[8] Open source is not a business model:

[9] Entrepreneurship for Engineers: Open Source Business Models:

[10] Business models for open-source software: