什么是开放核心？一个项目是开放核心，还是一个企业是开放核心？这是有争议的。与开源一样，有些人将其视为一种开发模式，另一些人则将其视为一种商业模式。作为一名产品经理，我更多地从价值创造和价值捕获的角度来看待它。
(Scott McCarty, CC BY-SA 4.0)
通过开源，一个工程团队可以捕获比其贡献更多的价值。一名参与开源项目的工程师可以贡献价值 1 美元的代码，但可以获得价值 10 美元、20 美元、30 美元或更多的回报。这种价值体现在个人品牌以及领导和影响项目朝着对其雇主有利的方向发展的能力上。
通过开放核心，至少一部分代码是专有的。对于专有代码，公司雇用工程师、解决业务问题并为该软件收费。对于代码库的专有部分，没有基于社区的工程，因此没有社区成员可以通过参与获利的过程。对于专有代码，投入工程的一美元将在代码中返回一美元。与开源不同，专有开发流程无法返回比工程团队贡献更多的价值（另请参见：Red Hat 为什么投资 CRI-O 和 Podman）。
在分析开放核心时，缺乏社区利润非常重要。代码的这一部分没有社区，因此没有社区参与，没有社区利润。如果没有社区，社区成员就没有机会获得开源的标准好处（个人品牌、影响力、使用权、学习等）。
开放核心没有创造差异化价值，因此在将开源产品与上游供应商区分开来的 18 种方法中，我将其描述为一种捕获价值的方法。社区驱动的开源是关于价值创造，而不是价值捕获。这是开源和开放核心之间的根本矛盾。
开放核心与粘合代码
首先，让我们看看人们通常认为的开源。正如维基百科所描述的，“开放核心模型主要涉及提供软件产品的“核心”或功能受限版本作为免费和开源软件，同时提供“商业”版本或附加组件作为专有软件。”下图以图形方式显示了此模型。
此模型的一个例子是 SugarCRM，它有一个核心的开源软件以及一堆插件，其中许多是专有的。另一个例子是微软最初为 .Net 中的热重载功能制定的计划（此后已被撤销）。
另一个相关的模型是我将称为粘合代码。粘合代码不直接为客户提供商业价值。相反，它将一堆项目粘合在一起。请注意，在此示例中，我演示了三个开源项目、一个数据驱动的API 服务以及一些将它们粘合在一起的粘合代码。粘合代码可以是开源的或专有的，但这并不是人们通常在谈论开放核心时所想到的。
开源粘合代码的一个例子是 Red Hat Satellite Server。它由多个上游开源项目组成，例如 Foreman、Candlepin、Pulp 和 Katello，以及与更新的数据服务的连接（以及与 Red Hat Insights 等工具的连接）。在 Satellite Server 的情况下，所有的粘合代码都是开源的，但是人们很容易想象其他公司如何选择使用专有代码来实现此功能。
当开放核心与社区目标冲突时
开放核心的经典问题是，当上游社区想要实现某个专有附加组件中的功能时。采用开放核心模型的公司或产品有动机阻止这种情况发生在专有代码所依赖的开源项目中。这给上游社区和客户都带来了一些严重的问题。
潜在客户将被激励参与到社区中，以实现他们认为缺失的专有功能。当尝试实现这些功能的社区成员发现他们的拉取请求难以被接受或直接被拒绝时，会感到震惊或恼火。
我从未见过解决此问题的有效方案。在此视频中，如何做好开放核心：6 条具体建议，Jono Bacon 建议与社区成员坦诚相待。他建议告诉他们，与专有产品功能竞争的拉取请求将被拒绝。虽然这比不坦诚更好，但这不是一个可扩展的解决方案。具有专有功能的上游项目和下游产品都在不断变化。通常，社区贡献者甚至没有关注下游产品，并且不知道哪些功能在下游实现，或者更糟糕的是，在路线图中实现为专有功能。上游社区很少对下游产品解决的业务问题投入感情，并且当他们的拉取请求被拒绝时很容易感到困惑。
即使社区愿意接受禁区（例如：按付费层级划分的 GitLab 功能），这也会使开源项目很有可能成为单一供应商的努力（例如：GitLab 贡献主要来自 GitLab 员工）。竞争对手极不可能参与，这将固有地限制社区的价值创造。开放核心业务仍然可以通过思想领导力、技术采用和客户忠诚度来捕获价值，但可以说他们永远不会真正创造比他们投资更多的代码价值。
除了这些问题之外，如果上游项目真正坚持开放治理，那么开放核心业务实际上无法阻止专有功能的实现。项目内（在单个项目内）的专有代码根本不起作用。
什么时候开放核心可能有效
粘合代码是开放核心或专有代码可能工作的地方。我不是在倡导开放核心，我经常认为它效率低下，但我想诚实地进行分析。开源项目之间确实存在自然的界限。回到我关于开源作为供应链的论点（另请参见：开源的产品管理的艺术），一个燃油喷射器就是一个燃油喷射器；它不是一个交流发电机。这些自然的分界点确实为下游产品与上游项目的差异化创造了良好的区域（另请参见：将开源软件产品与上游项目区分开来的 18 种方法）。
专有粘合代码的一个经典例子是最初的Red Hat Network (RHN)，于 2000 年发布。RHN 本质上是一个 SaaS 产品，为 Red Hat Linux 机器提供更新，这甚至是在 Red Hat Enterprise Linux 出现之前。在发布 RHN 时，“开放核心”一词甚至尚未发明（2008 年创造），巧合的是，同年发布了上游 Spacewalk 项目。那时，每个人仍在学习如何做好开源的核心竞争力。
回想起来，我认为 RHN 存在于上游 Linux 发行版和付费产品之间自然分界点的中心，这并非巧合。这自然符合区分产品与上游供应商的思维模型。人们可能会想得出结论——“看！世界上最大的开源公司通过专有代码实现了差异化！开放核心是 Red Hat 能够生存和繁荣的原因”——但我会小心不要将相关性与因果关系混淆。Red Hat 最终将 RHN 开源为 Spacewalk，并且从未遭受收入损失。
稍微转变一下，人们还可以争辩说，云提供商今天经常遵循这种模式。行业内众所周知的是，大多数大型云提供商都拥有自己的 Linux 内核分支。这些分支具有专有扩展，使 Linux 可以在他们的环境中使用。这些功能不会直接解决客户的业务问题，而是解决云提供商的问题。它们本质上是粘合代码。
云提供商不将这些更改提交到上游的动机略有不同。对于他们来说，维护一个分支通常比将这些功能贡献给上游更便宜和/或更容易（虽然并不容易），尤其是在 Linux 内核社区经常不需要这些更改时。云提供商通常是在一堆糟糕的主意中选择最佳的糟糕主意。
开放核心的粘合代码可能被称为跨项目（多个项目之间）的专有代码。 这也许可行，但可以说，这类代码本身就难以实现，不需要专有许可的“保护”。换句话说，开源贡献者不一定有动力去开发和维护粘合代码。 这自然成为供应商可以差异化的地方。 通常，粘合代码很复杂，需要上游项目的特定版本之间的特定集成，以满足特定的生命周期要求。 所有这些特定要求使粘合代码成为产品与上游项目区分开来的绝佳之处，而无需专有许可。 企业集成的速度（速度和方向）与多个上游项目之间协作所需的速度截然不同。 上游社区需求和下游客户需求之间的这种速度不匹配是差异化的完美之处，而无需开放核心。
结论
开放核心可行吗？ 它比开源更好吗？ 每个人都应该使用它吗？ 看起来很明显，开放核心可行，但仅在非常特定的情况下，使用非常特定类型的软件（例如，粘合代码）。 似乎不太明显的是，有任何论点表明开放核心实际上更适合创造价值。 因此，我不建议大多数企业使用开放核心。 此外，我认为它提供的感知保护实际上是不必要的。
通常，供应商会找到彼此竞争的自然领域。 例如，SUSE 运行着 OpenSUSE 构建服务，该服务基于完全开源的代码。 即使 Red Hat 可以下载源代码并建立一个竞争性的构建服务，他们也没有这样做。 事实上，上游的 Podman 项目（由 Red Hat 大力赞助）使用了 OpenSUSE 构建服务。 虽然 SUSE 可以很容易地使这段代码成为专有代码，但他们不需要这样做。 建立、运行和维护一个竞争性的服务需要大量的工作，并且不一定能为 Red Hat 客户提供很多价值。
我仍然认为开放核心是从完全专有代码朝着正确方向迈出的一步（例如：GitLab 是开放核心，GitHub 是闭源），但我没有看到任何令人信服的理由来推广它作为完全开源的更好替代方案。 事实上，我认为要做好开放核心极其困难，并且几乎不可能真正用它来创造差异化的价值（另见：社区主导的开源复兴和 伪开源对企业不利）。
这个关于开放核心的论题是通过与数百位热情的开源人士合作和学习而形成的，其中包括工程师、产品经理、市场经理、销售人员以及该领域一些最重要的律师。 为了在 Red Hat Enterprise Linux 和 OpenShift 中发布新的特性和功能，比如启动 Red Hat Universal Base Image，我与 Red Hat 的许多不同团队密切合作。 在我在这里的 10 多年里，我吸收了 25 年以上的机构知识。 现在，我正尝试在公共作品中正式化这些，例如开源产品管理的精妙艺术和类似的后续文章。
这项工作促成了我最近晋升为 RHEL for Server 的高级首席产品经理，这可以说是世界上最大的开源业务。 即使有了这些经验，我仍然不断倾听、学习和寻求真理。 我很乐意在评论中或在 Twitter (@fatherlinux) 上进一步讨论这个话题。
7 条评论