title: 当开源不再等于免费：2026，云厂商开始为“托管权”单独开价
date: 2026-10-04 10:00:00
categories:

• 1

tags:

• 云计算
• 开源
• 开发者
• 商业

过去十年，开源几乎被默认成一种定价策略：软件本身不要钱，钱从支持、托管、企业功能和品牌溢价里来。这个故事在 2024 年之后开始裂开。不是因为开源突然“不道德”，而是因为云厂商把同一套二进制做成了更便宜、更省事的托管服务，原厂却拿不到对应的账单。

2026 年，这条裂缝已经从个别数据库公司的许可证变更，变成云和开源之间一套可复用的商业结构。核心不再是“代码能不能看”，而是“谁有权把它当成产品卖”。

许可证战争只是第一幕

Redis、Elasticsearch、HashiCorp Terraform、MongoDB，这些名字在开发者圈子里已经被讲滥了。它们的共同动作很像：把宽松许可证收紧，换成 SSPL、BSL、AGPL，或者自有的“源代码可用、云厂商受限”条款。对外说法也高度一致——防止超大规模云把社区劳动直接产品化。

支持方认为这是生存权。一个项目如果大部分生产流量跑在别人的托管面板上，而原厂只剩下 GitHub star 和工单，开源就不再是飞轮，而是补贴。反对方则指出，许可证变更伤害的往往不是云巨头，而是中小集成商、发行版维护者和“只想自己部署”的团队。云巨头有律师，能 fork、能重写兼容层、能把品牌换成另一个名字继续卖。中小团队没有。

两边都对了一半。许可证能挡住“原样转售”，挡不住“兼容实现”。Valkey 从 Redis 分叉、OpenTofu 从 Terraform 分叉，说明社区有能力在协议收紧之后重建一条宽松分支。但它也说明：分叉成功依赖的是已经成熟的用户基数和云厂商的站台，不是每一家初创公司都复制得了。

2026 年真正在卖的，是托管权

更值得看的变化，不是又一家公司改了 LICENSE 文件，而是云账单的结构变了。

过去，托管开源的差价主要来自三件事：机器、磁盘、值班。客户自己也能算：一台虚机加对象存储，再雇半个 SRE，往往比托管版便宜。云厂商靠的是“你懒得自己弄”。

现在多出来的一层，是合规、身份、网络和数据驻留被捆进同一张发票。客户买的不再是“跑起来的 Postgres”或“跑起来的 Kafka”，而是：

• 这个服务能不能进现有的 IAM，而不是再维护一套账号
• 审计日志能不能直接进公司已有的 SIEM
• 跨境时数据能不能停在指定区域，密钥能不能留在客户自己的 KMS
• 出问题时，是云的工单号，还是开源项目的 GitHub issue

这些能力有的确实是工程，有的只是把已有控制面重新标价。难分的地方在于：一旦企业采购把“必须有合规报告、必须有区域承诺、必须有统一账单”写进招标，自建和社区发行版就在流程上输了，哪怕技术上完全够用。托管权因此变成一种可单独计价的商品。代码仍然开源，运行它的“被允许的方式”开始收费。

这和传统的开源商业模式不完全一样。旧模式是“核心免费，企业版加功能”。新模式更接近“核心仍然免费，但企业能采购的那条路径只经过云市场”。功能差异被缩小，采购路径的差异被放大。

云厂商不是一边倒的赢家

容易把这个故事讲成“云巨头收割开源”。2026 年的账单没有这么干净。

第一，分叉会反噬。云厂商站台 Valkey、OpenTofu 这类项目时，短期拿到了不被许可证卡住的发行版；长期则要自己养兼容性、自己背安全响应。托管一个没人认领的分叉，和托管一个有商业公司兜底的上游，成本不是同一个数量级。有的云已经在悄悄把“社区版”和“合作版”分成两个 SKU，前者便宜、后者带原厂支持。这等于承认：纯搬运并不总是更赚。

第二，客户开始对锁定更敏感。一旦数据库、队列、基础设施即代码都变成云市场里的托管 SKU，迁移成本就不再是导数据，而是重写 IAM、重接告警、重谈区域承诺。多云策略因此从口号变成采购条款：同一类组件至少要有一条不经过单一云市场的部署路径。这给了原厂和独立托管商一条缝——不是比云更便宜，而是作为“退出选项”被买下来。

第三，开源基金会和中立商标开始被当成基础设施，而不只是精神符号。项目放进基金会，不等于云就不能托管；它改变的是商标、发行版命名和“谁能说自己是官方”的权力。对采购部门来说，“官方”两个字有时比性能参数更值钱，因为它能写进合同的责任条款。

所以更准确的图景是三角关系：原厂想保住商业化权利，云厂商想保住托管规模，客户想保住退出权。三方都无法单方面定义“开源还算不算开源”。

开发者会被夹在中间

对写代码的人，这场变化很少表现为一份新的哲学宣言，更多表现为工具链上的摩擦。

本地 docker compose up 能跑的版本，和公司云上允许采购的版本，许可证可能已经不同。教程里的一行 terraform，在新项目里可能必须改成 tofu，状态文件迁移说明书比功能本身更长。安全扫描开始对“源代码可用但不是 OSI 认定的开源”标黄，合规同事要求解释，工程同事觉得这是律师问题。

这里有一个容易被忽略的成本：认知负荷。一个团队如果同时维护“社区分支、云托管分支、原厂企业分支”三套差异，所谓免费软件的总拥有成本会在人身上，而不是在发票上。2026 年不少平台工程团队的实际策略已经变得很务实——核心数据面尽量选协议稳定、分叉成本低的组件；外围控制面可以接受云锁定，因为本来就要用那家云的网络和身份。这不是理想，是把锁定预算花在最难迁移的那一层，而不是每一层都锁一遍。

也有团队走向相反方向：凡是会进生产数据路径的，优先选基金会治理或协议明确不会单方面收紧的项目，哪怕功能少一截。他们买的不是性能，是未来两年不用重写迁移脚本的确定性。

反方：也许这只是开源长大后的正常发票

有一种看法认为，外界把许可证变更戏剧化了。软件从爱好者项目变成关键基础设施之后，本来就不可能永远靠捐赠和 T 恤活着。云厂商收托管费，原厂收限制条款，客户为多云退出权付溢价，只是同一笔“谁为可靠性付钱”的账被拆开。真正的问题不是开源变味，而是行业太晚才承认：免费分发和免费运营从来不是一回事。

这个反方有力量。它提醒人们不要把 OSI 许可证文本当成商业模式。代码公开、可以审计、可以分叉，这些公共品属性并没有因为云市场多了一行 SKU 就消失。很多团队今天仍然在没有付任何原厂费用的情况下，把关键系统跑在开源数据面上。变化的是规模化之后的默认路径，不是个人和中小团队的自由。

但它也有限度。如果“官方路径”在事实上只剩云市场，而分叉又只有云巨头养得起，那么“你随时可以自己部署”就从权利变成理论可能性。权利还在许可证里，能力已经不在大多数组织的预算里。这种落差才是 2026 年争论的核心，而不是某一份 BSL 文本的措辞。

判断

我的判断是：开源不会死，但“开源等于可以直接当产品用”这个默认假设正在失效。2026 年的分界线不是源码是否可见，而是托管权、商标权和采购路径被谁握住。

对使用方，实用的做法不是站队骂云或骂原厂，而是在选型时把三件事写进同一张表：协议是否允许我们自己托管、云上的锁定点具体在 IAM 还是在数据格式、如果上游明天改许可证，分叉或迁移的最短路径是什么。答不上来的组件，就不该因为“它现在免费”进入核心数据路径。

对做开源商业的人，单纯改许可证已经不够。云厂商证明了自己可以 fork；客户证明了自己会为退出选项付费。接下来能站住的，更可能是那些把托管、支持和商标分开卖，而不是指望一份 LICENSE 文件替自己完成定价的项目。

代码可以继续免费。把代码变成企业敢采购的服务，正在变成另一门生意。这两件事从一开始就不是同一个价格。