开源即基础设施：字面意义上的道路与桥梁

# 将《道路与桥梁》照字面意思理解 来源：https://nesbitt.io/2026/06/30/taking-roads-and-bridges-literally.html 上周我参加了联合国开源周（https://www.unopensource.org/），十几个国家的官员轮流上台，将开源描述为关键基础设施。自纳迪亚·埃格巴尔（Nadia Eghbal）在2016年为福特基金会撰写《道路与桥梁：数字基础设施背后看不见的劳动》（https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/）报告以来，这一框架便成为标准说法，十年后，它终于触及了报告所描述的受众。坐在联合国会议室里，周围都是从事公共基础设施工作的人，我开始思考：如果我们不再把标题当作隐喻，而是看看桥梁实际是如何维护的，那会意味着什么。 《道路与桥梁》报告的目标受众是2016年听报告的那些人——科技公司和慈善基金会，这两者都不负责维护桥梁：他们免费从桥上驶过，通过税收支付费用，而维护工作则留给政府。向那个会议室里的人详细解释《国家桥梁检测标准》和《公路信托基金》，相当于向非政府听众描述一个政府项目，所以报告止步于类比，并请在场的人提供帮助。 这十年催生了 GitHub Sponsors、Open Collective、企业 OSPO 预算以及基金会资助：这些都是基础设施使用者的自愿贡献。在土木工程领域，与之对应的是“领养公路”（https://en.wikipedia.org/wiki/Adopt-a-Highway）项目，当地企业出资清理某段公路上的垃圾，换来在指示牌上写上自己的名字。“领养公路”是一个现实的、能带来一些好处的项目，但没有哪个州会指望它来阻止一座桥梁塌进河里。 ## 国家桥梁检测标准 在美国，所有跨度超过20英尺的公共道路桥梁都受制于一个自1971年开始运行的联邦制度，该制度是在1967年银桥坍塌（https://en.wikipedia.org/wiki/Silver_Bridge）造成46人死亡后建立的。国家桥梁检测标准（https://www.fhwa.dot.gov/bridge/nbis2022.cfm）被编纂在《联邦法规》第23卷第650部分C小节（https://www.ecfr.gov/current/title-23/chapter-I/subchapter-G/part-650/subpart-C）中，具体规定了以下内容： - **强制检测**。每座桥梁都按照固定周期由持证检查员（https://www.fhwa.dot.gov/bridge/nbis/index.cfm）进行检查，无论桥梁所有者是谁，也无论所有者是否同意：默认的常规检测间隔为24个月，高风险结构周期更短，在数据支持的情况下可采用基于风险的更长间隔。 - **构件状况评级**。每次检测都会对桥面、上部结构和下部结构给出0–9的评级。“状况较差”以及2018年替换掉的旧标签“结构性缺陷”（https://highways.dot.gov/highway-history/structurally-deficient-bridge-meaning-term）都是与这些数字挂钩的术语，而非主观判断。 - **限载通行**。一座已经退化到低于设计载荷的桥梁在法律上会被降级（https://www.fhwa.dot.gov/bridge/loadrating/）：会竖起标志限制可通行的车辆重量，这样桥梁就能以降低后的能力保持开放，而不是被忽视或关闭。 - **记录清单**。每座桥梁在国家桥梁清单（https://www.fhwa.dot.gov/bridge/nbi.cfm）中都有一个结构编号，有记录在案的所有者，整个数据集是公开且可查询的（https://infobridge.fhwa.dot.gov/）。 - **公式化拨款**。联邦燃油税流入公路信托基金（https://www.fhwa.dot.gov/highwaytrustfund/），并按公式分配给各州。这笔资金是循环且可预测的，不会由某个季度心情好的捐赠者随意决定。 - **事后调查**。重大坍塌事件后，国家运输安全委员会（NTSB）会出具正式事故报告，包括可能原因的发现和建议：如明尼阿波利斯I-35W桥（https://www.ntsb.gov/investigations/AccidentReports/Reports/HAR0803.pdf）、匹兹堡弗恩霍洛桥（https://www.ntsb.gov/investigations/Pages/HWY22MH003.aspx）。 将一个结构认定为公共桥梁，会自动开启所有这些：清单条目、检测周期、状况评级、资金线、关闭权限。对于开源项目，同样的认定目前开启的只是一场演讲。 政府随之采取的行动监管的是开源的*消费者*，而非基础设施本身。欧盟《网络弹性法案》（https://eur-lex.europa.eu/eli/reg/2024/2847/oj）、美国第14028号行政令（https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity）以及各种软件物料清单（SBOM）强制要求，将义务施加在那些产品中包含开源的公司身上。用桥梁术语来说，这相当于要求运输公司证明他们的卡车经过了哪些桥梁，但同时却不雇佣任何桥梁检查员。 ## 所有权 关键的开源项目通常有可识别的所有者（具名维护者、基金会、公司），而单人维护者统计数据（https://opensourcesecurity.io/2025/08-oss-one-person/）之所以令人担忧，是因为人数为1，而非因为所有者未知。它们缺少的是一个*国家*记录在案的所有者，但桥梁制度并不要求这一点。连接底特律和温莎的大使桥（https://en.wikipedia.org/wiki/Ambassador_Bridge）承载了美加之间约四分之一的路运商品贸易，归一家私营公司（https://www.ambassadorbridge.com/）所有，但仍需接受联邦检查，因为该制度取决于结构所执行的功能，而非产权证书上写的是谁。我们很清楚谁拥有它，并且我们任由他们自行管理。 ## 空结果 国家桥梁检测标准中最没有开源对应物的部分，也是最无聊的部分：一次没有发现任何问题的检测，其归档手续与发现主梁裂缝的检测完全相同。检查员记录桥面9分、上部结构9分，注明日期并签名，然后与其他所有记录一起进入国家桥梁清单，其中上次检测日期本身就是一个可查询字段。 在开源领域，一次没有发现任何问题的审查几乎从不发表，因为唯一有地方可去的产出是发现项：问题、拉取请求、CVE（常见漏洞与暴露）。一个项目没有CVE，无法区分“有胜任能力的人检查过，没问题”和“没人仔细看过”。漏洞赏金、CVE致谢、安全公告致谢以及会议演讲都只对有发现项才给予回报，而花时间确认一个库是安全无虞的，不仅没有收益，也不会留下任何痕迹，这使得进行干净的审查在经济上不合理（https://nesbitt.io/2026/06/18/open-source-vs-the-invisible-hand.html）。桥梁检查员无论给出9分还是3分都得到相同的报酬，正是这种固定费率使得例行检查成为一份工作，而不是一种爱好。 持证检查员出具的“经检查安全”是一份法律记录，因为国家定义了谁算检查员、检查包括哪些内容；而GitHub上一条“我看了这个，看起来没问题”的路过评论理所当然地被认为毫无价值，因为无法知道是谁看的、看得多仔细、以及看了哪个版本。如果没有对“什么是检查”以及“谁有资格执行”的定义，一份干净的报告就没有分量，所以没人会费力去写。 ## 采购 德国的“主权技术署”（https://www.sovereign.tech/）是我所知道的政府将开源视为其应承担一定责任的基础设施的最清晰例子，而其法律形式则透露出关键细节。它于2022年成立时名为“主权技术*基金*”，2024年更名为（https://www.sovereign.tech/news/sovereign-tech-agency）“主权技术*署*”，从发放资金的机构转变为从事实际工作的机构，并通过服务合同（https://www.sovereign.tech/programs/applications#what-format-does-the-investment-take）支付维护者，而非提供资助，因为德国公共支出法使得政府很难在没有明确对价的情况下直接送钱。 这一约束通常被描述为官僚障碍，但在这里它发挥着与土木工程中相同的作用：州交通部门通过协议（https://www.fhwa.dot.gov/bridge/nbis/docs/contractingoutbridgeinspection.pdf）向承包商采购检测和维修服务，协议明确了范围、交付物、时间表和验收标准。合同将维护者定位为国家因需要完成工作而从其处购买服务的专业人士，这比大多数开源资金所陷入的受赠者与恩主关系更为准确且更有尊严。 采购机构自行编写工作范围（哪个项目、哪些组件、什么方法、交付什么、何时交付），因此针对该范围向公共机构交付的审查因其委托人和具体规范而有分量，而非基于审查员持有的任何认证。工程标准通常以这种方式传播：大型公共买家写下他们愿意支付的内容，而承包商则趋同于能赢得订单的做法。这也避免了“谁有权为开源设定规范”的争论：一份工作范围并不声称对整个生态拥有权威，只对其采购订单拥有权威。 ## 工作范围 开源项目的维护合同显然有其工作范围，而且大部分内容都是维护者已经无偿在做的工作： - 测试覆盖率 - 文档 - 性能基准 - 安全审查 - 针对所支持语言和平台版本的兼容性矩阵 - 依赖项更新 这份清单上的每一项都会产生人工制品，无论是否发现问题，因为覆盖率始终是一个百分比；兼容性矩阵的每个单元格都有值；在给定日期针对既定方法进行的安全审查，即使发现数为零，也是一份记录。这些人工制品等同于构件状况评级，是一个跨多个维度的、带有日期戳的概况，而不是单一的健康评分（https://nesbitt.io/2026/05/09/the-mismeasure-of-open-source.html），每个维度都可以按周期重新测量。一个概况还可以承载相当于限载通行的信息，即报告记录该项目在所述限制范围内是安全的（例如“仅为LTS平台维护”、“未针对不可信输入进行加固”），而无需在完全健康和警告标签之间做出选择——这是开源目前无法表达的状态。将足够多的合同报告汇总起来，结果就是一个清单，包含结构编号、记录在案的所有者、上次检测日期以及按构件划分的状况。 文档会过时，依赖项会过时，CI矩阵不再匹配人们使用的平台，其周期比混凝土风化周期更短，因为库运行的环境是同样在变化的其他软件。正确的工具是定期维护合同，而非一次性资助或赏金。“我们2024年资助了那个项目”听起来应该像“我们2024年检查了那座桥”一样奇怪。该合同的边界是状况评估和维护，而非功能开发，因此政府购买的是“保持其运行并报告其状况”，这预先回答了人们的担忧：政府资金会将政府之手伸向项目的路线图。 《道路与桥梁》隐喻所指的机构早已存在，背后有五十年的法规、判例法和采购实践，而这一切都不是靠要求卡车公司赞助它们心爱的立交桥建立起来的。