人类有很强的倾向，会把新事实归入既有的分类。这在心智和文化上有助于将相似的事件归到同一个逻辑范畴下，因此两天前当我澄清 Redis 核心仍以原版 BSD 许可证发布，只有 Redis Labs 开发的某些 Redis 模块将变更许可证，从 AGPL 变为另一种非开源许可证时，人们说：“啊！明白了，你们是要走 open core(开放核心)了”。

如果你真的想弄清这里究竟发生了什么，这种简化这次就行不通。open core 技术需要两个条件。一是系统是模块化的，二是将系统中的部分内容变为专有，以便围绕原本自由的软件来打造产品。例如，将数据库的单节点作为开源提供，而将集群逻辑和机制在另一个非自由层中实现，就是一种 open core 技术。同样，如果我写一个带有模块化存储系统的关系型数据库，但唯一能够提供强保障的存储是非自由的，那也属于 open core。在围绕开源系统的 open core 商业模式中，*根本*的一点在于，你要从自由软件部分拿走某些有用的东西。

如今 Redis 在一段时间内已经是一个模块化系统。你可以使用 Redis modules 来编写许多东西，包括利用最近引入的 cluster message bus API 编写新的分布式系统，或是看起来像原生的新数据类型。然而，让 Redis 模块化的原因，并不是为了从系统中移除某些有用的东西并为其标价。例如，Redis 5 中新增的数据结构之一 streams，就是核心的一部分，并以 BSD 许可证发布。streams 是在 Redis 已经成为模块化系统之后才实现的。

Redis modules 源于另一个不同的观察。作为前提，我应该说，我在软件开发上是一个非常保守的人。我认为 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 的使命，人们完全可能会需要一个快速的 inverted index(倒排索引)，具备全文搜索能力，可以实时写入数据，同时每核又能处理相当可观的查询量。这正是 Redis Labs 正在做的，它运用同样的 Redis 技术与思路，去做比 Redis 本来想做的更多的事情。不仅是在功能领域，还包括一致性模型等其他领域。我在某些事情上观点非常鲜明，我认为，例如 CRDTs(无冲突复制数据类型)虽然在某些用例中非常酷，但对 Redis 而言并非正确的选择，如果要保留同样的内存占用、性能和简洁性，即使代价是拥有较弱的一致性模型。因此 Redis Labs 与该领域的一位顶尖研究者一起实现了它（而且这是一个没有任何源码开放的专有产品）。我能看到这样的功能对某些操作会极其有用，但 Redis 本来就不是为了解决所有问题而存在的，而 Redis Labs 做到了。

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

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