谁该为源代码可用性买单？开源可持续性的经济学困境

一个被忽视的开源经济学问题

开源软件早已成为现代数字基础设施的基石。从操作系统、编程语言到无数的库和框架，几乎每一款商业软件的底层都或多或少地依赖开源组件。现代软件的依赖关系已经发展到令人惊叹的复杂程度——以JavaScript生态为例，npm注册表上托管超过200万个包，一个典型的企业级Node.js应用可能直接或间接依赖数百甚至上千个开源包。Harvard和Linux基金会2020年发布的《开源软件供应链安全》报告指出，全球商业软件中开源组件的占比已超过70%，而这些组件中有相当比例处于维护不足的状态。

然而，一个长期被回避的核心问题正在浮出水面：当源代码需要持续保持"可用"（availability）时，究竟谁应该为此承担成本？

这个问题看似简单，实则牵涉到开源生态的可持续性、维护者的权益分配，以及依赖开源的商业公司的责任边界。Hacker News 上关于"Who Should Pay for Source Code Availability?"的讨论虽然规模不大，却触及了整个行业的痛点。

hackernews source: Who Should Pay for Source Code Availability?

源代码可用性到底意味什么

不仅仅是把代码放上 GitHub

很多人对"源代码可用"的理解停留在"把代码上传到公开仓库"这一步。但真正的可用性远不止于此，它是一个持续的、需要投入资源的过程：

托管成本：代码仓库、镜像站点、下载带宽都需要持续的服务器与流量开销；
维护成本：修复漏洞、更新依赖、回应 issue、审查 PR，这些工作日复一日地消耗着维护者的精力；
合规成本：许多开源许可证要求分发者提供对应版本的源代码，这在企业级场景下意味着额外的存档与追溯责任；
长期存续：项目一旦被广泛采用，就承担起了"不能随意消失"的隐性社会契约。

换句话说，源代码的"可用"是一种需要长期供养的公共品，而非一次性的施舍。

免费的午餐正在崩塌

维护者的倦怠与依赖链危机

过去十余年，开源界反复出现同一类危机：一个被数百万项目依赖的关键库，背后往往只有一两位无偿的志愿者在苦苦支撑。当维护者精疲力竭而选择退出时，整个供应链都会随之震动。

这些事件的具体表现令人触目惊心。2014年的Heartbleed漏洞是最具警示意义的案例之一：OpenSSL这个被全球三分之二的Web服务器使用的加密库，其核心开发团队长期只有不到五名全职成员，年度捐款不足2000美元。2016年，仅有11行代码的npm包left-pad被作者从注册表中撤除，导致包括React、Babel在内的大量项目构建失败。2022年，colors.js和faker.js的维护者Marak Squires故意向自己的库注入无限循环代码以抗议大公司的"免费搭车"行为，影响了超过两万个依赖项目。同年曝光的Log4Shell漏洞（CVE-2021-44228）更是震动了整个行业——这个被无数Java应用使用的日志库Apache Log4j，其关键维护者同样面临资源严重不足的困境。

这些事件一次次提醒我们：建立在无偿劳动之上的基础设施是脆弱的。

问题的本质在于价值分配的严重错位：从开源中获益最多的往往是那些将其整合进商业产品、赚取巨额利润的大公司，而承担成本的却是分散的、缺乏回报的个人维护者。Tidelift的研究表明，超过80%的关键开源维护者是无偿工作的个人，而依赖他们代码的企业年收入可能达到数十亿美元。

许可证条款下的隐性义务

有意思的是，一些开源许可证（如 GPL 系列）明确要求：只要你分发了软件，就必须让接收方能够获取对应的源代码。这意味着"源代码可用性"不只是道德期待，在特定条件下更是具备法律约束力的义务。而履行这一义务的成本，往往被使用方轻描淡写地忽略了。

GPL（GNU General Public License）是自由软件基金会（FSF）创始人Richard Stallman于1989年首次发布的copyleft许可证，其核心机制是"传染性"——任何基于GPL代码的衍生作品也必须以GPL发布，且分发二进制代码时必须同时提供或承诺提供完整的对应源代码。GPLv2要求分发者以"不超过物理复制成本"的价格提供源代码，有效期至少三年；GPLv3则进一步明确了网络分发场景下的义务。AGPL将义务扩展到网络服务场景，意味着即使不分发二进制文件，仅通过网络提供服务也需要公开源代码。这些条款在嵌入式设备、云服务等领域产生了复杂的合规挑战，企业需要借助专门的工具（如Black Duck、FOSSA、Snyk）来追踪和管理开源合规，这本身又构成了一项不可忽视的成本。

谁来买单：几种可能的路径

商业受益者承担开源维护责任

最直接的答案是：从开源中获得商业价值的公司应当回馈生态。 这种回馈可以有多种形式：

直接资助关键项目的维护者；
通过 GitHub Sponsors、Open Collective 等平台进行常态化捐赠；
派遣自家工程师参与核心项目的维护；
承担镜像托管与分发的基础设施成本。

近年来，越来越多的科技巨头设立了开源项目办公室（OSPO, Open Source Program Office），试图系统性地管理对开源社区的投入。Google是最早设立OSPO的公司之一，其职责包括制定开源使用政策、管理对外贡献流程、处理许可证合规，以及协调对上游项目的资金和人力投入。截至2023年，TODO Group（一个推广OSPO最佳实践的行业组织）的成员已超过80家，包括微软、亚马逊、Meta等。

这是一个积极的趋势，但覆盖面仍远远不够。OSPO的资源分配往往倾向于企业自身依赖最深的"明星项目"，而忽视那些关键但不显眼的基础依赖。此外，中小企业通常缺乏设立OSPO的资源，形成了回馈生态的结构性盲区。

基金会与集体供养模式

另一条路径是通过中立的基金会来集中资源、统一分配。像 Linux 基金会、Apache 基金会这样的组织，本质上扮演了"公共品供养中介"的角色——企业向基金会缴纳会费，基金会再将资源投向需要维护的项目。

Linux基金会目前托管超过700个项目，会员企业包括几乎所有主要科技公司，年度预算超过2亿美元。Apache软件基金会则以其"Apache Way"——基于共识的社区治理模式著称，托管超过350个项目。这些基金会提供的不仅是资金，还包括法律保护（如专利防御）、基础设施（CI/CD、镜像分发）、以及项目治理框架。2020年成立的Open Source Security Foundation（OpenSSF）则专注于供应链安全，推出了Scorecard、Sigstore等工具来提升开源生态的整体安全水位。

这种模式的优势在于降低了单个项目对某个企业的依赖，也让维护工作更具持续性。但它同样面临难题：如何公平地评估哪些项目值得资助？ 那些默默无闻却至关重要的"长尾"依赖，往往难以进入基金会的视野。全球估计有数十万个活跃的开源项目，而能进入基金会庇护伞的只是极少数，绝大多数关键基础设施依然在基金会体系之外"裸奔"。

新型许可证与开源商业化探索

近年来兴起的各种"源代码可用"（source-available）而非严格"开源"的许可证，正是行业在探索可持续性时的产物。这类许可证允许用户查看和修改代码，但对商业用途施加限制，试图在开放与变现之间寻找平衡。

2018年以来，多家开源商业公司修改了许可证策略：Redis Labs引入了Commons Clause附加条款；MongoDB从AGPL转向自创的SSPL（Server Side Public License）；Elastic将Elasticsearch从Apache 2.0改为SSPL和Elastic License双许可；HashiCorp在2023年将Terraform从MPL改为BSL（Business Source License）。BSL由MariaDB公司设计，允许代码在非生产环境自由使用，但商业生产使用需要付费许可，且代码会在指定时间后（通常4年）自动转为完全开源许可。

OSI（Open Source Initiative）明确表示这些许可证不符合其"开源定义"（OSD），因为它们对使用领域施加了限制，违反了OSD的第六条。虽然这引发了关于"是否背离了开源精神"的激烈争论，但它至少反映了一个现实：纯粹依赖利他主义的模式已经难以支撑现代软件生态的规模。 这场许可证之争本质上反映了"开源"作为公共品与作为商业模式之间的深层张力——当一个项目的商业价值被云服务商大规模攫取时，原始开发者寻求保护自身利益的冲动既可以理解，也需要在更大的生态框架中寻找平衡。

结语：从"免费"到"公平"

"谁该为源代码可用性买单"这个问题，没有标准答案，但它的提出本身就意义重大。它迫使我们重新审视一个被长期视作理所当然的假设——开源是免费的。

事实是，开源从来都不是免费的，只是成本被隐形地转嫁给了一群缺乏话语权的维护者。随着软件供应链安全愈发受到重视——2021年美国白宫发布的网络安全行政令、2022年的开源软件安全峰会、以及欧盟《网络弹性法案》（Cyber Resilience Act）对开源软件的潜在影响——围绕开源可持续性的讨论正从边缘走向核心。监管机构开始关注开源依赖的风险，这既为开源生态带来了前所未有的关注度，也提出了新的治理挑战。

未来的健康生态，或许不在于让所有软件都保持绝对免费，而在于建立一套让受益者与贡献者之间价值流动更加公平的机制。无论是企业赞助、基金会供养，还是许可证创新，最终目标都应是同一个：让那些支撑起整个数字世界的代码，能够被持续、可靠地维护下去。