开源怎么赚钱：服务、托管云、开放核心与许可证博弈
最后更新：2026-10-03
本文是产业观察的一篇，在 开源商业模式总览 搭好框架之后，专门回答一个更扎手的问题：开源怎么赚钱，钱到底从哪一条管道流进来，以及为什么 MongoDB、Elastic、Redis、HashiCorp 这些明星项目会一个接一个地改许可证。如果你还关心云厂商在整个链条里的角色，可以配合 AWS 与阿里云的云计算史 和 订阅制软件经济学 一起读。本文的观点是：开源商业化从来不是"能不能赚钱"的问题，而是"社区漏斗够不够大、护城河是代码还是服务"的问题。
本文要回答的问题
- 开源软件本身免费，Red Hat、MongoDB、HashiCorp 这些公司靠什么一年收几亿甚至几十亿美元？
- 支持服务、双重授权、开放核心、托管云四条变现路径，各自的毛利和天花板差在哪？
- 为什么云厂商把开源项目"打包成服务"卖钱，会被社区骂作"吸血"？这场论战双方的道理各是什么？
- GPL、AGPL、SSPL、BSL 这几张许可证，在"防云厂商转售"这件事上强度差多少？改许可证的代价是什么？
- Redis 改许可证之后社区分叉出 Valkey、Terraform 改 BSL 之后分叉出 OpenTofu，这对其他开源公司意味着什么？
一、四条变现路径：从"卖人天"到"卖订阅"
先说清楚一个常识：开源软件本身不等于生意，生意是围绕软件长出来的付费理由。回头看过去三十年的开源公司，变现路径基本收敛到四条，按毛利从低到高排列。
第一条，支持与咨询（Red Hat 模式）。 软件免费，但企业为"出事了有人兜底"付费：7×24 支持热线、补丁回溯、认证硬件兼容矩阵、长期维护的旧版本。Red Hat 靠 RHEL 订阅做到年收入三十多亿美元、2019 年被 IBM 以 340 亿美元收购，是这条路的巅峰。但它的本质是"卖人头"——收入随支持工程师数量线性增长，毛利低，扩张慢，一家纯支持公司很难长成巨头。
第二条，双重授权。 同一个代码库，社区版用 GPL/AGPL，商业客户不想被 copyleft 传染就买商业许可证。MySQL 当年靠这个模式活得很好：想闭源嵌入 MySQL 的厂商必须向 MySQL AB 付费。这条路的前提是公司对代码有完全版权（不接受外部 CLA 之外的贡献），天花板取决于"有多少客户必须闭源使用你"。
第三条，开放核心（open core）。 核心引擎开源，企业级功能——审计日志、SSO、细粒度权限、集群管理界面——放进付费企业版。GitLab、Confluent、Elastic（早期）都是典型。这条路的关键是切分线画在哪：画得太靠里，社区版残废没人用；画得太靠外，没人有付费理由。
第四条，官方托管云（Managed Cloud / SaaS）。 把"部署、备份、升级、扩缩容、监控"全部打包成订阅服务。这是过去十年增长最快、毛利最高的一条路：MongoDB Atlas 的收入占比从 2019 年的三成多一路涨到总收入的七成左右，Databricks、Confluent Cloud、Elastic Cloud 都靠托管服务撑起估值。托管云把开源公司从"卖保险"变成了"卖水电"，经常性收入、续费率、可预测性全都上了一个台阶。
| 变现路径 | 付费理由 | 毛利 | 规模天花板 | 代表 |
|---|---|---|---|---|
| 支持/咨询 | 出事有人兜底 | 低（人力线性） | 低-中 | Red Hat |
| 双重授权 | 闭源使用/免 copyleft | 高 | 中 | MySQL |
| 开放核心 | 企业级功能 | 高 | 中-高 | GitLab、Confluent |
| 托管云 | 免运维的订阅服务 | 高（经常性收入） | 高 | MongoDB Atlas、Elastic Cloud |
这四条路不是互斥的，成熟的开源公司通常混着用。但战略重心在哪一条，决定了公司的估值逻辑：服务型按利润估值，订阅型按经常性收入倍数估值，差距可以是十倍。
二、转化漏斗：社区规模是所有商业化的源头
不管走哪条路，开源公司的收入公式都长得一样：社区采用 → 生产环境依赖 → 付费保障/企业功能/托管服务。漏斗顶端的社区规模决定了一切，这也是为什么开源公司早期疯狂投入开发者体验、文档和会议，却对收入不急。
这张图解释了开源商业化里一个反直觉的事实：转化率低到百分之一以下也能撑起一家上市公司，因为漏斗顶端是百万级的免费用户。反过来说，任何伤害漏斗顶端的动作——比如把许可证改得太激进、把核心功能藏进企业版——都是在亲手掐死自己的未来收入。这就是后面许可证博弈里所有纠结的根源。
投资人看开源公司时，看的也不是当期收入，而是三个指标：社区活跃度（漏斗顶端是否在涨）、生产环境渗透率（多少关键系统离不开你）、以及付费留存率（续费率）。MongoDB 上市前后 Atlas 的高速增长、Confluent 按 Kafka 使用量计费的云收入，都是这套逻辑的兑现。
三、云厂商"吸血"论战：到底是谁占了谁的便宜
2018 年前后，开源界爆发了一场持续数年的论战，导火索是公有云厂商的一个商业模式：把别人的开源项目包装成托管服务卖钱，而原项目的公司一分都拿不到。
最出名的案例是 Elastic 与 AWS 之争。Elasticsearch 是 Elastic 公司的核心产品，AWS 直接推出 Amazon Elasticsearch Service，用 Elastic 的品牌引流、用自己的渠道收钱。Elastic 的 CEO Shay Banon 公开指责 AWS"滥用开源、搭便车"，2021 年 Elastic 一怒之下把 Elasticsearch 和 Kibana 从 Apache 2.0 改为 SSPL 加 Elastic License 双授权，禁止云厂商直接拿去做托管服务。AWS 的回应是把最后一个 Apache 版本分叉出来，起名 OpenSearch，自己拉了一票厂商继续维护。几年后，2024 年 Elastic 又把 AGPLv3 加回了许可选项，算是向社区递出橄榄枝——这场仗谁也没赢干净。
MongoDB 更早动手。2018 年它推出 SSPL（Server Side Public License，服务器端公共许可证），核心条款是：如果你把 MongoDB 作为服务对外提供，就必须把你整个服务栈的源代码也开源。这条款明显是冲着云厂商去的——没有哪个云厂商愿意开源自己的全套管理平台。紧接着 Redis 在 2018 年对部分模块改用 Commons Clause，2024 年 3 月更进一步，把 Redis 本体从 BSD 改为 RSALv2 加 SSPLv1 双授权。结果一个月后，Linux 基金会联合 AWS、Google、Oracle 等厂商把最后一个 BSD 版本分叉成 Valkey，社区核心维护者大面积倒向分叉，Redis Ltd. 陷入被动——2025 年 Redis 又把 AGPLv3 加回许可选项，试图挽回社区。HashiCorp 2023 年 8 月把 Terraform 等产品从 MPL 改为 BSL（Business Source License），同样一个月内社区分叉出 OpenTofu，并被 Linux 基金会收编。
"吸血"这个词准确吗？把双方的理摆出来：
| 立场 | 论据 | 软肋 |
|---|---|---|
| 开源公司（被"吸血"方） | 研发成本全是自己扛，云厂商零研发投入却拿走最大利润；还用原品牌引流造成用户混淆 | 当初选宽松许可证就是为了让所有人免费用，云厂商的做法合规；云分发也帮项目扩大了采用 |
| 云厂商（"合规使用"方） | Apache 2.0 / MIT 明确允许商业转售；托管服务投入的运维、安全、集成是真实成本；分叉后也在回馈上游（OpenSearch、Valkey 都有贡献） | 几乎不雇原项目的核心维护者，品牌借用有搭便车之嫌；上游公司一旦倒闭，生态整体受损 |
这场论战没有标准答案，但它彻底改变了开源公司的许可证策略——宽松许可证"先圈地再商业化"的时代结束了。
四、许可证军备竞赛：GPL、AGPL、SSPL、BSL 强度对比
要理解各家改证的力度差异，得先看这几张许可证在"防转售"这件事上的递进关系。
GPL 是经典的 copyleft：分发改生作品必须开源，但"通过网络提供服务"不算分发——这就是著名的 ASP 漏洞，云厂商在 GPL 软件上套个服务壳就能绕开。AGPL 补上了这个洞：只要用户通过网络与你交互，你就有义务提供源码。但 AGPL 管的是"这个软件本身"，云厂商把 AGPL 软件改一改、周边管理面自己写，还是能合规运营。SSPL 再进一步：把"提供服务的整个栈"都纳入开源义务，强到 OSI（开放源代码促进会）拒绝承认它是开源许可证。BSL 干脆不装开源：代码公开可读，但约定若干年内（通常 3-4 年）不得用于竞争性商业用途，到期后自动转为开源许可证——它从一开始就是"延时开源"，不是开源。
改证的代价是实打实的。OSI 不认可 SSPL 意味着改证项目会被踢出 Debian、Fedora 等主流发行版的官方仓库，企业合规部门会直接拉黑，社区贡献者会流失。MongoDB 敢改 SSPL，是因为它的托管云 Atlas 已经起量、对发行版渠道依赖小；Redis 改证后社区立刻分叉出 Valkey 并带走核心维护者，说明当项目的社区力量大于公司力量时，改证就是把王位让给分叉。HashiCorp 改 BSL 后 OpenTofu 获得 Linux 基金会背书，也是同一逻辑。
所以对开源公司来说，许可证是把双刃剑：不改，云厂商合法收割；改狠了，社区分叉、发行版除名、品牌受损。真正过得好的公司，靠的从来不是许可证本身，而是"云厂商分叉了也追不上"的执行速度——Elastic 和 MongoDB 在改证后都把全部火力压在自家托管云的功能迭代上，让用户觉得官方服务比分叉和云厂商的克隆版好用得多。
五、维护可持续性：商业化冲突之外的另一本账
聊完巨头博弈，别忘了开源世界还有大量"没有公司"的项目。log4j 漏洞事件让全世界发现：一个支撑半个互联网的日志库，背后是几个业余维护的志愿者。志愿者倦怠（burnout）、维护者老龄化、安全责任无偿化，是比"云厂商吸血"更根本的可持续性问题。
目前社区的解法大致三类：基金会托管（CNCF、Apache、Linux 基金会提供中立治理和企业赞助通道，Kubernetes、Valkey、OpenTofu 都走这条路）；企业雇佣维护者（Google、微软、红帽雇佣大量上游开发者，把维护当基础设施投入）；直接资助平台（GitHub Sponsors、Open Collective、Tidelift 按依赖关系向维护者付费）。没有一种是万灵药，但趋势很清楚：关键开源基础设施的维护正在从"爱好"变成"有人付钱的工作"——这本身就是开源怎么赚钱这个问题在个体层面的答案。
六、给从业者的决策清单
如果你自己手里有个开源项目，或者你在评估一家开源公司，可以把全篇浓缩成几个问题：
- 这个项目的护城河是代码还是服务？代码能被分叉，服务的运维深度和迭代速度不能。
- 漏斗顶端还在涨吗？GitHub 活跃度、下载量、生产环境案例，比当期收入更能预测未来。
- 许可证策略和分发渠道匹配吗？重度依赖发行版仓库的项目，改 SSPL 等于自杀。
- 如果云厂商明天推出同款托管服务，公司的应对方案是什么？没有答案的项目商业化风险极高。
- 维护者的饭谁管？无论公司还是个人项目，没有可持续维护机制的开源，迟早是供应链上的雷。
这一篇在知识体系里的位置
本文是产业观察线中"开源经济"专题的第二篇：上承 开源商业模式总览 的框架，把四条变现路径和许可证博弈展开到案例级深度；横向关联 AWS 与阿里云的云计算史（云厂商为什么有能力收割开源）与 订阅制软件经济学（托管云收入的估值逻辑）；往下则连接软件供应链安全话题——log4j 事件这类维护危机，正是 软件供应链攻击 一篇讨论的现实背景。
总结
开源怎么赚钱？答案是：软件免费、围绕软件长出的"付费理由"收费——支持服务卖兜底、开放核心卖企业功能、托管云卖免运维，而 MongoDB SSPL、Elastic 与 AWS 之争、Redis 与 Valkey、Terraform 与 OpenTofu 这一连串许可证战争说明：在公有云时代，许可证只是防守武器，真正的护城河是"分叉了也追不上"的执行速度和持续扩大的社区漏斗。