最近，红帽因疑似闭源，备受非议。今天聊一聊这个事。到底红帽有没有闭源？
加上，红帽又被称为开源服务商业化“唯一的幸存者”，如果连他都闭源了，从开源到服务商业化，最终实现健康、稳定的盈利，这套模式有没有可能是一个被梦想吹大的泡沫？
就像现在国内吵到唾沫横飞的 SaaS 一样，迟迟无法盈利，只能拿国外最头部的案例，反复讲 Salesforce 的故事试图说服投资人，说服自己。
一
过去，红帽的江湖地位受益于开源。
在早年闭源商业软件时期，办公软件比如 Office 靠销售策略垄断了市场，在缺乏竞争的情况下，开发权被限制在 20% 的少数人手里，软件发展缓慢；随后，在自由软件、开源运动时期，开源软件兴起，其余 80% 使用者也有机会参与开发，表现出指数级增长，甚至超过硬件行业摩尔定律的创新周期，也带动了硬件发展。
不过，不用把开源视作一种无私奉献，每多一个使用者，就多一份技术说服力。增长本身就是一种目的。就像对用户免费但向广告商收费的平台一样，比如 Google、Facebook。
无论是个人还是公司，做开源，无非是想借社区竞争性创新的活力，借原本只是使用者的那 80% 人的创造力，帮助项目更好地成长，推动社区的发展。
红帽，就是受益者之一。这次闭源风波，要从“开源”定义讲起。
开源的定义，复杂又严谨，容易被误解，也容易被人从中牟利。
比如 Meta 的 Llama 2，因冠名“开源”而广受关注，其实并不属于真正意义的开源。
按 OSI 官网上的说法，“Meta 对 LLaMa 模型和代码的许可，对某些用户的商业用途施加了限制，并且还限制将模型和软件用于某些目的。其许可证不在开源类别中。”
开源者的动机有两种，一种是纯属 Hacker 行为的 Linux，另一种是大公司的商业行为，比如 Google 的 TensorFlow。Meta 从宣传上把自己伪装成后一种。但不管怎么说，从开源的官方严谨定义讲，没有用开源许可证的，不是开源。
二
那到底什么是开源？
一千个人有一千种说法，不过最官方的定义其实很简单：采用开源定义许可证的就是开源。而对一个开源项目来说，选择哪种开源许可证，就选择了什么样的商业模式。
开源许可证很多，OSI 官网上记录有 114 种，不过软件领域常用的基本可以分成两类，“copyleft” 属性、“Permissive free”属性，也对应着开源领域的两大阵营：FSF、OSI。
开源领域的第一大阵营，是自由软件基金会，FSF（Free Software Foundation） 。
秉持对自由的重视，不仅关注使用者的自由，更在意全过程包括使用、修改、分发的自由。“自由软件”这一理念，在基金会建立的许可证中彰显得淋漓尽致。
作为开源运动的发起者，FSF 建立了开源领域的第一个 “copyleft” 属性的许可证，GPL，规定软件的源码必须提供给使用者，不得闭源，且衍生子软件必须延用这条规定，也可以理解成有传染性。所以，全过程，没有人能靠卖软件本身获利。
过于理想化的自由许可，让无数开源项目缺少资金而夭折，比如 FSF 创建者自己的项目，反而阻碍了开源的发展。
为了在开源和商业间寻找平衡，1998 年第二大阵营组建，OSI（Open Source Initiative）。“开源运动”由此兴起。
他们希望找到一种方式，更有效率地把软件销售给客户，特别是企业界客户，从而更好地推动开源发展。建立了“Permissive free”属性的许可证，比如修改源码后可闭源的 Apache、MIT、BSD。
红帽的核心产品，就采用了那个近乎“理想化”的许可证 GPL——软件的源码必须提供给使用者。
三
坚持了GPL 30 年的红帽，生动诠释了什么叫生于忧患。
因为源码必须提供给使用者，红帽始终面临着其他克隆版开源竞品的威胁，核心产品 RHEL（Red Hat Enterprise Linux），前有 CentOS，后来被红帽收购，后有 RockyLinux 和 AlmaLinux。
这些年的成功，在产品市场占有率之外，就是靠在公开竞争中，培养出了强大的开发能力和开源社区的运作能力。
红帽开源运作能力之强，最佳案例就是让 Google 的 Kubernetes 产品，在容器之战中获胜，成为云基础设施的一部分。
Google 工程师 Merlin 曾说“没有开源，Google 不会有今天的成功。”但 Google 一开始并不做开源，第一代软件都是内部有使用需要才设计的。当时，为了塑造技术影响力，Google 的套路是在顶会期刊上发论文，比如 2004 年前后发布的大数据三驾马车：MapReduce、BigTable、GFS。只是，他们没想到，技术荣誉并不一定会带来等同的经济收益。
这三篇论文确实成为了分布式领域的经典，问题是 Google 并没有发布对应产品，一众公司基于论文开发的开源产品，比如 Hadoop、HBase，反倒趁势而起，抢先占据了绝大部分开发者，也顺势定义了业界的技术标准。只留 Google 黯然神伤。
当时有个故事，Google 做云的时候，云上放内部评价最牛最成熟的 MapReduce，但发现，所有开发者用的接口居然全部是 Hadoop 接口，导致 Google 不得不去捏着鼻子去兼容 Hadoop 接口。
后来，2013 年初 Docker 发布，但容器只能作为云平台最终部署应用的载体，会被上层的调度系统屏蔽。感受到压力的 Docker 开始往上做 Swarm，Mesos 也加入了竞争。
而大数据一战中失败的 Google，面对这一次的容器之战，迅速出击，在发完论文抢占技术影响力后，为进一步抢占开发者市场，也决定发布产品，也就是 Google 内部相对成熟的容器编排调度框架，Borg。Borg 一直在内部被视作最强大的“秘密武器”，只是设计之初，也是为了内部使用需要，跟很多系统搅在一起，没办法直接开源。于是，Google 用 Go 语言迅速重构了 Borg，2014 年，Kubernetes 发布。
但 Kubernetes，思想之超前，开发者难以理解，而且发布后由不善开源运作的 Google 工程师维护，一直不温不火。
眼看着已成容器事实标准的 Docker 一步步做强做大，Google 慌了，形势紧急，自己做不起来，不如找擅长开源圈子玩法的外援一块儿做，于是联合 RedHat 牵头成立了 CNCF 基金会，让有成熟的社区管理体系和足够工程能力的 RedHat 着手运作。
后面的故事我们都知道，基于最宽松的 Apache 许可证的 Kubernetes 项目，周边生态迅速发展，闭源的 Docker 最终遗憾落败。
四
但上个月，红帽官网宣布：不再公开 RHEL 源码，只向索要源码的客户私下提供。
很多人误认为是闭源了，严格上来说，按 GPL 许可证，软件的源码必须提供给使用者，RHEL 的使用者都是企业付费客户，红帽私下提供，是符合许可证要求的，钻了个空子。
其实，早在 2020 年，红帽就钻过这个空子，是这一次的“闭源”风波的前奏。
红帽的核心商业产品 RHEL，是基于开源 Linux 构建的，上游社区是 Fedora，很多创新性的功能都在其中试验，最终会构建稳定的 RHEL 版本开源发布，自己挣点服务费。
2014 年，红帽看到克隆版竞品 CentOS，用户基数很大，很多想用 RHEL 稳定性功能但又不想付费的用户，都投奔了 CentOS，自己的商业发展受阻，决意收购，把这个产品放在自己眼皮子底下看着。
但收购后，CentOS 团队仍保持独立性，CentOS Linux 甚至更方便拿到 RHEL 的源码了，大批开发者开开心心地跑去投诚。
于是，2020 年，红帽费尽心机去掉了 CentOS Linux 的竞争力——稳定性，让其变成了 CentOS Stream，作为 RHEL 的上游开发平台，也就是 RHEL 的预览版。RHEL，成为了唯一的稳定版本。
一众开发者认为红帽违背了开源原则，揭竿而起，继续在 RHEL 下游，发布克隆版，把免费+稳定性重新捡起来，试图替代原本的 CentOS，比如 Rocky Linux、AlmaLinux。
这一次，红帽干脆一不做二不休，宣布不在 git.centos.org 上发布 RHEL 的源代码了。虽然，上游 CentOS Stream 依然存在，其他人再想克隆，平添了不少难度。
红帽核心平台工程副总裁 Mike McGrath 写道：“这次变动，很大程度上是因为那些不想为 RHEL 投入时间、精力和资源的人，或者那些想要为了自己的利益而重新包装它的人……简单地重建代码，而不增加价值或以任何方式改变它，对世界各地的开源公司来说都是真正的威胁。”
他的意思，简单讲就是，你们这群简单克隆者完全没有创造价值，实在威胁开源。
五
可以理解他的想法。红帽，成于 GPL 许可证，之后也可能会败于 GPL。
因为 GPL，红帽拥有了大规模的开发者社区，但在必须提供源码的情况下，公司很难靠软件本身盈利，毕竟别人可以克隆你的代码在社区免费分发。
另寻其道的红帽，走的路子是靠订阅服务赚钱，比如技术客服支持、安全更新、认证、培训。
这里要说明一下，基于开源的商业化产品，和开源项目是两回事。
开源项目，一般采用基金会模式，比如 Kubernetes 就属于 CNCF 基金会，Hadoop 托管在了拥有无数知名开源项目的 Apache 基金会下，全球公有云上运行的负载有 90% 是 Linux 操作系统，其基金会就是最知名的 Linux 基金会。
这些开源基金会，都是非营利性的技术协会，也就是说，不从使用开源项目的开发者手里收钱，也没法拉投资。想持续健康运作，钱从哪来呢？只能靠捐款了。
只是不能靠个人捐款，得靠企业。像 Linux 基金会有两百多名企业会员，白金会员比如英特尔、微软、华为，每年捐 50 万美元，黄金会员每年捐 10 万美元，白银会员每年按公司的员工数量，捐五千至两万美元。
代码贡献之外，捐得越多，企业越能成为高级会员，在董事会选举的时候能推荐的人选越多，越有机会列席，便于之后参与基金会决策，影响技术走向。所以像华为、腾讯、阿里这些公司，都更有想法，有能力，也确实会把自己的员工运作为全球各知名开源基金会的列席成员。
所以，开源项目的模式是立足开源，借社区里广大开发者的能量，迅速催熟技术并建立起丰富的生态链，吸引企业（或主动或被迫）加入，收成员费。
这里简单聊两句，为啥企业会被迫加入？
因为开源会反噬自研。
阿里和腾讯就吃过不少亏。对大厂来说，业务规模之大，问题之复杂，决定了很多技术必然领先业界，总是最先发现和修复难以发现的 bug，在没有成熟的开源产品或开源刚刚起步时，面对紧迫的需求，会干脆自研，或基于开源做大量 Patch。但如果没有颠覆性思想，长期，内部自研无法和开源生态抗衡，靠单方面尴尬地兼容，会越来越痛苦，打不过，最终只能选择加入，拥抱开源。
而基于开源的商业化产品，既然是商业化，肯定不能像开源项目那样靠企业捐赠，不过本质仍然是向企业收钱。
基于开源的商业化产品，是在开源项目的基础上，面向有工程化需求（比如稳定、安全、可靠）的企业，推出自己的商业化产品，从中获利。
还是以 Linux 项目为例，Linux 最知名的商业产品，就是红帽的 Linux 企业发行版，RHEL，一方面成为了重量级的 Linux 代码贡献者，促进 Linux 项目发展；一方面也通过出售 Linux 的企业订阅服务赚钱。于是有了那句话：
幸运的是，开源行业有一个 Red Hat，不幸的是，开源行业只有一个 Red Hat。
六
红帽，是过去很多基于开源的商业化产品的模范，基于“客服”商业模式，虽然利润率低，但也为无数后来人所效仿。结果没有成功的，当时业界评价“开源行业只有一个”。
现在红帽也钻空子了，可以说，给“客服”的开源商业化模式添上了最后一根稻草。
那开源如何商业化？
Marten Mickos 在早年担任 MySQL 公司 CEO 的时候，曾经思考过这个问题，他说“如果要在开源软件上取得成功，你必须服务两类人：一类是愿意花费时间来省钱的人，另一类是愿意花钱来节约时间的人。”
二者，缺一不可。开源想成功，现实讲，经济投入比如开源软件的研发、推广方面，必须通过经济收入补齐。
所以，一些人之所以能够免费用，也就是“花时间来省钱”这一类人，一方面是因为这些大量的免费用户，降低了软件在研发和推广方面的投入，另一方面，也是因为“花钱来省时间”的这一类，用户为开源软件掏了钱。这一类，也通常是企业。
从这两种人的需求出发，Andrew Lampitt 在 2008 年创造了 open-core 的商业模式，为开源商业化探索了另一条路。
在开源的基础上，发布开源软件的“core”版本和商业版本，其中：
核心版本，服务于“花时间来省钱”这类人，最大化降低研发和推广成本；
同时，在周边开发一些专有和可用源的附加特性和功能，组成商业版本，面向愿意“花钱来省时间”的企业，实现商业化闭环。
至于 open-core 的模式中，哪些功能开源，哪些专有，就是另一复杂的问题了。Open Core Ventures 曾给出了一个很直白的方案：确保开源版本的价值，足以吸引开发者广泛采用。建议关注下载率和社区活跃程度，如果没有被广泛采用或被采用得不够快，就要在开源版本里包含更多商业功能。
只是，目前最受欢迎，也看起来最成功的 open-core 的商业模式，也在等待时间的验证。比如已经非常成功的 MongoDB，完成了从开源到商业化，年营收超十亿，增速 70%。但仍然是亏损的。
回顾红帽“闭源”事件，能理解红帽的口号是改变开源风气，也让自己在微薄的利润率上，尽量多挣点钱。
只是红帽如今的成功，也建立在过去十几年里，社区无数开发者的开源贡献之上。“当一个闭源的解决方案在市场上取得成功时，很快就会出现一个甚至是多个提供类似功能或服务的开源或者闭源的追随者。”这一点也不容忽视。
本文来自微信公众号：MacTalk（ID：MacTalkPro），作者：池建强