什么是开放核心？ 是一个项目是开放核心，还是一个企业是开放核心？ 这是有争议的。 像开源一样，有些人将其视为一种 开发模式，另一些人将其视为一种 商业模式。 作为一名产品经理，我更多地从价值创造和价值获取的角度来看待它。
(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 内核社区需要时。 云提供商通常是从一堆糟糕的想法中选择最好的坏主意。
开放核心（Open Core）粘合代码可能被称为项目间的（多个项目之间）专有代码。这或许可行，但可以说，这类代码的实现本身就很难，并不需要专有许可所带来的“保护”。换句话说，开源贡献者不一定有动力去开发和维护粘合代码。这自然成为供应商可以进行差异化的地方。通常，粘合代码很复杂，需要上游项目的特定版本之间进行特定的集成，以满足特定的生命周期要求。所有这些特定要求使得粘合代码成为产品与上游项目区分开来的绝佳之处，而无需专有许可。企业集成的速度（速度和方向）与多个上游项目之间协作所需的速度截然不同。上游社区需求和下游客户需求之间的这种速度不匹配，是无需开放核心即可实现差异化的理想场所。
结论
开放核心模式能行得通吗？它比开源更好吗？每个人都应该使用它吗？ 似乎很明显，开放核心可以工作，但仅在非常特定的情况下，且针对非常特定类型的软件（例如，粘合代码）。 似乎不太明显的是，有任何论点可以证明开放核心实际上更适合创造价值。 因此，我不建议大多数企业使用开放核心。 此外，我认为它提供的感知保护实际上是不必要的。
通常，供应商会找到彼此竞争的自然领域。 例如，SUSE 运行 OpenSUSE Build Service，它基于完全开源的代码。 即使 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 的高级首席产品经理，可以说是世界上最大的开源业务。 即使拥有了这些经验，我仍然在不断倾听、学习和寻求真相。 我很乐意在评论中或在 Twitter (@fatherlinux) 上进一步讨论这个主题。
7 条评论