作者 | 顧鈞

責編 | 胡巍巍

出品 | CSDN（ID：CSDNnews）

很多創業公司苦惱于如何設計開源項目的商業模式，以下內容是筆者目前對此問題的摸索，權當拋磚引玉。

1.開源許可證

既然我們決定了 “Milvus 向量搜索引擎”（筆者所在公司在GitHub上開源項目）要開源，第一步便是要選擇合適的開源許可證。雖然自由軟件創始人 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 這么成熟的開源許可證，大家還是有一個擔心：公有云。

2.需要防范公有云廠商嗎？

開源軟件與公有云的關系這兩年有點緊張，一個比較流行的觀點是公有云插管吸血開源軟件，而對開源社區沒有太多貢獻。

不少開源項目開始尋找在公有云面前保護自己的方法。畢竟公有云的出現，一定程度上打亂了原有的開源商業模式。最終用戶通過購買云服務，從公有云服務商那里得到了保障，開源廠商被繞開了。

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

Common Clause 比較精煉，全文只有 3 句話。

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

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

不過 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 第一個想明白了。我相信會有越來越多的公有云廠商想明白這個問題，選擇與成熟的開源廠商合作。所以對開源基礎軟件來說，當務之急是提升自身的成熟度，防范之心可以暫時放到一邊。

3.商業設計

在上一篇文中，我們提到“ Apache 基金會擁有 1.9 億行代碼。根據 COCOMO II 模型估算，這些代碼的開發成本超過 200 億美元（ 2019 年報）。”如此算來，每一行代碼的開發成本超過 100 美元。所以千萬別覺得開源軟件就該免費使用。

典型的開源商業模式

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

• 訂閱服務：開源許可證免除了廠商對軟件質量與軟件缺陷修復的責任。而這些都是企業級應用所必須的。因此，最自然的商業模式就是提供軟件訂閱服務，從而向用戶提供生產級的服務支持響應和 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 之間的定價：

當然 Aurora MySQL 和 RDS MySQL 的技術實現不太一樣，同樣實例規格需要的硬件也不能簡單劃上等號。

不過考慮到 AWS 本身的體量，兩者間硬件差異的成本應該是微乎其微的。可以大致認為 20% 的溢價來自 Aurora MySQL 軟件。

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

4.后記

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

其中比較關鍵的社區運營和開發者生態構建，我們也還在不斷的摸索。等有一天我們形成自己的方法與風格，屆時一定與大家分享。希望國內的基礎軟件同行都能一起進步。

作者簡介：顧鈞，ZILLIZ首席架構師，畢業于北京大學。15年數據庫相關工作經驗。目前在ZILLIZ從事異構眾核數據分析引擎的產品化工作。加入ZILLIZ之前，曾就職于IBM、Morgan Stanley、華為等跨國公司。

【END】