摘要

  • W3C 在 10 月 27 日把 WebMCP polyfill 列为开源计划的第二个试点。规范走向标准轨道、浏览器出现可互操作的原生实现，两个条件满足后，补丁才有逐步退场的路径。
  • 10 月成立的社区组目标是到 2028 年年中推动完整计划，其章程却明文排除试点选拔。现行政策把托管、停办、资源、品牌和捐助决定交给 W3C 员工。

项目先住进来，房规还在写

一段补丁代码的优点，往往是终有一天可以不用它。W3C 10 月 27 日公布的第二个试点围绕 WebMCP polyfill：先发布 npm 包，支持生命周期事件和声明式用法，并跟进规范与 Web 平台测试。公告还替这段代码写了一个有条件的告别：规范进入标准推进过程，浏览器也拿出能够互操作的原生实现，polyfill 便可逐步退出。这里没有确定的截止日期，更没有已经发生的原生替代。两个条件少一个，桥就不能按公告所说拆掉。

开源计划本身没有同样清楚的权力交接时间表。它的第一个试点是 9 月公布的 Can I VC?，一项由 W3C 成员 Digital Bazaar 提供的可验证凭证看板。看板与可安装的浏览器能力补丁，维护成本和对外依赖都不一样。它们已经进入 W3C 的试点计划，未来替它们决定准入、维持、改变状态和退出的完整治理机构却尚在设计。先有住客，后定房规。这种次序在试点阶段可以理解，也使早期决定更容易变成不成文先例。

W3C 10 月 21 日启动的社区组要为 2028 年年中推出完整计划做准备，加入该组不要求 W3C 会员资格。章程把项目范围、生命周期、状态变更、争议上诉、捐助、安全、许可和可能的计划委员会都列为研究建议事项，并设想完整计划成立后由继任治理体接手，社区组归档。参与者能在这里影响未来规则，这不是摆设。

但是，章程也把一把最现实的钥匙拿走了：该组不参与决定哪些试点进入计划。W3C 员工会通报试点进展，供讨论参考。听取入选消息，与决定谁能入选，是两回事。把前者写成后者，会让开放参与的门面掩盖今天真正行使的权力。

现行政策并非空白纸

计划的一般政策解释，文中作为决策者的“W3C”指 W3C 员工；文件没有说明管理层如何在员工内部划分具体权限。项目生命周期的完整定义仍在制定中。现有政策已写明：员工监督项目健康，活动不足时与项目寻找恢复路径；停止托管、负责地结束或导出项目、以及重启停办项目，也由员工决定。

对维护者而言，“托管”绝非一项只有服务器费用的服务。W3C 决定项目知识产权、标识、商标、域名、基础设施、人手与品牌使用。代码仓库可以复制，机构名称所带来的持续可信度和法律、运营支撑不能一键克隆。倘若某个项目所需最低资源不再足够，谁定义“最低”、谁认定失去条件、谁决定导出方式，就会直接改变用户能否继续依赖这个包。

钱也沿着这条权力线流动。政策让 W3C 决定接受现金或实物支持，并要求员工尽早参与潜在资助者的沟通；同时寻求切断捐助与项目战略、技术决策之间的直接控制关系。W3C 可从收到的捐助中保留 20% 支付计划开支，并承诺定期概括资金管理、纳入年度审计。20% 是政策授权，不是这两个试点已经被扣款的证据。应被公开说清的，是每项支持带来什么资源、附带什么条件、谁有权重新分配。

员工在试点期握有法律、品牌和预算责任，并不奇怪。W3C 用自己的机构身份承载软件，不能假装风险已经交给尚未成立的委员会。真正需要盯住的是交接：继任机构究竟获得项目状态和争议的决定权，还是只获得建议权？如果员工仍保留法律与财政否决权，其范围何时触发？没有写明这些界线的“社区治理”，到了第一次资源紧张时就会变成各说各话。

下一篇值得读的是授权文件

WebMCP polyfill 将来若满足退场条件，仍有人要决定何时停发包、怎样处理安全修复、保留哪些测试与文档、W3C 的项目名义何时结束。技术条件不会自己执行制度动作。同样，第三个试点若要入门，应有可查的标准、签署者和理由。一个新项目的彩色发布图，比不上这三行决定链。

目前公开材料没有列出试点准入在员工内部的具体授权，也没有最终的生命周期争议申诉通道。带日期的授权文件或继任章程会改变这一判断。在那之前，W3C 的新补丁可以准确描述自己何时失去必要性；接手决定的人和程序，却仍比代码模糊。

来源