互联网依靠多少没有被看见的维护者？

Geoffrey Chen

研究与版本说明 本文属于《世界依靠谁来维护？》第 0.1 版研究稿，关注被商业和公共系统广泛调用的开源组件。开源项目的治理、许可证和资源差异很大，文章不把志愿维护者的处境概括成一种统一模式。欧盟《网络韧性法》的适用时间和配套指南仍需在正式发布前再次核查。

《世界依靠谁来维护？》· 第 4 篇

快速阅读

一个现代应用很少由单一团队写完。它调用操作系统、语言运行时、加密库、压缩工具、数据库驱动和大量软件包。用户与采购机构看见产品名称，依赖图却可能延伸到由少数人、基金会或志愿社区维护的组件。自由取得代码不表示维护成本为零，也不表示任何人已经承诺无限期支持。

开源具有重要的维护优势：代码可以检查、分叉和修补，知识不必封闭在一个供应商内部。与此同时，公开仓库不等于有足够审查者，下载次数也不会自动转化为资金、时间和安全能力。大量商业使用者可能分别认为自己的依赖很小，合在一起却把公共风险压到维护链的上游。

软件物料清单和依赖扫描能够回答“我们用了什么”，但仍不能回答“谁能在漏洞出现时修复、多久发布更新、旧版本怎样退出”。企业若只等待上游补丁，便把自己的产品责任当成许可证附赠服务。负责任的使用者需要维护依赖清单、测试升级、资助或贡献关键项目，并为无人继续维护的组件准备替换路径。

欧盟《网络韧性法》区分非商业开源贡献者、把数字产品投放市场的制造商，以及持续支持开源项目的某些法律实体，并为 open-source software stewards 设计较为特定的义务。这种区分承认责任应与商业角色和控制能力相联系，而不能把整个网络安全负担交给写下原始代码的个人。

项目受欢迎也不能证明维护健康。星标、提交次数和发布频率很难显示审查深度、维护者疲惫或是否有人可以接替。关键依赖需要明确的安全渠道、版本政策、测试能力和不止一人掌握发布流程。

本文的暂定判断是：开源维护不是慈善附属物，而是数字供应链治理。代码可见性提供了共同维护的可能，不保证共同维护已经发生。真正的责任应沿依赖链分布：上游透明处理漏洞，下游知道并测试自己的组成，商业受益者为持续能力付费，监管者则避免用企业式义务压垮非商业贡献。

一、产品名称掩盖了依赖结构

购买软件时，客户通常面对一个供应商、订阅计划和服务条款。界面呈现为单一产品，内部却由许多来源不同的组件组成。程序员为了可靠性与效率复用成熟库，这本来是软件工程的正常做法。重新实现加密、解析或网络协议不仅浪费，也可能更不安全。

复用改变了维护责任。一个下游应用的故障可能来自自己的代码、第三方商业服务、开源库或它们的组合。组件更新还可能修复安全问题，却破坏旧接口。最终产品团队必须决定是否升级、怎样测试和何时停止支持旧版本。

Linux Foundation、OpenSSF 与哈佛研究团队发布的 Census III分析企业生产应用中常见的开源应用库。它的意义不在于生成一份永久的热门排名，而是让依赖从个别代码仓库问题进入供应链观察。组织若不知道自己实际部署了什么，便无法在漏洞、许可证变化或停止维护时判断暴露范围。

二、开放代码为什么不等于免费维护

开源许可证允许用户依具体条款使用、查看、修改与再分发代码。它改变了知识和控制的分布：用户不必完全依赖原供应商，社区可以发现问题，项目也可能被分叉。这些都是真实的韧性来源。

但许可证授予的自由不自动生成劳动。审查补丁、回答问题、发布版本、维护构建系统、处理漏洞报告和协调贡献需要时间与专业能力。项目可以拥有大量下载，却只有少数持续维护者；也可能由企业员工在工作时间维护，或者由基金会组织资源。把所有开源都描述为业余志愿工作，同样失真。

经济错配发生于受益与责任分离。数千个组织使用一个组件，每个组织对其运行的边际影响很小，于是分别选择不贡献。总体依赖变得关键，上游资源却没有相应增加。这类似公共品问题，但不能只靠道德呼吁解决，因为组织需要知道哪些项目关键、资助能否改善安全，以及谁有治理权。

维护者也不应被要求接受无限责任。代码按许可证提供，通常没有对每种商业用途作保证。一个跨国公司把组件放入高风险产品时，具有测试、集成与盈利能力；把最终风险归给上游个人，会让责任远离最有控制能力的一方。

三、维护不只是修复漏洞

安全事件使开源维护最受关注，但日常工作范围更大。维护者评估功能请求、拒绝不合适变更、保持文档、更新依赖、迁移工具链，并在兼容性和改进之间选择。拒绝也是维护，因为每一项功能都会扩大以后测试与支持范围。

项目的“健康”无法由提交数量单独判断。稳定库可能很少改变，频繁提交也可能反映高故障。贡献者人数、响应时间、发布规律和治理文件提供部分信息，却需要结合软件关键性、成熟度和使用情境。把开源项目压成单一分数，会重复本系列所反对的可见性简化。

维护还包含安全地结束。项目停止时，应尽可能说明最后支持版本、已知风险和迁移选择。个人没有义务永远继续，但下游组织不能把一个仓库多年未更新自动解释为“一切稳定”。他们需要判断没有更新是成熟，还是无人能够处理问题。

四、谁真正知道一个产品用了什么

软件物料清单（SBOM）尝试记录产品所含组件及版本。依赖管理工具还能识别直接与间接依赖，帮助机构在漏洞公告后搜索受影响系统。这类可见性是维护前提，却不是完成。

清单可能过时，构建环境与生产部署也可能不同。组件名称和版本映射存在困难，供应商提供的清单未必包含服务端依赖。即使准确找到受影响库，组织仍要判断漏洞是否可达、补丁是否兼容、临时控制是否足够以及何时部署。

美国 CISA 等机构关于缩小 software understanding gap 的指导强调，软件生产者和使用者需要更清楚地理解组成与风险。这个方向值得肯定，但“理解”不应只变成采购一个扫描工具。没有人员处理结果，更多警报会形成新的积压。

依赖知识还需要跨组织传递。上游公告说明修复，包管理者重新发布，下游团队测试，产品供应商通知客户，运营人员完成部署。任何接口停顿，补丁都可能存在于仓库却没有进入实际系统。

五、一次更新为什么可能成为新的风险

“及时更新”是合理的安全建议，但大型系统不能在看到新版本后直接替换。更新可能改变接口、性能和数据格式，关键服务需要测试和回退。快速部署降低已知漏洞暴露，却可能引入运行故障。

这不是拖延补丁的理由，而是要求维护测试能力。持续集成、分阶段发布、兼容性测试和可回滚部署，使安全与稳定不必成为绝对二选一。组织若长期依赖过时版本，通常不是因为不知道有更新，而是升级路径已经被多年定制和技术债务堵塞。

上游维护者无法测试所有使用方式。下游最了解自己的配置和业务后果，因此必须承担集成责任。与此同时，下游发现的兼容问题若不反馈，上游也无法改善。开源维护的优势来自这种双向关系；把项目当作静态免费原料，会切断反馈。

六、欧盟为什么创造“开源软件管理者”角色

欧盟 Regulation (EU) 2024/2847，即《网络韧性法》，对含数字元素产品的安全与漏洞处理设置要求。立法同时意识到，个人非商业贡献者、商业产品制造商和持续支持开源开发的法律实体不应承担相同义务。

法规使用 open-source software steward 概念，指某些持续支持拟用于商业活动的开源项目并在其可持续性中发挥主要作用的法律实体。相关制度较制造商义务更有针对性，包含网络安全政策、漏洞处理和在特定情况下与监管机构合作。法规还明确，单纯向不由自己负责的非商业开源项目贡献代码，不应因此被当作制造商。

这种分层仍会面临实施困难。基金会规模差异很大，项目可能跨国，商业意图也不是总能轻易确定。合规成本若设计不当，会使小型组织退出；过度豁免又可能让商业企业通过形式安排逃避责任。正式应用需要结合生效时间、配套指南和具体角色，不能仅凭“使用了开源”作结论。

哲学上重要的地方，是法规尝试把责任与控制、持续支持和市场角色连接，而非追溯到最初作者。维护网络中的责任不应集中在离最终风险最远、资源最少的人身上。

七、商业使用者应当贡献什么

“使用开源就必须回馈”是一项有吸引力的道德主张，却不足以形成具体制度。贡献可以是资金、代码、测试、文档、安全审计、基础设施或让员工参与治理。项目实际需要不同，未经协调的大量补丁甚至会增加维护负担。

企业首先应知道关键依赖，并为内部集成承担责任。随后可以与项目沟通资源需要，支持长期维护而不以资助换取不透明控制。对广泛共享的关键组件，行业联合基金和基金会可能比每个企业分别签约更有效。

采购方也能改变激励。公共机构和企业可以要求供应商说明依赖、支持期限、漏洞处理和退出路径。要求不能变成把所有责任再次转给上游；供应商应证明自己具有持续测试与更新能力。

资助并不自动赋予决定权。开源社区有自己的治理和用户群，单一出资者的短期需求可能损害项目。稳定维护需要资源，也需要规则处理优先级、利益冲突和维护者更替。

八、可分叉是否足以保证连续性

开源常被认为具有终极退出能力：原项目停止，任何人都可以 fork。法律许可确实保留了可能性，却不保证有人拥有理解代码、建立社区、管理发布和承担安全响应的能力。分叉复制代码，不会自动复制信任、基础设施和维护关系。

因此，韧性要看知识是否分散到足以接续，而不是只看仓库是否公开。文档、可复现构建、测试、清晰许可证和多方治理能降低接续成本。若项目事实上只有一个人掌握发布密钥和架构知识，开放代码仍可能拥有关键单点。

这并不要求每个项目追求庞大委员会。小项目可以高效清楚地由少数人维护。关键是下游对依赖结构保持诚实：若一个组件成为关键基础，使用者应帮助降低单点风险，或准备替代。

九、AI 生成代码会减轻还是扩大维护负担

生成式 AI 可以帮助编写测试、解释代码和提出修复建议，也会降低生成新依赖和新代码的成本。生产速度提高并不意味着审核、集成和长期支持成本同比下降。组织可能更快制造一批无人真正理解的组件。

AI 还可能复制过时模式或建议不存在的包。即使生成代码在部署时通过测试，后来仍需要补丁、兼容与安全处理。作者身份模糊不会让责任消失；把生成结果放进产品的组织仍然决定使用情境和风险。

开源维护者可能收到更多低质量、自动生成的议题和补丁，使有限审查能力被占用。项目需要贡献规则，企业则应在提交前进行人工验证。AI 的合理作用是增加维护能力，而不是把上游社区当作免费审核层。

十、暂定判断：把开源看作关系，而不是原料

互联网并不依靠一个可计算的固定维护者人数。依赖随版本和部署改变，很多组件由组织化团队维护，也有项目资源稀少。寻找一个总数会制造精确错觉。更好的问题是：每项关键依赖是否存在可持续的知识、治理、响应与接续路径。

开源的公共价值在于允许检查、修改和共同维护。它没有保证共同体一定出现。下游商业和公共机构必须承担组成识别、风险判断、升级测试和退出计划，并依据使用程度支持上游能力。维护者则需要透明地说明支持范围和安全渠道，但不能被赋予对所有下游用途的无限责任。

监管应沿角色分配义务。把企业式合规直接施加给个人贡献者，会减少开放协作；让商业产品只以“这是开源组件”为由免责，则把收益私有化、风险上移。欧盟法规的角色区分提供了一次重要尝试，实际效果仍需观察。

什么会改变本文判断？更好的数据可能显示，企业资助并不稳定改善项目安全，或者强制清单在某些领域造成大量无用信息。具体工具应随证据修正。较坚实的原则是：取得代码的自由与持续支持的承诺不是同一件事，依赖他人维护成果的组织必须知道自己承担了什么责任。

主要资料与进一步阅读

系列导航： 《世界依靠谁来维护？》系列总览

了解 Geoffrey Chen 的更多信息

订阅后即可通过电子邮件收到最新文章。