像小強一樣堅不可摧的資料庫，CockroachDB是如何構建業務並進行盈利的？

作者丨Spencer Kimball

文章講述CockroachDB是如何圍繞開源軟體構建業務，並建立自身的盈利模式。

Cockroach產生於對可用開源資料庫和雲DBaaS服務的失望，但它從來不被認為是開源軟體。

2014年底，在GitHub社區的鼓勵和一些有遠見的風險投資家的諮詢下，我們到了做決定的時候：是否應該成立一家公司來加速CockroachDB的發展？一方面，僱傭一支優秀的團隊會讓你更快地開發出一款可行的產品。另一方面，我們的目標不再僅僅是構建下一個偉大的開源資料庫。

我們面臨著如何圍繞開源軟體構建業務的難題。

圍繞開源軟體構建業務

自從RedHat開闢了第一條道路以來，開源軟體商業模式一直在不斷發展。很少有人能成功地借用RedHat以支持和服務為中心的原始模型。事實上，大多數投資者都認為早期的開源商業模式是一個失敗的命題。這裡有兩種常見的OSS商業模式可供選擇:

核心開放。這通常涉及一個功能強大的核心產品，它是免費和開源的，通常使用APL、MIT或GPL授權。圍繞核心部分提供一組專有軟體，以添加或擴展其功能。這些專有的附加組件通常與支持和服務捆綁在一起，以商業軟體的形式出售。

使用開源軟體的雲託管服務。通常，這也涉及到私有軟體(例如多租戶、計費、服務指示板)，但是最終產品是作為服務而不是軟體銷售的。

這兩種模式正被許多公司成功地推行。Cloudera、Elastic和Confluent是我喜歡的三個案例，它們都有不同的模型，並且在不同的階段將開源產品轉化為成功的業務。

警示故事

一些OSS公司為付費功能設置的門檻太低，使得核心的OSS產品感覺「舉步維艱」。在2017年，任何擁有核心功能的產品在不需要商業許可的情況下無法擴大規模，可能就是門檻設得太低了。也有一些公司在早期未能提供足夠的專有價值，而開放核心正迅速成為一種標準的基礎設施。那些在核心產品中看到價值的，以及願意為改進產品而付費的大公司，除了建立自己的自定義擴展外，沒有別的選擇。

有一些優秀的開源軟體公司由於缺乏收入而停止開發它們的產品。最近一些，包括RethinkDB。以前，那些在默認情況下可以進入開放核心產品的公司，逐漸在生存的利益上更有眼光(參考Paul Dix』s InfluxDB 文章)。

這是一種微妙的平衡。為開源軟體構建付費的「企業」特性可能會讓人感覺骯髒。付費功能削弱了開源的吸引力，並可能導致社區的不安。另一方面，龐大的雲服務提供商在不尋找開源生態系統的情況下重新包裝開源軟體的做法，或者是1000億美元的跨國公司放棄了陷入困境的OSS公司的支持許可，這些都令人感到沮喪。如果你真的想要圍繞開源軟體建立一個公司，你必須走一條狹窄的道路，儘早引入付費功能，會有縮短使用的風險。如果引入付費功能太晚，有可能鼓勵經濟搭便車的人。在任何一個方向上偏離太遠，你的努力最終只會持續作為無報酬的開源貢獻。

那麼，CockroachDB是如何賺錢的呢？

我相信，最終我們將同時擁有雲託管模型和核心開放模型。對DBaaS的需求正在迅速發展，我們只寫好了第一章(劇透提醒：AWS正在勝出)。但在不久的將來，我們的產品將與那些打算在公共或私有雲中運行資料庫的公司更好地結合在一起。換句話說，我們追求的是核心開放模式，儘管其中有一些有趣的Cockroach實驗室的特點。

首先是許可的問題。許多採用核心開放模型的公司都將其專有特性作為封閉的源擴展來實現。另一些則發布了兩個或更多的產品，其中包括包含封閉源代碼的企業版本，並作為已編譯的二進位文件分發。這些模型存在明顯的缺陷。它們很難升級到最新版本，它們經常涉及多個開發分支，這些分支地管理令人沮喪，並且它們消除了新特性所涉及的開源的好處：外部開發人員不能調試或定製產品的專有部分。

CockroachDB社區許可證(CCL)

我們將以不同的方式提供付費的企業特性。目前，我們的GitHub上的所有內容都是按照Apache許可證2(APL)的條款進行授權的。我們所介紹的企業特性將包含在一個新的許可證所包含的源文件中，稱為CockroachDB社區許可證(CCL)。源代碼仍然是可用的，但是因為它不包括自由的再分配，所以它不是根據定義而開源的。其目的是確保企業特性的商業使用，在評估周期之外，是付費的。這些特性不會在默認情況下出現，將在文檔、代碼和幫助消息中清晰地標記出來，並且只能通過操作員或開發人員的選擇來啟用。我們發布的二進位文件將包含這些特性，但不能在FLOSS許可下進行分發。然而，也可以使用「純」FLOSS分發版，對於那些需要分發版來說企業特性是不存在的。

因為源代碼可以用於所有由CCL許可所覆蓋的特性，所以我們希望其他人能夠從我們構建的東西中學習，並且有一天可以構建更好的產品。我們希望我們的客戶能夠定製軟體以適應他們自己的需求。

我們將如何決定由CCL許可所覆蓋的特性？

這是一個很難回答的問題，也是平衡法的關鍵。我們已經將選擇的結果歸結為一個石蕊測試:創業成功所需的特性是APL，並且是開放核心的一部分；只對已經成功的公司主要有用的特性是CCL，並且是企業產品的一部分。每一個新特性的許可，我們將根據我們的直覺和社區反饋來決定。

然而，因為這樣的決定是主觀的，它們會隨著時間的推移而發展。將企業功能從CCL遷移到APL是很簡單的，我們希望這是對任何特性的一種需求，而這些特性最終都是來自於創業公司的高需求。

為了在2017年取得成功，一家初創公司需要從資料庫中獲得什麼?

這也是激發CockroachDB設計的特點:

跨數據中心的部署和一致的複製以克服失敗的災難(例如，停機和丟失或不一致的數據)。

水平的可伸縮性和雲本地設計，以保證數據架構的未來。

具有分布式ACID事務的SQL API，以及用於開發人員生產的查詢執行。

雖然上面的一些特性在其他資料庫中被認為是企業特性，但是我們相信它們是構建產品和服務的一個通用的基礎，並且在APL中仍然是免費的。畢竟，這些特性也代表了CockroachDB這款產品。

我們計劃在2017年推出兩項此類產品。

第一種是完全分布式的、擁有增量的能力，可以快速、一致地備份和恢復使用可配置存儲庫(例如S3或GCS)的大型資料庫。其中相同的功能，但非分布式的，將免費提供給所有用戶。

第二種是地理分區——一種對數據複製方式和位置進行行級控制機制的資料庫。地理分區允許一個單一的、邏輯的資料庫為地理上不同的客戶提供低延遲的訪問，並允許遵從數據主權需求。

構建CockroachDB已經兩年多了，我們現在已經接近1.0版本。我們認識到使用這些功能構建一個新的資料庫所固有的挑戰，並且我們正在努力確保能夠繼續開發CockroachDB資料庫，只要有更好的產品可以在下一個版本中發布。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！