开源已是潮流，开放核心才是关键
作者：Scott McCarty
译者：宋彤彤
原文链接：https://opensource.com/article/21/11/open-core-vs-open-source
开放核心（Open Core）与开源有何不同？ 不同时候哪一个更胜一筹？
什么是开放核心？是开源项目的核心，还是开源业务的核心？这是值得商榷的。像开源一样，有些人将其视为开发模式，另一些人将其视为商业模式。作为一名产品经理，我更多地从价值创造和价值捕获的角度来看待它。
通过开源，一个工程团队可以获得的价值比付出更多。参与开源项目的工程师付出价值1美元的代码，但可以收获10美元、20美元、30美元甚至更多的价值。这种价值既以个人品牌来衡量，也以领导和影响对雇主有利的项目发展能力来衡量。
使用开放核心，至少一些代码是专有的。使用专有代码，公司雇用工程师、解决业务问题并对该软件收费。对于代码库的专有部分，没有基于社区的工程，因此社区成员无法参与获利的过程。对于专有代码，在工程上投资一美元即在代码中返回一美元。与开源不同，专有开发流程的回报无法超过工程团队贡献的价值。
在分析开放核心时，社区利益非常重要。这部分代码没有社区，所以没有社区参与，没有社区利益。如果没有社区，社区成员就不可能获得开源的标准利益（个人品牌、影响力、使用权、学习等）。
开放核心没有创造差异化价值，因此在区分开源产品与上游供应商的18种方式中，我将其描述为一种捕获价值的方法。社区驱动的开源是关于价值创造，而不是价值捕获。这是开源和开放核心之间的根本张力。
开放式内核与粘合代码（Glue code）
首先，让我们来看看通常人们认为的开源是什么。正如维基百科上所描述的那样，“开放核心模式主要涉及提供软件产品的‘核心’或功能受限版本作为免费和开源软件，同时提供‘商业’版本或附加组件作为专有软件。”下图以图形方式显示了此模式。
这种模式的一个例子是SugarCRM，它有核心、开源软件以及一堆插件，其中许多是专有的。另一个例子是微软对.Net中的热重载功能的原始计划（此后已被撤销）。
另一个相关的模式被称之为粘合代码的模式。粘合代码，又称“胶水代码”，不直接为客户提供业务价值。相反，它将一堆项目组合在一起。请注意，在此示例中，我将演示三个开源项目，一个数据驱动的API服务以及一些将它们结合在一起的粘合代码。粘合代码可以是开源的，也可以是专有的，但在人们谈论开放核心时通常不会想到。
开源粘合代码的一个例子是Red Hat Satellite Server。它由多个上游开源项目组成，如Foreman，Candlepin，Pulp和Katello，以及与数据服务的连接来进行更新（以及与Red Hat Insights等工具的连接）。在卫星服务器的情况下，所有的粘合代码都是开源的，但很容易想象其他公司如何选择使用专有代码来实现此功能。
当开放核心与社区目标相悖时
开放核心的经典问题是当上游社区想要实现专有附加组件的一个功能时，采用开放核心模式的公司或产品会理所应当地阻止这种情况在专有代码所依赖的开源项目中发生。这给上游社区和客户带来了一些严重的问题。
潜在客户会被激励来参与社区，以实现被认为缺失的专有功能。尝试实现这些功能的社区成员会感到震惊或恼火，因为他们的拉取请求很难被完全接受或拒绝。
我从未见过针对此问题的严肃解决方案。在《如何做好开放核心：6个具体建议》中，来自英国的作家和软件工程师Jono Bacon建议与社区成员保持联系。他建议告诉社区成员，与专有产品功能相悖的拉取请求会被拒绝。虽然这比不提前要好，但它不是一个可扩展的解决方案。具有专有功能的上游项目和下游产品都在不断变化。通常，社区贡献者都不会关注下游产品，也不知道下游实现了哪些功能，或者更糟的是在路线图上下游产品作为专有功能实现。上游社区也很少关心下游产品解决的业务问题，当他们的拉取请求被拒绝时很容易混淆。
虽然社区愿意接受禁区（例如：GitLab Features by Paid Tier），但这很有可能是单一供应商为开源项目做的努力（例如：GitLab的贡献主要是GitLab员工）。竞争者参与的可能性太小，这将从根本上限制社区的价值创造。开放核心业务还可以通过精神领袖、技术采用和客户忠诚度来获取价值，但可以说，他们永远不会真正创造比他们投资更多的代码价值。
除了这些问题之外，如果一个上游项目真正坚持开放治理，那么开放核心业务实际上无法阻止专有功能的实现。项目内（在单个项目中）专有代码不起作用。
开放核心何时可能工作
粘合代码是开放核心或专有代码可能工作的地方。我不是在提倡开放核心，我经常认为它效率不高，但我想认真对待我的分析。开源项目之间确实存在自然的界限。回到我开源的供应链论文，喷油器就是喷油器，它并不是交流发电机。这些自然分界点确实为区分下游产品和上游项目提供了良好的区域。
专有粘合代码的一个经典实例是2000年发布的原始Red Hat网络（RHN）。RHN本质上是一个SaaS产品，为Red Hat Linux机器提供更新，这是在Red Hat Enterprise Linux出现之前。就上下文而言，当RHN发布时，开放核心这个术语甚至还没有出现（在2008年出现），巧合的是同一年上游太空行走项目发布。那时候，每个人都还在学习如何做好开源的核心竞争力。
回想起来，我认为RHN存在于上游Linux发行版和付费产品之间自然分界点的交界处这并非巧合。当然这符合将产品与上游供应商区分开来的思维模式。可能很容易得出结论 ——“看！？！？世界上最大的开源公司通过专有代码脱颖而出！开放的核心是Red Hat生存和繁荣的原因。”但我会小心不要混淆相关性与因果关系。Red Hat最终将RHN开源为Spacewalk，并且从未因此对收入造成过影响。
换个角度思考，人们还可以提出一个论点，即云提供商今天依旧遵循这种模式。业内众所周知，大多数大型云提供商都带有自己的Linux内核分支，这些分支具有专有的扩展，使Linux在其环境中可用。这些功能不会直接解决客户的业务问题，而是解决云提供商的问题。它们本质上是粘合代码。
云提供商没有在上游更改这些的动机略有不同。对他们来说，与向上游提供这些特性相比，携带fork通常更便宜/或更容易（虽然不容易），特别是当Linux内核社区通常不想要这些更改时。云提供商经常从一堆馊主意中择优。
开放核心粘合代码可能被称为项目间（多个项目之间）专有代码。这也许有效，但可以说这种代码已经很难实现，并且不需要专有许可证的感知“保护”。换句话说，开源贡献者不一定有动力去处理和维护粘合代码。这是供应商可以区分的自然场所。通常，粘合代码很复杂，并且需要在上游项目的特定版本之间进行特定集成，以满足特定的生命周期要求。所有这些特定要求使粘合代码成为产品与上游项目区分开来的好地方，而无需专有许可证。企业集成的速度（速度和方向）与多个上游项目之间协作所需的速度大不相同。上游社区需求和下游客户需求之间的这种速度不匹配是差异化的完美场所，无需开放核心。
结论
开放核心能工作吗？它比开源更好吗？每个人都应该使用它吗？当然，开放核心可以工作，但只能在非常特定的情况下使用非常特定类型的软件（例如粘合代码）。鲜为人知的是，有人认为开放核心实际上更适合创造价值。因此，我不建议大多数企业开放核心。此外，我还认为它提供的感知保护实际上是不必要的。
通常，供应商会找到相互竞争的自然场所。例如，SUSE运行OpenSUSE构建服务，该服务基于完全开源的代码。尽管Red Hat可以下载源代码并设置竞争性构建服务，但他们还没有。事实上，由Red Hat大力赞助的上游Podman项目使用了OpenSUSE构建服务。虽然SUSE可以轻松地将此代码设为专有代码，但它们不需要这样做。设置、运行和维护竞争服务需要大量工作，而且并不一定能为Red Hat客户提供很多价值。
我依旧认为开放核心是完全专有代码向正确方向迈出的一步（例如：GitLab是开放核心，GitHub是闭源代码），但没有能让我信服的理由来推广它成为完全开源的替代品。事实上，我认为做好开放核心是非常困难的，并且很可能不能真正创造差异化的价值。
参考链接：
为什么Red Hat投资CRI-O和Podman：Why Red Hat is investing in CRI-O and Podman
《如何做好开放核心：6个具体建议》：How To Do Open Core Well: 6 Concrete Recommendations | Open Source - YouTube
开源产品管理的微妙艺术：http://crunchtools.com/the-delicate-art-of-product-management
将开源软件产品与上游项目区分开来的18种方法：18 ways to differentiate open source products from upstream suppliers | Opensource.com
社区主导的开源：The community-led renaissance of open source | Opensource.com
仿源的复兴对业务不利：Fauxpen source is bad for business | Opensource.com