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

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

开源软件早已成为现代数字基础设施的基石。从操作系统、编程语言到无数的库和框架，几乎每一款商业软件的底层都或多或少地依赖开源组件。现代软件的依赖关系已经发展到令人惊叹的复杂程度——以JavaScript生态为例，npm注册表上托管超过200万个包，一个典型的企业级Node.js应用可能直接或间接依赖数百甚至上千个开源包。这种依赖关系往往呈树状甚至网状结构，一个顶层应用的node_modules目录中可能包含上千个传递性依赖（transitive dependencies），而开发者对其中绝大多数包的存在甚至一无所知。这种"依赖地狱"现象并非JavaScript独有——Python的PyPI、Rust的crates.io、Java的Maven Central都面临类似的依赖图爆炸问题，只是npm因其生态鼓励小型单功能包的文化（"微包哲学"）而使问题尤为突出。Harvard和Linux基金会2020年发布的《开源软件供应链安全》报告指出，全球商业软件中开源组件的占比已超过70%，而这些组件中有相当比例处于维护不足的状态。

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

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

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

不仅仅是把代码放上 GitHub

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

• 托管成本：代码仓库、镜像站点、下载带宽都需要持续的服务器与流量开销。GitHub虽然为公开仓库提供免费托管，但这本身是微软每年数亿美元基础设施投入的结果——一种由商业巨头补贴的公共品模式。对于需要自建镜像的场景（如中国大陆访问GitHub不稳定时的镜像需求、企业内网镜像），成本则完全由使用方承担；
• 维护成本：修复漏洞、更新依赖、回应 issue、审查 PR，这些工作日复一日地消耗着维护者的精力；
• 合规成本：许多开源许可证要求分发者提供对应版本的源代码，这在企业级场景下意味着额外的存档与追溯责任；
• 长期存续：项目一旦被广泛采用，就承担起了"不能随意消失"的隐性社会契约。Software Heritage项目（由INRIA发起）正试图成为源代码的"互联网档案馆"，截至2023年已归档超过160亿份源文件，但其运营同样依赖持续的资金投入。

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

免费的午餐正在崩塌

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

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

这些事件的具体表现令人触目惊心。2014年的Heartbleed漏洞是最具警示意义的案例之一：OpenSSL这个被全球三分之二的Web服务器使用的加密库，其核心开发团队长期只有不到五名全职成员，年度捐款不足2000美元。Heartbleed漏洞（CVE-2014-0160）源于TLS心跳扩展实现中的一个缓冲区过读错误，攻击者可以每次读取服务器内存中最多64KB的数据，可能获取私钥、会话令牌和用户密码等敏感信息。这个漏洞在代码中存在了超过两年才被发现，直接催生了Core Infrastructure Initiative（CII，后演变为OpenSSF）的成立，以及对OpenSSL项目的紧急注资。2016年，仅有11行代码的npm包left-pad被作者从注册表中撤除，导致包括React、Babel在内的大量项目构建失败。这一事件促使npm修改了其unpublish策略——发布超过72小时或有其他包依赖的包不能再被随意删除。2022年，colors.js和faker.js的维护者Marak Squires故意向自己的库注入无限循环代码以抗议大公司的"免费搭车"行为，影响了超过两万个依赖项目。同年曝光的Log4Shell漏洞（CVE-2021-44228）更是震动了整个行业——这个被无数Java应用使用的日志库Apache Log4j，其关键维护者同样面临资源严重不足的困境。Log4Shell被安全研究人员评为CVSS满分10.0的漏洞，其利用门槛极低（仅需在日志中注入一段JNDI查询字符串），影响范围覆盖了从Minecraft服务器到企业级云服务的几乎所有Java应用。

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

问题的本质在于价值分配的严重错位：从开源中获益最多的往往是那些将其整合进商业产品、赚取巨额利润的大公司，而承担成本的却是分散的、缺乏回报的个人维护者。Tidelift的研究表明，超过80%的关键开源维护者是无偿工作的个人，而依赖他们代码的企业年收入可能达到数十亿美元。这种现象在经济学中被称为"公地悲剧"（Tragedy of the Commons）的变体——所有人都从公共资源中受益，却没有人有足够的激励去维护它，最终导致资源的退化。不同于传统公地悲剧中的过度消费，开源面临的是"供给不足"的悲剧：使用者越多，维护负担越重，而激励机制却未随之扩展。

许可证条款下的隐性义务

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

GPL（GNU General Public License）是自由软件基金会（FSF）创始人Richard Stallman于1989年首次发布的copyleft许可证，其核心机制是"传染性"——任何基于GPL代码的衍生作品也必须以GPL发布，且分发二进制代码时必须同时提供或承诺提供完整的对应源代码。GPLv2要求分发者以"不超过物理复制成本"的价格提供源代码，有效期至少三年；GPLv3则进一步明确了网络分发场景下的义务，并增加了反Tivoization条款（防止硬件厂商通过签名验证阻止用户运行修改后的软件）和专利授权条款。AGPL将义务扩展到网络服务场景，意味着即使不分发二进制文件，仅通过网络提供服务也需要公开源代码——这正是MongoDB等公司最初选择AGPL的原因，也是后来它们认为AGPL保护力度不足而转向更严格许可证的背景。这些条款在嵌入式设备、云服务等领域产生了复杂的合规挑战，企业需要借助专门的工具（如Black Duck、FOSSA、Snyk）来追踪和管理开源合规。这些软件组成分析（SCA, Software Composition Analysis）工具通过扫描代码库和构建产物，识别所有开源组件及其许可证，生成SBOM（Software Bill of Materials，软件物料清单），帮助企业了解自身的许可证义务——这本身又构成了一项不可忽视的成本，企业级SCA工具的年费通常在数万到数十万美元不等。

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

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

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

• 直接资助关键项目的维护者；
• 通过 GitHub Sponsors、Open Collective、Tidelift等平台进行常态化捐赠。GitHub Sponsors自2019年推出以来已向维护者支付了数千万美元，但相对于开源创造的商业价值而言仍是九牛一毛；
• 派遣自家工程师参与核心项目的维护——这种"上游贡献"（upstream contribution）模式在Linux内核社区最为成熟，内核代码的绝大部分贡献如今来自企业雇员而非独立志愿者；
• 承担镜像托管与分发的基础设施成本。

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

这是一个积极的趋势，但覆盖面仍远远不够。OSPO的资源分配往往倾向于企业自身依赖最深的"明星项目"，而忽视那些关键但不显眼的基础依赖——这就是著名的"xkcd 2347"漫画所描述的场景：整个现代数字基础设施依赖于某个内布拉斯加州的无名维护者多年来无偿维护的项目。此外，中小企业通常缺乏设立OSPO的资源，形成了回馈生态的结构性盲区。

基金会与集体供养模式

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

Linux基金会目前托管超过700个项目（包括Kubernetes、Node.js、Hyperledger等），会员企业包括几乎所有主要科技公司，年度预算超过2亿美元。其运作模式类似于行业协会：白金会员年费可达50万美元，获得董事会席位和项目优先影响力；金银会员费用递减，影响力也相应降低。Apache软件基金会则以其"Apache Way"——基于共识的社区治理模式著称，托管超过350个项目。与Linux基金会的企业主导模式不同，Apache强调个人贡献者的平等地位，项目决策基于"懒共识"（lazy consensus）原则。这些基金会提供的不仅是资金，还包括法律保护（如专利防御）、基础设施（CI/CD、镜像分发）、以及项目治理框架。2020年成立的Open Source Security Foundation（OpenSSF）则专注于供应链安全，推出了Scorecard（自动评估开源项目安全实践）、Sigstore（代码签名透明化）、SLSA（Supply-chain Levels for Software Artifacts，供应链完整性框架）等工具来提升开源生态的整体安全水位。

这种模式的优势在于降低了单个项目对某个企业的依赖，也让维护工作更具持续性。但它同样面临难题：如何公平地评估哪些项目值得资助？ 那些默默无闻却至关重要的"长尾"依赖，往往难以进入基金会的视野。全球估计有数十万个活跃的开源项目，而能进入基金会庇护伞的只是极少数，绝大多数关键基础设施依然在基金会体系之外"裸奔"。一些新兴尝试正在试图解决这个问题：例如，基于依赖图数据（如deps.dev提供的数据）自动识别关键但资金不足的项目，或通过类似"彩票"的随机资助机制确保长尾项目也有机会获得支持。

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

近年来兴起的各种"源代码可用"（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公司于2013年设计，其核心机制颇具巧思：允许代码在非生产环境（开发、测试、个人使用）自由使用，但商业生产使用需要付费许可，且代码会在指定时间后（通常4年，称为"Change Date"）自动转为指定的完全开源许可（通常是Apache 2.0或GPL）。这意味着BSL本质上是一种"延迟开源"模式，确保开发者在商业价值窗口期内获得回报，同时保证代码最终进入公共领域。

OSI（Open Source Initiative，成立于1998年，负责维护"开源定义"并审批符合标准的许可证）明确表示这些许可证不符合其"开源定义"（OSD），因为它们对使用领域施加了限制，违反了OSD的第六条（"No Discrimination Against Fields of Endeavor"）。虽然这引发了关于"是否背离了开源精神"的激烈争论——支持者认为这是对云服务商"搭便车"行为的合理回应，反对者则担忧这将导致开源生态的碎片化和信任危机——但它至少反映了一个现实：纯粹依赖利他主义的模式已经难以支撑现代软件生态的规模。 这场许可证之争本质上反映了"开源"作为公共品与作为商业模式之间的深层张力——当一个项目的商业价值被云服务商大规模攫取时（AWS提供的托管Elasticsearch、Redis、MongoDB服务每年收入数亿美元，而原始项目获得的回报微乎其微），原始开发者寻求保护自身利益的冲动既可以理解，也需要在更大的生态框架中寻找平衡。值得注意的是，这些许可证变更也催生了社区分叉（fork）：Elastic的决定导致AWS创建了OpenSearch，HashiCorp的变更催生了OpenTofu——这既体现了开源生态的韧性，也提醒我们许可证策略的选择会产生深远的生态后果。

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

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

事实是，开源从来都不是免费的，只是成本被隐形地转嫁给了一群缺乏话语权的维护者。随着软件供应链安全愈发受到重视——2021年美国白宫发布的网络安全行政令（EO 14028，要求联邦供应商提供SBOM）、2022年的开源软件安全峰会（白宫召集科技巨头讨论开源安全投入，会后各公司承诺投入超过1.5亿美元）、以及欧盟《网络弹性法案》（Cyber Resilience Act，要求联网产品制造商对软件安全负责，其早期草案曾因可能波及开源维护者而引发社区强烈反弹，后续版本增加了对非商业开源活动的豁免条款）对开源软件的潜在影响——围绕开源可持续性的讨论正从边缘走向核心。监管机构开始关注开源依赖的风险，这既为开源生态带来了前所未有的关注度，也提出了新的治理挑战。

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

核心要点

核心要点