什么是开放核心？一个项目是开放核心，还是一个企业是开放核心？这值得商榷。与开源一样，有些人将其视为一种 开发模式，另一些人将其视为一种 商业模式。作为一名产品经理，我更倾向于在价值创造和价值捕获的背景下看待它。
（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 服务器的案例中，所有的粘合代码都是开源的，但人们很容易想象其他公司可能如何选择为该功能使用专有代码。
当开放核心与社区目标冲突时
开放核心的经典问题是，当上游社区想要实现专有附加组件中的一项功能时。采用开放核心模型的公司或产品有动机阻止这种情况在上游开源项目中发生，因为专有代码依赖于该项目。这为上游社区和客户都带来了一些严重问题。
潜在客户将受到激励参与社区，以实现被认为缺失的专有功能。当社区成员尝试实现这些功能时，当他们的拉取请求难以被接受或直接被拒绝时，他们会感到震惊或恼火。
我从未见过针对此问题的严肃解决方案。在这个视频中，如何做好开放核心：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 可以下载源代码并建立竞争的构建服务，但他们并没有这样做。事实上，由 Red Hat 大力赞助的上游 Podman 项目使用了 OpenSUSE 构建服务。尽管 SUSE 可以轻松地使这段代码成为专有的，但他们不需要这样做。建立、运行和维护竞争服务是一项非常繁重的工作，并且不一定为 Red Hat 客户提供很多价值。
我仍然认为开放核心是从完全专有代码迈出的正确一步（例如：GitLab 是开放核心，GitHub 是闭源），但我没有看到有令人信服的理由将其宣传为完全开源的更好替代方案。事实上，我认为 做好开放核心极其困难，并且可能无法真正用它创造差异化价值（另请参阅：社区主导的开源复兴 和 伪开源对业务不利）。
关于开放核心的这个论点是通过与数百名对开源充满热情的人合作和学习而形成的，包括工程师、产品经理、营销经理、销售人员以及该领域的一些最杰出的律师。为了在 Red Hat Enterprise Linux 和 OpenShift 中发布新功能和能力，例如启动 Red Hat Universal Base Image，我与 Red Hat 的许多不同团队密切合作。在我在这里的 10 多年中，我吸收了 25 年以上的机构知识。现在，我正试图在像 开源产品管理的精妙艺术 这样的公开作品中以及像这篇文章这样的后续文章中将此正式化。
这项工作为我最近晋升为 RHEL for Server 的高级首席产品经理做出了贡献，RHEL for Server 可以说是世界上最大的开源业务。即使有了这些经验，我仍然不断地倾听、学习和寻求真理。我很乐意在评论区或 Twitter (@fatherlinux) 上进一步讨论这个话题。
7 条评论