文章講述CockroachDB是如何圍繞開源軟件構建業(yè)務，并建立自身的盈利模式。

　　Cockroach產(chǎn)生于對可用開源數(shù)據(jù)庫和云DBaaS服務的失望，但它從來不被認為是開源軟件。

　　2014年底，在GitHub社區(qū)的鼓勵和一些有遠見的風險投資家的咨詢下，我們到了做決定的時候：是否應該成立一家公司來加速CockroachDB的發(fā)展？一方面，雇傭一支優(yōu)秀的團隊會讓你更快地開發(fā)出一款可行的產(chǎn)品。另一方面，我們的目標不再僅僅是構建下一個偉大的開源數(shù)據(jù)庫。

　　我們面臨著如何圍繞開源軟件構建業(yè)務的難題。

　　圍繞開源軟件構建業(yè)務

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

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

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

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

　　警示故事

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

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

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

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

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

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

　　CockroachDB社區(qū)許可證（CCL）

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

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

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

　　這是一個很難回答的問題，也是平衡法的關鍵。我們已經(jīng)將選擇的結(jié)果歸結(jié)為一個石蕊測試：創(chuàng)業(yè)成功所需的特性是APL，并且是開放核心的一部分；只對已經(jīng)成功的公司主要有用的特性是CCL，并且是企業(yè)產(chǎn)品的一部分。每一個新特性的許可，我們將根據(jù)我們的直覺和社區(qū)反饋來決定。

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

　　為了在2017年取得成功，一家初創(chuàng)公司需要從數(shù)據(jù)庫中獲得什么？

　　這也是激發(fā)CockroachDB設計的特點：

　　跨數(shù)據(jù)中心的部署和一致的復制以克服失敗的災難（例如，停機和丟失或不一致的數(shù)據(jù)）。

　　水平的可伸縮性和云本地設計，以保證數(shù)據(jù)架構的未來。

　　具有分布式ACID事務的SQL API，以及用于開發(fā)人員生產(chǎn)的查詢執(zhí)行。

　　雖然上面的一些特性在其他數(shù)據(jù)庫中被認為是企業(yè)特性，但是我們相信它們是構建產(chǎn)品和服務的一個通用的基礎，并且在APL中仍然是免費的。畢竟，這些特性也代表了CockroachDB這款產(chǎn)品。

　　我們計劃在2017年推出兩項此類產(chǎn)品。

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

　　第二種是地理分區(qū)——一種對數(shù)據(jù)復制方式和位置進行行級控制機制的數(shù)據(jù)庫。地理分區(qū)允許一個單一的、邏輯的數(shù)據(jù)庫為地理上不同的客戶提供低延遲的訪問，并允許遵從數(shù)據(jù)主權需求。

　　構建CockroachDB已經(jīng)兩年多了，我們現(xiàn)在已經(jīng)接近1.0版本。我們認識到使用這些功能構建一個新的數(shù)據(jù)庫所固有的挑戰(zhàn)，并且我們正在努力確保能夠繼續(xù)開發(fā)CockroachDB數(shù)據(jù)庫，只要有更好的產(chǎn)品可以在下一個版本中發(fā)布。