開源軟件商業模式的探討

聲明：咱們的開源項目「 Milvus 向量搜索引擎」還處在社會主義初級階段。如下內容是咱們目前對開源工做的摸索，並不是最佳實踐。

開源許可證

既然咱們決定了要開源，第一步即是要選擇合適的開源許可證。雖然自由軟件創始人 RMS 曾經倡導 Copyleft 概念，但 Copyleft 也是一種特殊的 Copyright 。

那麼，什麼是開源許可證？簡單來講，一個許可證只要通過 OSI （ Open Source Initiative ）認證，就能夠被稱之爲開源許可證。 OSI 有專門的流程來審覈一個許可證是否符合開源定義（ Open Source Definition ）。好比說， MongoDB 新設計的 SSPL （ Sever Side Public License ）在完成 OSI 認證以前， MongoDB 只能說本身的許可證是源碼可用（ source available ），而不能說本身是開源（固然，這個限制屬於行業慣例，沒有強制性）。

目前主流的開源許可證，能夠在 OSI 網站上查詢到。網上也有不少文章去比較各個許可證之間的不一樣（可參考阮一峯老師的博客），我就不一一贅述了。這裏主要結合咱們的自身狀況來談一下開源許可證的選擇。開源許可證簡單來講，能夠分爲三檔：

• 嚴格，以 GPL 2.0 許可證爲表明，典型軟件是 MySQL
• 適中，以 Apache 2.0 許可證爲表明，目前使用最普遍
• 寬鬆，以 BSD，MIT ， PostgreSQL 許可證爲表明，典型軟件是 PostgreSQL

熟悉數據庫的朋友必定知道 MySQL 和 PostgreSQL 。 MySQL 是最流行的開源數據庫，但 PostgreSQL 是衍生項目最多的開源數據庫。如今的新項目不多使用 GPL 2.0 許可證，它的傳染性應該是你們最有顧慮的地方。

對於推廣基礎技術來講，MIT/BSD 類的許可證是一個好選擇。可能如今已經不多人使用 FreeBSD 。但它也還在不斷的發展，由於採用很是寬鬆的 2-Clause-BSD 許可證， FreeBSD 被很多廠商用來開發本身的閉源系統。好比， Sony 的 Play Station 3 和 4 的系統都基於 FreeBSD ， 還有任天堂的 Swtich 遊戲機也是。

Redis 也採用寬鬆的 3-Clause-BSD 許可證（相比 2-Clause 多了對商標的使用限制）。不過， Redis 整個工具鏈的許可證狀況十分複雜。以致於當 Redis 切換部分組件的許可證時，引發了業界很大的誤解。所以中途將許可證變嚴格是件有點敏感的事情。

看起來頗爲複雜的 Redis 許可矩陣。

若是上策太急，下策太緩。那麼就選擇中間的 Apache 2.0 。Apache 2.0 目前是 Apache 基金會與 CNCF 基金會推薦的默認開源許可證。

Github 網站對 Apache 2.0 許可證的簡易說明

Apache 2.0 像其餘開源許可證同樣不限制商業使用，專利受權也默認包含其中。不過 Apache 2.0 也明確規定了在此開源許可證下軟件廠商的免責條款。這也就是開源軟件公司提供訂閱增值服務的法律基礎。

不過即便是 Apache 2.0 這麼成熟的開源許可證，你們仍是有一個擔憂：公有云。

須要防範公有云廠商嗎

開源軟件與公有云的關係這兩年有點緊張，一個比較流行的觀點是公有云插管吸血開源軟件，而對開源社區沒有太多貢獻。很多開源項目開始尋找在公有云面前保護本身的方法。畢竟公有云的出現，必定程度上打亂了原有的開源商業模式。最終用戶經過購買雲服務，從公有云服務商那裏的到了保障，開源廠商被繞開了。

因而， Common Clause 應運而生。 Common Clause 是一種附加條款，開源廠商依然須要選擇一個基本的主許可證。最終的形式相似： Apache 2.0 + Common Clause 1.0 。

Common Clause 比較精煉，全文只有 3 句話，以下：

The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.

Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.

For purposes of the foregoing, "Sell" means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.

Common Clause 主要禁止他人在不增長開源軟件價值的狀況下，利用開源軟件牟利。它的限制性主要體如今如下三點：

禁止他人	對軟件生態構建的影響
利用原軟件進行 license 銷售	很是小。目前主流觀點是開源軟件不收取 license 費用，軟件收費以按年支付的訂閱模式進行。
提供軟件支持服務	比較小。尤爲是產品初期，你們都不瞭解，須要依靠官方支持。官方提供訂閱模式，你們比較容易接受。產品的訂閱收費模式可以獲得保障。不過未來等產品成熟之後，須要考慮參照 Oracle 的 OCP 方式，提供一些針對專業人士的產品能力認證，以緩和這一點可能的影響。
提供軟件託管服務	防範雲廠商。限制雲廠商不能經過託管雲服務（ hosting ）的方式，利用原軟件進行盈利。但不表明用戶不能在雲環境裏使用該軟件。Apache 2.0 + Common Clause 1.0 不會限制用戶運行軟件的硬件環境，只要用戶購買訂閱服務，產品方同樣會提供支持服務。

假設第三方在開源軟件的基礎上構建了一整套面向用戶的應用，這套新應用增長了原開源軟件的價值，那麼這套新應用不會受到任何限制。這一點保證了開源廠商與合做夥伴之間的合做關係不會受到影響。

不過 Common Clause 沒有通過 OSI 認證，所以添加了 Common Clause 之後建議只說本身是源碼可用（ source available ）。雖然會引發必定的爭議，不過初創開源項目選擇添加 Common Clause 看起來正受到愈來愈多人的理解。

然而，咱們的開源項目並不打算加上 Common Clause 。有兩個重要的緣由。

MongoDB 的啓示

MongoDB 是開源項目成功的範例。 MongoDB 一開始就採用 AGPL 3.0 許可證。若是公有云要利用 MongoDB 提供服務，那麼公有云廠商須要公佈相關底層服務的源碼。所以， AWS ， Azure， Google Cloud 等一衆美國公有云都選擇自行開發文檔型數據庫。而在美國之外， MongoDB 卻很難用法律武器保護本身。 2018 年 10 月 MongoDB 修改新版本的許可證時，再次抱怨了公有云廠商對 MongoDB 利益的侵害，主要指的就是美國之外的公有云廠商。所以，志在全球的開源基礎軟件廠商其實很難僅靠一個許可證來對本身進行全面的保護。

另外一方面，當 AWS 有了 DynamoDB ； Azure 有了 Cosmos DB ； Google Cloud 有了 Cloud Firestore 以後，文檔數據庫再也不是 MongoDB 一家獨大。在以後的移動互聯網浪潮中，移動端的 MongoDB Mobile 沒有達到期待中的影響力。畢竟 Realm 這樣的移動端文檔數據庫能夠直接和多個公有云文檔數據庫同步，極大的方便了移動開發者。2019 年 4 月， MongoDB 以 3900 萬美圓收購了 Realm 。

防範別人的同時也部分影響了本身的發展空間，是否值得？答案因人而異，開源項目須要結合自身狀況做出一個選擇。

四爺的新策略

據諮詢公司 Gartner 的統計， Google Cloud 2018 年佔據公有云 IaaS 市場 4.0% 的份額，排行全球第四。依然不及老大 AWS 市場佔有率（ 47.8% ）的一個零頭。 Google Cloud 想迎頭遇上，他該怎麼辦？

在今年的 Google Cloud Next 大會上，新上任的 Google Cloud CEO 一舉請來了 Redis Lab CEO 與 MongoDB CEO 幫忙站臺。大會上 Google Cloud 推出了 Redis 的託管服務， MongoDB 上了 Google Cloud Marketplace 。後續 MongoDB 的 Atlas 雲服務還和 Google Cloud 展開了一系列合做。

Redis 和 MongoDB 在開源界與互聯網行業有較大的技術影響力。並且他們是開源界對公有云廠商開炮比較多的兩家。近期他們又前後針對公有云廠商修改了本身的許可證。所以 Google Cloud Next 大會上傳達的信息頗有意思。 與成熟的開源廠商合做，看起來正是 Google Cloud 的新策略。這條路值得一試。畢竟，老四恐怕很難用老大的方法來打敗老大。

「學我者生，似我者死。」 —— 齊白石

Google Cloud 第一個想明白了。我相信會有愈來愈多的公有云廠商想明白這個問題，選擇與成熟的開源廠商合做。因此對開源基礎軟件來講，當務之急是提高自身的成熟度，防範之心能夠暫時放到一邊。

商業設計

在上一篇文中，咱們提到「 Apache 基金會擁有 1.9 億行代碼。根據 COCOMO II 模型估算，這些代碼的開發成本超過 200 億美圓（ 2019 年報）。」如此算來，每一行代碼的開發成本超過 200 美圓。因此千萬別以爲開源軟件就該無償使用。

典型的開源商業模式

目前比較成熟的開源軟件商業模式有如下幾種：

• 訂閱服務：開源許可證免除了廠商對軟件質量與軟件缺陷修復的責任。而這些都是企業級應用所必須的。所以，最天然的商業模式就是提供軟件訂閱服務，從而向用戶提供生產級的服務支持響應和 hotfix 修復。
• 高級功能：好比 Redis 。核心部分的組件是開源的。但工具類軟件，進階功能（如多租戶，無共享分佈式架構等）都是收費的。
• 雲服務：好比 Databricks 。 Spark 是開源的，但收費版本僅提供 Azure 和 AWS 上的雲服務。
• 生態收益（僅限超大型開源廠商）：好比據華爾街分析師估算 Google 每一年要支付近百億美圓給 Apple ，就爲了 iPhone 上的默認搜索引擎入口。想一想 Android 幫 Google 省了多少錢？

軟件世界裏有兩個重大難題：一是大型軟件系統的項目管理（人月神話），另外一個是軟件訂價。關於項目管理，已經有了很多的研究與實踐，你們多少有個參照物。而軟件訂價沒有什麼成熟的公式與模型。

但至少對於開源軟件的訂價，要避開下面兩個坑：

• 定高價，打 1 折
• 不採用訂閱模式

這些都是傳統商業軟件的模式。傳統商業軟件提供給客戶的是資產，開源軟件提供給用戶的是服務。

若是大型用戶要求對軟件進行買斷怎麼辦？大型用戶傾向於一次性付費，並非他們喜歡購買一堆軟件資產。背後的緣由在於大型用戶內部的軟硬件採購流程，須要採購人員與 IT 技術人員共同介入。而採購並非技術人員的本職工做，以及過後的各類審計。所以技術人員更喜歡一次性買斷，以省去將來的麻煩。請提醒他們，開源軟件提供的是服務，服務是不能買斷的，應該走更便捷的服務採購流程。

向 AWS 學習

基礎軟件的商業化是件頗有挑戰的事情。好在有不少成熟的企業可供咱們參考。若是說 Oracle 是必須研究的傳統商業軟件公司，那麼 AWS 毫無疑問就是必須好好學習的雲服務公司。

剛纔說軟件訂價沒有什麼成熟的公式與模型？其實 AWS 幫你們摸索了一個公有云上軟件的訂價方式。AWS Aurora 數據庫據稱是 AWS 上增加最快最賺錢的雲服務。 Aurora 在技術上是很是創新的雲原生數據庫，帶出了一衆追隨者。依據官方宣傳：

Amazon Aurora 的速度最高能夠達到標準 MySQL 數據庫的五倍、標準 PostgreSQL 數據庫的三倍。它能夠實現商用數據庫的安全性、可用性和可靠性，而成本只有商用數據庫的 1/10。（引用自 https://aws.amazon.com/cn/rds/aurora/ ）

那麼這樣一款技術如此先進的雲上數據庫是怎麼訂價的呢？如下對比 Aurora MySQL 全部可選的實例規格與 RDS MySQL 之間的訂價：

雲實例規格	RDS MySQL	Aurora MySQL	Aurora 溢價
db.t3.small	0.034	0.041	20.59%
db.t3.medium	0.068	0.082	20.59%
db.t2.small	0.034	0.041	20.59%
db.t2.medium	0.068	0.082	20.59%
db.r5.large	0.24	0.29	20.83%
db.r5.xlarge	0.48	0.58	20.83%
db.r5.2xlarge	0.96	1.16	20.83%
db.r5.4xlarge	1.92	2.32	20.83%
db.r5.12xlarge	5.76	6.96	20.83%
db.r4.large	0.24	0.29	20.83%
db.r4.xlarge	0.48	0.58	20.83%
db.r4.2xlarge	0.96	1.16	20.83%
db.r4.4xlarge	1.92	2.32	20.83%
db.r4.8xlarge	3.84	4.64	20.83%
db.r4.16xlarge	7.68	9.28	20.83%

單位：美圓/小時

固然 Aurora MySQL 和 RDS MySQL 的技術實現不太同樣，一樣實例規格須要的硬件也不能簡單劃上等號。不過考慮到 AWS 自己的體量，二者間硬件差別的成本應該是微乎其微的。能夠大體認爲 20% 的溢價來自 Aurora MySQL 軟件。

基礎軟件上公有云 Marketplace 的時候怎麼訂價，總算有個參照物了。

後記

雖然寫了兩篇文章，但也只是涉及了開源的一小部分。開源模式可一點也不比傳統商業軟件的模式要簡單。

其中比較關鍵的社區運營和開發者生態構建，咱們也還在不斷的摸索。等有一天咱們造成本身的方法與風格，屆時必定與你們分享。但願國內的基礎軟件同行都能一塊兒進步。