CockroachDB是如何建構業務并進行盈利

原文：How We’re Building a Business to Last

作者： 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資料庫，隻要有更好的産品可以在下一個版本中釋出。