隨著企業嘗試改變業務模式以在雲端架構時代有效運營，開源的可行性仍然是一個熱門話題。在這篇文章中，我探討了開源作為長期商業模式的可行性的基本問題。這篇文章是由Cockroach Labs最近宣布的有關許可變更的公告引發的，這實際上相當於他們完全放棄開源。
分析 Cockroach Labs 的許可證變更
Cockroach Labs 授權變更的關鍵在於，他們現在已經取消了核心產品，並要求所有使用其軟體、收入超過 1000 萬美元的組織支付專有的 CockroachDB Enterprise 授權費用。讓我們來看一些歷史背景。
2019 年 7 月，Cockroach Labs 將 CockroachDB Core 的授權從 Apache 2.0 更改為限制更嚴格的商業原始碼授權。他們還透過商業企業許可證來限制對許多關鍵功能（例如，讀取已提交事務隔離、多區域功能和資料加密）的存取。他們追隨了限制 葡萄牙 電話號碼庫 核心資料庫存取和功能的趨勢，這些趨勢被 MongoDB、Confluence（Apache Kafka 背後的公司）、Elastic、Redis Labs 等一系列前開源專案所採用。
大約在同一時間，我們決定全面投入開源，將 YugabyteDB 授權模式從開放核心切換為 Apache 2.0。此變更向所有使用者開放了資料庫中的企業功能。
Cockroach Labs 現在更進一步，完全取消了免費的核心產品。身為分散式 SQL 資料庫公司（也是競爭對手）的創辦人，我可以猜測（並理解）導致 Cockroach 放棄其開源產品的收入壓力。但是，我認為這是短期思維可能扼殺長期成長的一個例子。
扼殺長期成長引擎－Oracle、MySQL，全部結束
Cockroach Labs 的新授權模式要求公司「如果您的企業成功且收入成長超過 1000 萬美元，則需要付費」。而較小的企業（收入低於 1000 萬美元的企業）需要強制發回遙測數據，大概是為了識別用戶並提取收入（臭名昭著的 Oracle 審計會檢查任何人嗎？）
我想知道有多少開發人員和組織會傾向於採用 CockroachDB 作為入門資料庫，因為他們現在需要考慮其業務收入達到 1000 萬美元的影響（成本、授權等）。
當開發新的應用程式時，企業通常專注於使該應用程式成功，而不是花時間在使用哪個資料庫上——工程組織的理由是，一旦成功，就完全值得遷移或重寫。如今，首選的資料庫是 PostgreSQL，當應用程式起飛時，
組織最終簽約使該資料層成為「雲端原生」。
然而，如果有一個資料庫能夠提供與 PostgreSQL 等效的無摩擦入口點，同時在第一天就提供雲端原生功能，他們會選擇它。但是，與 PostgreSQL 選項相比，迫使他們考慮對業務的影響會增加太多的摩擦，從而扼殺成長引擎。
當 Oracle 有效收購 MySQL 時，市場擔心 MySQL 作為開源產品的長期生存能力。這損害了 MySQL 並導致新應用程式的採用速度放緩。因此，在過去十年中，MySQL 相對於（開源）PostgreSQL 等替代品的地位明顯下降。請參閱下面的 DB-Engines 排名圖表（記住 Y 軸是對數刻度）。
自從 PostgreSQL 被 Oracle 收購以來，MySQL 正在失去與 PostgreSQL 相比的動力
圖：MySQL 被 Oracle 收購後，與 PostgreSQL 相比正在失去動力
CockroachDB 已經缺乏 MySQL 和 PostgreSQL 所享有的 取得 2023 年 wordpress 最佳主題 幾乎普遍的採用水平，扼殺頂部的成長引擎將更快、更痛苦地影響 CockroachDB。
「退出到 Postgres」資料庫風險緩解策略
為什麼 PostgreSQL 的完全相容性如此重要？
因為，遷移到新資料庫的組織希望確保他們可以輕鬆遷移（回）到 PostgreSQL 作為風險緩解選項。 CockroachDB 並不真正相容於 PostgreSQL，這使得移出和移回 PostgreSQL 變得非常困難。
我們知道，因為我們已經嘗試過。一位 YugabyteDB 社群使用者詢問如何從 YugabyteDB Community Slack 上的 CockroachDB 遷移。您可能會認為與 PostgreSQL 的「線路相容性」使這一切變得容易。事實並非如此。從 PostgreSQL 和 CockroachDB 匯出資料的方式沒有相似之處。
由於 PostgreSQL 令人難以置信的功能集，我們設法找到了一個解決方案，但 CockroachDB 的非標準 API 並沒有讓這一切變得容易。您可以在 Franck Pachot 撰寫的這篇部落格文章中閱讀有關將資料從 CockroachDB 移至 PostgreSQL 或 YugabyteDB 的所有詳細資訊。現在您也可以使用我們的資料庫遷移工具YugabyteDB Voyager來實現此目的 – 該工具在 Apache 2.0 授權下完全開源，重申了我們的開源立場。
YugabyteDB與 PostgreSQL 完全相容，並且可以與 PostgreSQL 互通。這意味著我們可以保證寫入 YugabyteDB 的應用程式可以無需更改地遷移到 PostgreSQL。另一方面，無法從 CockroachDB 遷移到 PostgreSQL（由於缺乏相容性）意味著您面臨長期供應商鎖定的風險。
與 PostgreSQL 競爭時，MongoDB 手冊並不適用
如果您是開始建立新應用程式的開發人員，您會選擇最受歡迎、廣受支援的開源資料庫 (PostgreSQL)，還是專有的「類似但不完全是 Postgres」資料庫？
明智的選擇顯然是 PostgreSQL。
現在，如果您想將擴充應用程式遷移到分 ws資料庫 散式資料庫，為什麼要選擇與 PostgreSQL 不完全相容的專有資料庫（CockroachDB 與 PostgreSQL 有點相容，但不完全相容）（因此開發人員不喜歡這樣做）非常熟悉），並且會鎖定您？
有人可能會說，這項策略遵循了 MongoDB 的策略，並且取得了成功。但「Mongo 就是這麼做的」的說法並不成立。 MongoDB 透過引入新的資料模型（文件）進行創新，並利用該模型快速成長。他們也已經成為文件資料庫領域的領導者——尋求文件資料模型易用性的開發人員最終會選擇 MongoDB，沒有既定的替代方案。因此，「MongoDB 成長手冊」在這裡不太適用。
在本例中，CockroachDB 是一個類似 PostgreSQL 的關聯式資料庫。 Cockroach Labs 的這項聲明實際上使 CockroachDB 與 PostgreSQL 展開競爭，而不是提供補充解決方案。
反對 PostgreSQL 的宣傳只能到此為止——Postgres 是完全開源的，並且擁有更大（熱情）的用戶和貢獻者社群。
重申 YugabyteDB 的 OSS 立場
現在是我們重申對開源承諾的好時機。五年前，我們決定在 Apache 2.0 授權下讓 YugabyteDB 100% 開源，包括先前閉源的企業功能。
當領先的資料庫和資料基礎設施公司放棄部分或全部核心專案的開源許可證時，我們選擇確認我們對開源的承諾
當我們審視當今行業正在發生的事情時，我們選擇開源的理由仍然同樣有效，而且事實上變得更加強大。我們採用開源並不是純粹「不惜一切代價」保持開放的無私舉動，而是出於良好的商業原因。
免費開源產品的可用性使企業客戶有信心購買商業軟體。為什麼？因為如果與供應商的商業關係因任何原因惡化，客戶可以依靠開源產品。
擁有開源選項可以為客戶提供策略選擇。當企業考慮使用 Yugabyte 和 Cockroach 等現代「新興」資料庫供應商的資料庫時，這種風險緩解是一個重要的考慮因素。
OSS 成長引擎 – 超過 10K 的使用者社群（以及數百萬個部署！）
開源模型仍然是開發和分發關鍵業務基礎設施軟體最成功的方法之一。
組織可以免費開始使用開源軟體，無需與銷售人員交談或提出演示請求或聯絡我們表格。這使得指數級採用成長成為現實。
證據就在布丁裡。在過去的五年裡，我們已經建立了超過 10,000 名的用戶社群（光是 YugabyteDB Slack 社群就有近萬用戶），部署了數百萬個叢集。此開源軟體補充了我們的託管雲端資料庫服務YugabyteDB Aeon，降低了採用 YugabyteDB 的准入門檻。
據我所知，在短期內，開源的使用可能會蠶食供應商的商業產品。但是，有必要讓所有使用者有機會不受限制地體驗 YugabyteDB 的強大功能和有效性。最終，更多的使用會促進更多的商業成功，反之亦然。
YugabyteDB 採用開源的一個令人高興的結果是，它實現了高速、協作、社群驅動的開發所需的回饋循環。 YugabyteDB 充滿活力、快速發展的 Slack 社群由10,000 名成員組成，正在積極使用該軟體，相互支持並提供回饋（和程式碼！）。生態系統整合、可擴展性框架和其他企業功能自然就變強了。
未來是 PostgreSQL
PostgreSQL是業界最受歡迎的RDBMS之一，提供了成熟且極為強大的資料生態系統。 Postgres 獲勝是因為它 100% 開源、成熟、功能豐富，並且擁有龐大的用戶生態系統。
毫無疑問，PostgreSQL 正在成為雲端原生事務資料庫的預設 API。
YugabyteDB 是最早選擇 PostgreSQL 作為其關聯式 API 的雲端原生資料庫之一
圖：YugabyteDB 是最早選擇 PostgreSQL 作為其關聯式 API 的雲端原生資料庫之一。
我們很早就認識到了這種轉變，並在 2017-2018 年宣布了 PostgreSQL 相容性。我們還發現與 Postgres 的線路相容性還不夠 – 客戶想要完全相容性，即運行時相容性，以確保重試、錯誤代碼等相容。透過從頭開始建立 PostgreSQL API 來實現這一目標是不可行的。 YugabyteDB 重複使用 PostgreSQL 查詢層來實作 PostgreSQL 執行階段相容性。
作為與 PostgreSQL 運行時相容的資料庫，YugabyteDB 還繼承了 PostgreSQL 整合的龐大生態系統，無需對程式碼進行任何更改。