开源软件无人付费？强制资助的可行性探讨

开源资金困境的老问题

开源软件（FOSS）支撑着现代互联网的大部分基础设施，从操作系统内核到编程语言运行时，再到无数被大厂免费使用的库和框架。然而一个尴尬的现实始终存在：几乎没有人主动为这些软件付费。开发者社区里流传的一篇文章《Nobody pays for FOSS, we can force them to》正是直击这一痛点——如果自愿捐赠模式行不通，是否可以通过某种机制“强制”受益方付费？

该文在 Hacker News 上获得了 171 分、165 条评论的热度，说明这个议题触动了大量从业者的神经。这不是一个新问题，但每隔一段时间就会以新的形式重新浮出水面，反映出开源生态在商业化与可持续性上的结构性矛盾。

为什么自愿付费模式失灵

开源软件的核心特性是自由使用，这也意味着它天然缺乏付费的“闸门”。一家市值千亿的公司可以毫无成本地把某个由个人维护者在业余时间开发的库嵌入其核心产品，而维护者往往连一句感谢都收不到，更别提经济回报。

这种“搭便车”现象是经济学上典型的公共物品困境。当一件东西可以被无限复制且无法排他使用时，理性的个体和企业都倾向于坐享其成，而非主动付费。结果就是维护者精疲力竭、项目停滞，甚至出现关键基础设施因为无人维护而爆发安全事故的情况——业界对此早有惨痛教训。

捐赠平台如 GitHub Sponsors、Open Collective 等虽然提供了通道，但实际筹集到的资金相对于开源创造的经济价值来说微不足道。作者的核心观点正是：既然“请求”不起作用，那么讨论“强制”就成了绕不开的选项。

“强制付费”意味着什么

所谓“强制”，并非要推翻开源的自由精神，而是探索一种让大规模商业受益者承担相应责任的机制。这可能包括几种设想方向：

通过许可证约束

近年来出现的一些“源代码可见但商业受限”的许可证（如 SSPL、BSL 等）就是这类尝试。它们允许免费使用，但对将软件作为服务商业化的行为施加限制或收费要求。争议在于，这类许可证是否还算“真正的开源”，社区内部分歧巨大。

SSPL（Server Side Public License）由 MongoDB 于2018年推出，核心条款要求：若你将受保护的软件作为服务对外提供，则必须将整个服务栈的源代码一并开源，包括管理层、监控、自动化等周边代码。这一要求对云厂商极具杀伤力——AWS、GCP 等如果要托管 MongoDB 兼容服务，就必须开放其大量专有云基础设施代码，实际上使商业托管无利可图。BSL（Business Source License）则由 MariaDB 设计，允许在特定时间窗口（通常4年）内免费使用，但超出指定使用规模或范围的商业行为需要付费授权；时间窗口到期后，代码自动转为 GPL 等传统开源许可证。这两种许可证的根本争议在于：开源组织 OSI 均未认证其为"开源许可证"，因为它们对特定商业用途施加了限制，违背了开源定义（OSD）中"不得歧视特定用途"的原则。支持者称之为"源代码可见许可证"（source-available），批评者则认为这是借开源之名行封闭之实的"洗绿"行为。

通过行业规范或法律

更激进的设想是借助监管力量。既然企业依赖开源基础设施获利，是否可以通过某种类似“数字基础设施税”的机制，要求达到一定规模的商业主体为其使用的关键开源项目贡献资金？欧盟的《网络弹性法案》等立法已经开始触及企业对开源组件的责任问题，虽然出发点是安全而非资助。

欧盟《网络弹性法案》（Cyber Resilience Act，CRA）于2024年正式通过，要求在欧盟市场销售的含数字元素的产品承担强制性网络安全义务，包括漏洞披露、安全更新和合规文档。该法案最初草案曾引发开源社区的强烈反弹，核心担忧是：若开源维护者被视为"商业运营者"，他们将面临无力承担的合规成本，最终导致大量维护者选择放弃项目或将其下架。经过社区密集游说，最终版本对非商业目的的开源开发者给予了豁免。然而这也暴露出一个悖论：法律试图将"责任"与"商业化程度"挂钩，但现实中大量关键基础设施组件恰恰由非商业个人维护者承担，他们既无法享受商业庇护，又缺乏合规资源。CRA 的立法过程为未来"数字基础设施责任"立法提供了重要的博弈样本。

通过集体议价

另一条路径是维护者联合起来，形成对大型使用方的议价能力，将分散的、可被忽略的个体请求，转化为难以回避的集体诉求。

评论区的分歧与现实

Hacker News 的讨论中，观点呈现明显的两极分化。支持者认为，开源维护者长期被剥削，任何能改善其收入的机制都值得尝试；反对者则担忧“强制”会破坏开源的根基——一旦引入强制付费，开源就不再是开源，而滑向了某种受限的商业软件模式。

还有相当一部分务实的声音指出，问题的关键不在于“能不能强制”，而在于“如何执行”。谁来界定哪些项目值得付费？付费标准如何制定？跨国界的法律如何统一？这些执行层面的难题，往往比理念之争更棘手。

值得一提的是，一些评论者提出，与其纠结于向所有用户收费，不如聚焦于识别并对接那些真正有支付能力和支付意愿的企业客户——把免费用户当作漏斗顶端，把企业支持当作变现出口，这也是许多成功开源商业公司（如 Red Hat 模式）已经验证过的路径。

Red Hat 模式是开源商业化中被引用最频繁的成功案例。其核心逻辑是：不对软件本身收费，而对企业级服务收费——包括长期技术支持（LTS）、安全补丁、合规认证和专业咨询。Red Hat Enterprise Linux（RHEL）与免费的 CentOS/Fedora 共享大量代码，但前者面向对稳定性和法律责任有刚需的企业客户，订阅价格高昂。2019年 IBM 以340亿美元收购 Red Hat，证明了这一模式的商业价值。然而 Red Hat 模式有其局限性：它高度依赖软件本身具备足够复杂的企业级部署场景，适合操作系统、数据库、中间件等"有运维负担"的品类，对于功能单一的工具库或框架（如 left-pad 这类小型 npm 包）则几乎无法复制。这也是为什么讨论开源可持续性时，需要区分"平台级项目"与"组件级项目"——两者面临的商业化路径截然不同。

可持续开源没有银弹

这场讨论的价值不在于给出一个确定答案，而在于逼迫社区正视一个长期回避的现实：纯粹依赖利他主义和自愿捐赠的开源模式，在面对巨型商业受益者时是脆弱的。

“强制”或许是个刺激的说法，但其背后指向的是一个更根本的命题——如何在保持开放的同时，建立起让创造价值者获得回报的可持续机制。无论最终采取许可证创新、立法介入还是商业模式重构，开源生态都需要在理想主义与经济现实之间找到新的平衡点。这不是一次讨论能解决的，但每一次这样的争论，都在把行业往前推一步。