字面意义上的“道路与桥梁”Taking Roads and Bridges literally

上周我参加了联合国开源周（UN Open Source Week），在会上，十几个国家的政府官员相继起立发言，将开源描述为关键基础设施。自 Nadia Eghbal 在2016年为福特基金会（Ford Foundation）撰写《道路与桥梁》（Roads and Bridges）报告以来，这种定位就已成为标准说法，经过十年时间，它终于传达到了它所描述的受众耳中。坐在坐满本职工作就是公共基础设施的与会者的联合国会议室里，我开始思考：如果不把报告的标题仅仅当作一个比喻，而是真正去研究现实中的桥梁是如何维护的，那意味着什么。

《道路与桥梁》（Roads and Bridges）的受众是2016年时正在倾听的科技公司和慈善基金会，这两者都不负责维护桥梁：他们免费在桥上通行，通过纳税为桥梁买单，将日常维护交给了国家。向这些听众详细解释《国家桥梁检测标准》（National Bridge Inspection Standards）和公路信托基金（Highway Trust Fund），就等同于向非政府受众描述一项政府计划，因此报告只停留在类比层面，并呼吁在场人士伸出援手。

这十年来，出现了 GitHub Sponsors、Open Collective、企业 OSPO 预算以及基金会资助：这些都是基础设施用户的自愿捐助。在土木工程领域，与此对应的是“认领公路”（Adopt-a-Highway）项目，即当地企业出资清理一段公路上的垃圾，并以此换取在指示牌上署名。“认领公路”是一个确实能带来一些好处的真实项目，但没有任何一个州会指望靠它来防止桥梁倒塌。

《国家桥梁检测标准》（National Bridge Inspection Standards）

在美国，每一座跨度超过20英尺的公共道路桥梁都处于自1971年起实施的联邦体系维护之下，该体系是在1967年银桥（Silver Bridge）坍塌导致46人丧生后建立的。《国家桥梁检测标准》被编纂入《美国联邦法规》第23卷第650部分C子部分（23 CFR 650 Subpart C），其中明确规定了以下内容（包括但不限于）：

将一个结构认定为公共桥梁，会自动开启一整套机制：清单录入、检查周期、状况评级、资金支持以及关闭权限。而对于开源项目，同样的认定目前仅仅开启了口头表态。

随之而来的政府行动监管的是开源的使用者，而非开源基础设施本身。欧盟《网络弹性法案》、美国第 14028 号行政命令以及各项 SBOM（软件物料清单）强制规定，对发布包含开源组件产品的公司施加了义务。用桥梁来打个比方，这相当于要求运输公司证明其卡车途经了哪些桥梁，却没有雇佣任何桥梁检查员。

所有权

关键的开源项目通常拥有明确的归属者（具名维护者、基金会或公司），单一维护者的统计数据之所以令人担忧，是因为这个数字是“一”，而不是因为所有者“未知”。它们所缺乏的是国家备案的所有者，但桥梁管理体制并不要求这一点。底特律与温莎之间的大使桥承载着约四分之一的公路美加商品贸易，它归一家私人公司所有，但依然要接受联邦检查，因为该体制约束的是建筑结构所承担的功能，而不是谁拥有其产权。我们确切地知道它的所有者是谁，并且放手让他们自己去管理了。

无异常结果

NBIS（国家桥梁检查标准）中最枯燥的部分，恰恰是开源世界中最缺乏对应机制的环节：没有发现任何问题的检查记录，会与发现主梁裂缝的检查记录以完全相同的正式程序归档。检查员为桥面记录“9”，为上部结构记录“9”，签上日期和名字，随后这份记录便与其他所有记录一同被录入 National Bridge Inventory（国家桥梁清单），其中“上次检查日期”本身就是一个可独立查询的字段。

在开源领域，没有发现任何问题的审查几乎从不对外发布，因为唯一有去向的产出只有“发现的问题”：issues、pull requests 和 CVE。某个项目没有 CVE，根本无法让人区分是“有经验的人检查过了并且确认安全”，还是“根本没人看过”。漏洞赏金、CVE 荣誉、安全公告致谢以及会议演讲，所有回报都只针对“发现的问题”，而花时间确认某个库是否安全则毫无收益且不留痕迹，这使得执行一次无异常的审查在经济上极不理智。桥梁检查员无论评分为 9 还是 3，拿到的报酬都是一样的，正是这种固定费率，让例行检查成为一项真正的工作，而不是业余爱好。

拥有认证资质的检查员给出的“确认安全”结论是一份法律记录，因为国家已经明确了什么样的人具备检查员资格，以及一次检查包含哪些具体内容；相比之下，在 GitHub 上随口留下一句“我看过了，感觉没问题”的评论，理所当然会被视为毫无价值，因为根本无从知晓是谁检查的、检查力度有多大，或者检查了什么内容。如果没有对“什么是检查”以及“谁有资格进行检查”作出明确定义，一份无异常的报告就毫无分量，因此也就没有人愿意费心去写了。

采购

据我所知，德国的 Sovereign Tech Agency 是政府将开源视为其应承担责任的基础设施的最典型范例，而最能说明问题的细节在于其法律形式。该机构于 2022 年成立时名为 Sovereign Tech Fund，并在 2024 年更名为 Sovereign Tech Agency，这一转变意味着它从一个单纯拨款的机构转变为一个实际开展工作的实体。它通过服务合同而非拨款的形式向维护者支付报酬，因为根据德国的公共支出法律，政府很难在没有明确对价回报的情况下直接将资金无偿赠予。

这种约束通常被描述为一种官僚障碍，但在这里它发挥的作用与在土木工程中相同：州交通部门通过协议向承包商采购检查和维修服务，协议中规定了工作范围、交付物、进度和验收标准。合同将维护者定位为州政府因需要完成某项工作而购买其服务的专业人员，这比大多数开源资金所陷入的“受助人与资助人”关系更准确，也更具尊严。

采购机构会自行编写工作说明书（涉及哪个项目、哪些组件、采用何种方法论、发布什么内容以及何时发布），因此，基于该工作范围向公共机构提交的评审之所以具有分量，是因为委托方及其具体要求，而不是因为评审者持有的任何认证。工程标准通常就是这样传播的：大型公共买方写下他们愿意为何种工作付款，承包商则趋同于能够赢得合同的标准。这也避免了关于谁有权为开源设定规范的争论：工作说明书不对生态系统主张任何权威，只对采购订单有效。

工作范围

开源项目的维护合同有一个显而易见的工作范围，其中大部分是维护者已经在无偿做的工作：

列表上的每一项都会产生一个交付物，无论是否发现问题：因为覆盖率无论如何都是一个百分比，兼容性矩阵的每个单元格都有一个值，而在特定日期根据既定方法论进行的安全审查本身就是一份记录，即使发现的问题数量为零。这些交付物可以映射到组件状态评级，这是一种跨多个维度的带时间戳的概况，而不是单一的健康评分，其中每一项都可以按周期重新测量。这种概况还可以带有等效的“限载标识”，报告记录表明该项目在声明的限制内是完好的（例如“仅为 LTS 平台维护”、“未针对不受信任的输入进行强化”），而无需在“完全健康”和“警告标签”之间二选一，这是开源目前无法表达的状态。将足够多合同的报告汇总起来，得到的就是一份清单，包含结构编号、记录在案的所有者、上次检查日期以及各组件的状态。

文档会过时，依赖项会老化，CI 矩阵会停止匹配人们使用的平台，其周期比混凝土风化还要短，因为库运行的环境是其他同样在不断变化的软件。正确的工具是定期维护合同，而不是一次性资助或赏金，因此“我们在 2024 年资助了那个项目”听起来应该和“我们在 2024 年检查了那座桥”一样奇怪。该合同的边界是状态评估和维护，而不是功能开发，因此政府购买的是“保持其屹立不倒并报告其状况”的服务，这提前打消了人们对于政府资金会让政府插手项目路线图的担忧。

“道路与桥梁”这一隐喻所指向的机构已经存在，背后有五十年的法规、判例法和采购实践作为支撑，而这些都不是靠要求卡车运输公司赞助他们最喜欢的高架桥建立起来的。