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