人类有一种强烈的倾向，就是把新出现的事实塞进已有的分类里。这在思维和文化上有助于把相似的事件归到同一个逻辑框架下，所以两天前当我澄清 Redis 核心仍以标准的 BSD 许可证发布，只有 Redis Labs 开发的若干 Redis 模块将要变更许可证、从 AGPL 转为另一种非开源许可证时，大家便说：“啊，明白了，你们这是要搞开放核心了。”

如果你真想弄清这里到底发生了什么，这种简化就行不通了。开放核心技术需要具备两个条件。一是系统本身是模块化的，二是系统的某些部分被做成专有，以此围绕原本自由的软件打造产品。例如，把数据库的单节点版本开源，而把集群的逻辑和机制放在另一层非自由的代码中实现，这就是开放核心技术。同样，如果我写一个带有模块化存储系统的关系型数据库，但唯一能提供强一致性保证的存储引擎却是非自由的，这也属于开放核心。在围绕开源系统的开放核心商业模式中，*根本*的一点就是你必须从自由软件的那部分拿走一些有用的东西。

如今 Redis 早已是一个模块化系统。你可以利用 Redis 模块做很多事情，包括借助最近引入的集群消息总线 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 双方来说都是一个很大的优势：在内部只需负担我和另外几位开发者的开源开发时间，成本相对较低，而可以把其余资源投入到对 Redis Labs 业务更有用的开发上，比如确保 Redis 企业版的 SaaS 和产品足够好。无论如何，社区依然贡献了大量代码。而我也一直在对那些想把 Redis 带向其他领域的各种花哨想法说“不”……这本身也是个问题。

但如果能有类似 Redis、却又在 Redis 范畴之外的东西，依然会很酷，因为你知道，虽然这不是 Redis 的使命，人们确实可能非常需要一个可以实时写入、同时每核又能支撑大量查询的快速倒排索引及其全文搜索能力。这正是 Redis Labs 正在做的——沿用同样的 Redis 技术和思路，去做比 Redis 原本想做的更多的事。不仅是在功能层面，也包括一致性模型等其他方面。我在某些事情上观点很鲜明，比如我认为 CRDT 虽然在某些场景下非常酷，但对 Redis 而言并不是正确的选择，如果要保持同样的内存占用、性能和简洁性，哪怕代价是采用更弱的一致性模型。所以 Redis Labs 与该领域的一位顶尖研究者一起把它做了出来（而且这是一个不提供任何源码的专有产品）。我能看出这样的功能对某些业务会极其有用，但 Redis 本来就不是为了解决所有问题而生的，而 Redis Labs 去做了。

这不是开放核心。Redis Labs 正在做的，是你永远不会看到我去做的事：出于精力所限，也因为我认为并非所有软件最终都必须变得庞大。

所以我认为把这种模式称为“开放核心”是具有误导性的，Redis 的餐桌上什么都没有被拿走，只是在 Redis 项目原本未曾触及的其他领域，以“Redis 之道”去探索新的事物。