人類有一種強烈的傾向，會把新的事實套進既有的分類中。這在心智與文化上有其用處，能讓我們把相似的事件歸在同一個邏輯框架下理解，因此兩天前當我澄清 Redis 核心仍以原汁原味的 BSD 授權釋出，只有由 Redis Labs 所開發的特定 Redis 模組將變更授權，從 AGPL 改為另一種非開源授權時，大家便說：「啊！好吧，你們是要走 open core(開放核心) 了。」

然而，如果你真心想掌握這裡發生的真相，這種簡化的歸類這次就行不通了。open core 技術需要兩個條件。其一是系統必須是模組化的，其二是將系統中的某些部分轉為專有，以便在原本自由軟體的基礎上打造出產品。舉例來說，只把資料庫的單一節點以開源形式提供，然後把叢集的邏輯與機制實作在另一個非自由的層級中，就是一種 open core 技術。同樣地，如果我寫了一個具備模組化儲存系統的關聯式資料庫，但唯一能提供強保證的儲存引擎卻是非自由的，那也是 open core。在圍繞開源系統的 open core 商業模式中，*最根本的*一點就是你必須把某些有用的東西從自由軟體的那一部分拿走。

如今 Redis 已經是一個模組化系統好一段時間了。你可以利用 Redis 模組來撰寫各式各樣的東西，包括運用最近推出的 cluster message bus API 來打造新的分散式系統，或是看起來像原生的全新資料型別。然而，讓 Redis 走向模組化的原因，並不是為了把系統中某些有用的東西拿掉然後貼上價籤。舉例來說，Redis 5 中新的資料結構之一 streams，就是核心的一部分，並以 BSD 授權釋出。streams 是在 Redis 已經是模組化系統之後才實作的。

Redis 模組的起源來自一個不同的觀察。作為前提，我得先說我在軟體開發上是個非常保守的人。我認為 Redis 應該專注於處理那些透過記憶體內資料結構來操作時，相較於其他做法能帶來明顯優勢的事情。我不希望 Redis 去做比現在更多的事情，也不希望它去嘗試每一種可能的一致性取捨。我希望 Redis 就是 Redis，也就是開發者可以用不同方式來解決特定問題的通用工具。

然而在 Redis Labs，我們多次觀察到，Redis 無法解決某些特定問題其實有點可惜。舉例來說，如果 Redis 是一個像樣的全文搜尋引擎會怎麼樣？還有，開發者如此渴望 JSON，那麼提供一個能直接以 JSON 溝通的 API 又如何？再者，既然記憶體內的圖資料若以巧妙的方式呈現可以非常快速，那麼具備豐富查詢語言的圖資料庫能力又如何呢？Redis Labs 的客戶也經常直接提出這類需求。而事實上，這些功能或許很酷，但那不是 Redis，我沒興趣，而且 Redis 開源這一端的開發能量也無力長期維護這些東西，順帶一提。這對 Redis 和 Redis Labs 雙方來說都是一大優勢：在內部只要相對低廉的成本，支應我和另外少數幾位投入 OSS 開發的時間，同時把其餘資源分配給對 Redis Labs 業務有用的開發上，例如確保 Redis 企業版 SaaS 與產品的品質。無論如何，社群仍持續帶來大量的貢獻。而我也一直對那些想把 Redis 帶往其他領域的華而不實的點子說「不」……這本身也是一個問題。

儘管如此，能擁有這些類似 Redis、卻在 Redis 範疇之外的東西，還是很棒的，因為你知道，雖然那不是 Redis 的使命，人們確實可能需要一個可以即時寫入、同時每個核心又能處理相當大量查詢的快速反向索引全文搜尋能力。這正是 Redis Labs 正在做的事，它運用相同的 Redis 技術與理念，去做比 Redis 原本想做的更多事情。不僅是在功能面上，也在像一致性模型等其他面向。我在某些事情上立場非常鮮明，例如我認為 CRDTs(無衝突複寫資料型別) 雖然在某些使用情境下非常酷，但對 Redis 而言並不是正確的選擇，若要保留同樣的記憶體佔用、效能與簡潔性，即使代價是擁有較弱的一致性模型。因此，Redis Labs 與該領域的一位頂尖研究者一起把它做出來了（而且這是一個沒有提供任何原始碼的專有產品）。我能理解這樣的功能對某些營運情境會非常有幫助，但 Redis 本來就不是為了解決所有問題而生，而 Redis Labs 把它實現了。

這不是 open core。Redis Labs 正在做的是你絕不會看到我去做的事：出於頻寬考量，也因為我相信並非所有軟體最終都必須變得龐大。

所以我認為，把這種模式稱為「open core」是會造成誤導的，Redis 的餐桌上沒有任何東西被拿走，只是在 Redis 專案原本未觸及的其他領域中，嘗試遵循「Redis 之道」去探索新的事物。