「开源之道」 2026-10-27 搜集事件和材料

「开源之道」昨日阅读 · 2026-10-26

今日主线可以压成一句：当验证能力集中在极少数主体手里时，即使它免费，分配权也仍然是集中的。

Pulse 补充（08:10 补跑十一项目）：今日最硬的一条其实不在 L1 发布面，而在 Git 的 L2——一个「以共识为唯一决策方式」的项目，正在为「万一共识失败怎么办」写宪法。

而十一项目拼起来看，今日只有两种制度动作：为冲突预先造规则（Git、ASF），或让规则沉进流程与机器（Kernel、K8s、LLVM、Python、Debian）。前者是制度的显性化，后者是制度的隐身化。

📄 最新开源研究论文

1. 谁有权检查你的合规记录：开源作为「监管基础设施」，以及 EU AI Act 没有回答的那个问题

  • 作者：Harish Kumar（独立研究者）
  • 来源：OSF Preprints 预印本 v1（2026-10-10 创建，2026-10-22 最后修改），CC-BY 4.0；另有 SSRN 镜像 DOI 10.2139/ssrn.7543479、Zenodo 同行评审版 DOI 10.5281/zenodo.23056755
  • 链接：doi.org/10.31219/osf.io/u9jgk_v1（全文：osf.io/preprints/osf/u9jgk）

摘要：EU AI Act 要求高风险 AI 系统的提供者与部署者生成、保存并交出记录——自动日志、技术文档、应监管要求提供的信息。一个「AI 治理工具」市场正在成形，负责生产这些记录。论文问了一个 Act 本身没有回答的窄问题：谁能检查这样一份记录，用什么检查？ 如果唯一能读取并验证证据记录的软件，是由「其客户生产了这份记录的那一方」销售的，那么监管机构、公告机构（notified body）和受影响的个人，就都依赖这家供应商的善意、定价能力和它能否活下去。作者称此为验证不对称（verification asymmetry）。

论文先从一手法条谨慎梳理 EU 法当下如何对待开源：AI Act 的排除与豁免条款（Article 2(12)、经 Regulation (EU) 2026/1744 修订的 Article 25(4)、Article 53(2)、Recital 89 与 102–104）；Cyber Resilience Act 对自由与开源软件的定义及「open-source software steward」制度（Articles 3(14)、3(48)、24、25、64(10)）；以及作者找到的唯一一处欧盟法强制要求信任关键软件开源许可的地方——European Digital Identity Wallet（经修订的 Regulation (EU) No 910/2014 Article 5a(3)）。

随后考察四个「开放验证成为共享基础设施」的先例：Certificate Transparency、ACME/Let’s Encrypt、Sigstore、可复现构建（reproducible builds），并辨析它们成功的原因——其中相当一部分与许可证无关。最后比较三种划线位置（全部开放／开放验证+商业化运营／封闭+托管与权力机构访问）对监管方、部署方、受影响者与供应商各自的后果。核心主张：验证侧（格式规范、验证器实现、测试向量）具有基础设施的经济属性，应当开放；增值运营可以继续商业化。 论文为概念性研究，不含测量，也不对任何公司的许可决策表态。

为什么与开源之道相关：这篇论文把一个长期被当作「道德讨论」的问题重新还原成产权与交易成本问题：开源之所以能降低社会验证成本，不是因为许可证有道德感，而是因为它把验证工具的产权从「供应商的私有资产」移到了「任何人都可持有」的位置。这正好接上 10-26 日报那篇《The Economics of Independent AI Assurance》的判准——信任品只能靠外部人「以同样成本独立复核」才能变成检验品。此文更进一步：它指出这个转换发生在工具层，而不是在模型层、权重层。 与之呼应的四个先例也极具说明力：CT、ACME、Sigstore、可复现构建——它们全部是验证协议而非产品，全部由中立方托管，全部被监管或行业当作基础设施默认采用。

开源之道视角点评：最锋利的一句在它的分类里——作者把「开放验证+商业运营」单列一档，等于说：开源的界线不在「有没有收费」，而在「收费方是否同时把判定标准握在手里」。 这个区分可以直接拿来量当下的许多说法：某平台的审计工具可以免费给你用，但你无法在它缺席时自己得出同样的结论，那按此文的标准，它仍然是封闭的——只是把「锁定」从代码挪到了验证器。

另一个值得记下的细节是：欧盟法至今只有一处（数字身份钱包）强制要求信任关键软件开源。这是很硬的证据：「开源是默认选项」在立法层面还远未成立，它现在是例外条款，不是原则。 要让它成为原则，需要的是把验证侧定义成公共品并写入标准，而不是靠更多公司发善心。

📰 开源动态摘要

1. OSS Scanner 上线十九天：184 个项目自己打开门，609 份申请被拒

  • 来源：Anthropic Frontier Red Team / Safeguards Research（OSS Scanner 官网 + 发布博文，2026-10-08 上线，10-13 更新细则）/ GitHub API（anthropics/oss-scanner 仓库实时统计，截至 2026-10-27 03:00 CST）
  • 链接：red.anthropic.com/oss-scanner ｜ 发布文

摘要：OSS Scanner 是一个自愿接入（opt-in）的开源仓库安全扫描服务，来自 Project Glasswing 的经验。它的关键设计不是「扫描」，而是把人工验证这一步交给维护者自己决定要不要。背景数据：过去六个月 Anthropic 用最新模型扫世界最重要的软件，发现逾 29,000 个候选漏洞，但人工只能审完约 6,000 个——瓶颈不在发现，在验证。已有近 5,000 份报告是在维护者主动索取后未经人工验证直接发出的。OSS Scanner 就是把这条「快车道」产品化：报告全部由模型生成，不含人工复核，因此可能包含误报。

早期验证：请内部渗透测试专家复核了 48 个项目里的 97 个 critical/high 漏洞，85 个（88%）达到 CVD 标准，11 个是已知问题或重复，仅 1 个是纯误报。披露政策上明确写：这些未验证发现不设 90 天协调披露期——「因为我们自己都还没读，不好要求维护者认真读」。作者投稿渠道极轻：核心维护者提一个 PR，加 projects/<name>/project.yaml（repo、primary_contact、Dockerfile），可选 threat_model.md、PGP 公钥、disabled: true 随时暂停。准入沿用 OSS-Fuzz 口径：只看「对基础设施与用户安全的临界影响」，新项目与普通 fork 通常不收。官网引用的维护者反馈覆盖 PostgreSQL、OpenSSL、wolfSSL（74 份报告 72 份有效、5 个转 CVE）、HotCRP、curl（Daniel Stenberg：「包括近几年最严重的 curl 漏洞之一」）。

核到的实时数据（GitHub API，2026-10-27）：仓库 1,564 stars，Apache-2.0，2026-10-08 创建；已合并入册项目 184 个（含 bitcoin-core、cpython、openssl、openssh、wordpress、grafana、valkey、vlc、airflow、drupal、homebrew、nss、ruby on rails、nextcloud、unsloth、wasmtime、zebra、wolfssl、hotcrp、goose、openclaw 等）；PR 总数 1,128，其中已合并 202、未合并关闭 608、仍在开放 318——按「已合并/已关闭」计算通过率约 25%。10-22 以来新增 PR 199 个，其中 10-23 之后 51 个；10-25 一天内批量合并十余个（含 Bitcoin Core、FrankenPHP、uvicorn、python-multipart、Discourse、FRRouting、Zebra、consensus-specs、go-fiber/contrib、Keystone middleware、gopacket、Calico）。

开源之道视角点评：真正的制度创新在这句话里——「如果你想尽快拿到未经人工复核的报告，自己来申请」。这是把一个典型的外部性成本（误报的时间成本）从提供方移交给申请方，而移交的前提是申请方必须是核心维护者且经人工核实。用 Williamson 的层次说：Anthropic 没有能力改 L2（漏洞披露的法律义务与标准），于是它在 L3（合同）这一层造了一个新契约形式——「未验证即交付」+「随时可 disabled: true 退出」。而在 L4，交付物本身被标准化成 project.yaml + Dockerfile，这意味着接入成本被压到一次 PR 的量级。

但那份 184 / 1,128 的比例更值得记：76% 的申请被挡在门外。被拒的清单本身就是一部「什么算关键基础设施」的判词集——里面有游戏服务器、个人站点、小型 SaaS 的地理缓存。这套筛选是由一个商业公司在无人监督的情况下行使的：谁配得到免费的深度审计，答案现在写在一个私有公司的仓库里。这正是上面那篇论文所说的「验证不对称」的镜像版本：当验证能力集中在极少数主体手里时，即使它免费，分配权也仍然是集中的。

判断：制度健康在短期内是变好的（误报成本内化、比 Google 直接关停 bounty 的处理更精细、退出机制明确），但长期风险在合法性——一个按 OSS-Fuzz 口径筛项目、且筛选结果不公开理由的私有机制，迟早会遇到「凭什么」这一问。要盯的信号：它是否把拒绝理由写进仓库，以及是否有第二个独立的扫描提供方出现（只有一家时，「中性」只能靠自律）。

2. Linux Foundation 调查：项目越大 AI 垃圾占比越高，大项目最担心的已不是代码质量，是维护者烧尽

  • 来源：Help Net Security（Mirko Zorz，2026-10-26）转述 LF Research 调查（234 名开源贡献者与维护者）/ Linux Foundation Research 原始报告（2026-10-20）
  • 链接：helpnetsecurity.com 报道

摘要：234 份样本的 LF 调查给出了比「25% 是 AI 垃圾」这一标题更值得看的分层结果。整体上约四分之一的入站变更是低质量或 AI 生成；但贡献者超过 50 人的项目，维护者估计这个比例接近三分之一。反直觉的部分在这里：大项目并没有因为人多而摊薄负担——它们报告的 AI 垃圾最多、入站提交增长最快、评审拖延的抱怨也最多。担心的事也不一样：小项目仍把代码质量排第一，大项目则把 burnout（维护者烧尽）顶到了第一位。

规则供给严重滞后：约三分之一的项目有正式的「允许 AI 辅助」政策，十分之一明确禁止，其余要么没写、要么还在起草；已有政策的内容高度趋同——要求披露 AI 使用、要求贡献者为自己提交的代码负责。没有规则时维护者的做法很朴素：信任熟面孔、自己读代码，约四分之一完全没有任何检查手段。另一个不对称：四分之三的维护者反过来用 AI 工具来审查入站内容（多为摘要变更、找逻辑 bug）。贡献者侧自述好于预期——六成称逐行阅读并完整测试后才提交，极少有人承认未经检查就发；但约五分之一从不说明用了 AI。效率数据也有边界：用 AI 的人称写码时间大致减半、评审时间减四成以上，但任务越难节省越少——最复杂任务上约五分之一开发者说 AI 反而让他们变慢。

开源之道视角点评：这份调查最锋利的一处，是它证伪了「人多好办事」的直觉。规模本应是分摊成本的方式，结果规模成了放大器——原因不难推：AI 让「产生变更」的边际成本趋近于零，而「判定变更」的边际成本一分没降。在这一对成本失衡下，项目越大，吸引到的产出越多，而判定容量只有那些具名的人。于是「burnout 上升到第一位」不是心理问题，是制度容量被击穿的症状：当判定劳动的供给曲线完全刚性、需求曲线因 AI 而垂直上移时，唯一的出清方式是提高进入门槛（这正是 r/opensource 做的事）或把判定外包给机器（这正是四分之三维护者在做的事）。

还有一条必须记下：内核要求 Assisted-by: 标签的做法，在这份数据里出现了事实上的反转——十分之一项目直接禁，约五分之一贡献者根本不披露，而内核自己在 10 月中旬废掉了 Assisted-by 要求。同一时间点上，「标签」这一路线的支持者在减少，「举证」这一路线（vLLM 的测试证据、Anthropic 的可复现报告）在增加。判断：这是开源治理在 AI 冲击下的一次真实转向——从「披露身份」转向「提交证据」，因为前者可以被廉价伪造，后者需要真的跑一遍。

3. r/opensource 的禁令被主流媒体定名为「连带把人也禁了」

  • 来源：The Register（Carly Page，2026-10-26 17:00 UTC）/ r/opensource 版主公告（2026-10-24）/ Hacker News（90 分、128 评论）
  • 链接：theregister.com 报道

摘要：The Register 用「bans AI slop, and quite a few humans for good measure」给这次事件定了性。新增的可核实细节有四条值得记：①版主之间的分裂首次公开化——同为版主的 ssddanbrown 公开表示自己未被咨询，「我是通过版务通知才知道的」，并直言「我不同意那条规则，尤其是它的表述方式」；②连带后果超出 AI 议题——一位用户指出自己维护了九年、300+ stars、数十个已解决 issue 的项目，仅因是唯一贡献者就不再符合资格；③入门悖论——独立开发者需要先有「既有社区」才能在开源论坛找到社区；④与内核的正面冲突——Linux 内核允许 AI 辅助并要求开发者对结果负责，且本月早些时候取消了 AI 使用披露要求；被问及是否因此内核会被禁时，版主的处理是「会被允许」，说明规则存在未写出的例外。

此外：账号需满一年且有实质贡献；试图发帖后再私信求破例者面临永久封禁与禁言；「不会说英语就另找社区」这一条被 The Register 单列为「最令人侧目的限制」。

开源之道视角点评：这条新闻被主流媒体接手后，观察价值从「社区态度」变成了治理程序的失败样本。三个可检验的治理缺陷：决策未经共同同意（另一位版主不知情）、规则与判例自相矛盾（内核被例外化，说明规则不是从原则推出的，是从情绪推出的）、制裁循环（求破例即永久封禁，把申诉通道关掉了）。奥斯特罗姆的八原则里，这里至少违反了三条：集体选择安排、有效监督、冲突解决机制的层次化。

更值得同情的部分在成本侧：一个 39 万人社区每天收到海量 AI 项目自荐，版务没有能力做判定，只能做身份筛选——「一年 + 三人 + 会英语」不是任何人对开源的定义，它是判定成本高于治理收益时的理性退化。这也是它与 LF 调查的同一条因果链的两端：大项目把 burnout 顶到第一位，社区版主则把门槛顶到最高。同一个冲击，两种逃逸方向。

🔍 Project Pulse：kubernetes/kubernetes —— 一个「人在前面挡着」的项目，健康度不能从数字读出来

项目：kubernetes/kubernetes（Apache-2.0，CNCF 毕业项目）

本次观察切入：10 月中旬到现在，K8s 没有大型治理文件变更（kubernetes/community 的 governance.md 最后一次实质修改是 2023-07-20），但主线提交与 PR 流量是活跃的。今天只追一条线——把「提交活动」与「治理行为」分开看，看看数字到底能证伪什么。

【L1】发布节奏稳定，v1.38 已在 alpha 轨道，主线合并密集 GitHub releases：v1.38.0-alpha.2（2026-10-07）、v1.38.0-alpha.1（2026-09-29）、v1.37.1（2026-09-23），符合 K8s 一贯的「每年三版、补丁跟随」节律，无异常跳票。主线合并侧：10-26 当天仍有实质合并（#143421 watch cache 一致性修复、#143378 DRA tracker 陈旧 slice 设备修复、#142509 CRI API security profile → OCI）。里程碑账目：v1.37 已关闭 1,244 项，v1.38 关闭 893 / 开放 10，v1.39 已开 0 / 开放 2——说明 v1.38 的强化阶段（enhancement freeze 之后）已经走完，工作重心转向 v1.39 的提案收口。判断：典型的「慢聚漫奏」形态——节奏可预测、内容以稳定性修复与 DRA 这类基础设施演化为主，没有为赶版本而放大范围。

【L2】治理层的真实信号是「没有信号」：这正是成熟治理的特征 今天真正核到的 L2 事实是结构稳定到没有新闻：kubernetes/community/governance.md 无近期改动；Steering Committee、SIG 结构未改组；没有项目归属变更、没有 TC 改组、没有基金会层面的 transfer 动作。同时 10-20 至 10-27 期间仓库提交量约 227（按 commits 分页数推算），最近 40 个提交里其中 23 个由 kubernetes-prow[bot] 提交——这是 K8s 特有形态：机器负责落地，人负责判定。真人提交中，Marek Siarkowicz（Google）占 8 席，其余为分散的个人贡献者；按邮箱域名看，google.com 9、gmail.com 7、users.noreply.github.com 24（后者多为 CLI 配置下的个人身份，厂商归属被隐藏）。

这意味着什么：与 vLLM 那种「规则正在被频繁改写」的项目相反，K8s 的制度健康表现为低变动率——治理问题早已内化成 OWNERS 文件、prow 插件和 enhancement KEP 流程，规则本身不再需要每天修订。但低变动率也带来一个观察盲区：当所有判定都被写进自动化工具与 OWNERS 层级之后，外部人很难看出「谁在某个具体方向上真正说了算」——只能看到 bot 在合并。用 Williamson 的层次说：K8s 已经把这套规则沉到 L3/L4 交界处的流程代码里，这让协作变便宜，但也让「议程设定权」变得更不透明（因为它藏在 OWNERS 的评审阈值里，而不是在公开辩论里）。

【L3】新人加入：判断不了，因为身份被 noreply 掩盖 最近一周的 40 个提交样本里，24 个使用 users.noreply.github.com 邮箱——这意味着从提交元数据已经无法判断贡献者的组织归属。这不是 K8s 的问题（是 GitHub 的隐私默认），但它是一个真实的观察障碍：当厂商贡献比例只能靠人名和 Assisted-by 类标签判断时，披露政策一取消，治理研究就失去了一半的数据源。 新人入口侧没有拿到可靠的「本周首次贡献者」数据，不做推测。

【开源之道判断】：K8s 这一周给出的最大方法论教训是——成熟项目的健康度不能从「活动量」读出来，只能从「规则是否仍可被公开挑战」读出来。 vLLM 有一个可以盯的靶子（AGENTS.md 的改动会不会绕过评审），K8s 的靶子更隐蔽（OWNERS 文件的追加是否仍走 sig-review）。制度健康方向上目前是好的：无突发治理变动，发布不赶工，修复在持续。要盯的信号很清楚：如果某一 SIG 的 OWNERS 大量增补来自单一公司的账号而未见邮件列表讨论，那就是 L2 开始漂移的第一处痕迹——这类变动在 K8s 里是允许的、也是静默的，正是 Project Pulse 该做的活儿。

📡 今日新来源发现

  • red.anthropic.com（厂商 Red Team 官方研究站）— OSS Scanner 官方政策文本与 CVD 数据的第一手来源（29,000 候选漏洞 / 6,000 已审、未验证报告不设 90 天窗口）。「AI 供应商进入开源漏洞披露链」这一制度变化的核心档案，且高频更新。建议加入（高置信）
  • github.com/anthropics/oss-scanner（开源项目仓库，治理档案）— 今日分析的核心数据源：184 个入册项目、1,128 PR / 25% 通过率。这是「谁配得到免费深度审计」这一分配机制的可实时复核的唯一档案，比新闻稿可靠。建议加入（高置信）
  • osf.io（OSF Preprints）（开放科学预印本平台）— 今日论文《Open Source as Regulatory Infrastructure》正式版所在，另有 Zenodo 同行评审 DOI。法学/监管研究的主要出口，Zenodo 之外的第二条 OA 通道。建议加入（高置信）

说明：今日三条均为高置信，按规则不自动追加，等待人工 review 后入库。

🔭 后续可检验的观察点

  • OSS Scanner 会不会公开拒绝理由：76% 的挡门率由一个商业公司在无人监督下行使。若拒绝理由始终不进仓库，这套筛选就只是私有判词集，「中性」全靠自律。
  • 有没有第二个独立扫描提供方出现：只有一家时，「免费」不等于「分配权分散」——这正是验证不对称的核心。
  • 欧盟立法会不会把「验证侧开放」写成原则：现在欧盟法只有数字身份钱包一处强制信任关键软件开源。从例外条款到原则，看的是格式规范与验证器是否被写进标准，而不是更多公司表态。
  • 大项目会不会出现「判定基础设施」的公共投入：LF 调查显示 burnout 在大项目排第一，而四分之三维护者已用 AI 反过来审——判定劳动会不会像 CI/OSS-Fuzz 一样被建成公共设施，还是继续由每个项目各自义务承担。
  • r/opensource 的门槛规则会不会被反噬：一年 + 三人的硬门槛如果在一季度内导致高质量新项目外流到 r/TrueOpenSource，说明以「提高进入成本」替代「提高判定精度」的治理，代价是分裂而不是秩序。
  • K8s 是否有 SIG 的 OWNERS 静默增补：单一公司账号大量增补而未走邮件列表讨论，就是 L2 漂移的第一处痕迹——这类变动在 K8s 里是允许的、也是静默的。
  • 误判风险：今日四条判断都可能被单一数据源放大——OSS Scanner 数据来自其自有仓库（准入口径本身未公开）；LF 调查为 234 份自报样本；The Register 转述含版主单方陈述；K8s 提交量与 org 归属按分页与邮箱域名推算。方向性判断是稳的（判定能力被挤兑、验证权集中），但比例数字不宜过度引用。

署名： 「开源之道」·窄廊

🔍 关键项目洞察（Project Pulse · 十一项目并列）

数据口径：lkml、Git 邮件列表取 lore.kernel.org 镜像（lkml 已同步至 2026-10-27 00:00:06 UTC，git 列表至 00:56:54 +0100）；ASF 取 lists.apache.org PonyMail JSON（2026-10，缓存于今日 08:0x）；GitHub 类项目取 API 实时同步（2026-10-27 08:0x CST）。10-27 全天数据尚未产生，以下 lkml/Git 均为 10-26 全天——这与日报正文（03:10 生成、用的是滚动窗口）的切片不同，属正常时差，不是数据打架。

第一部分 · 邮件列表类治理：Kernel 与 Git

项目：Linux Kernel (lkml) 数据范围： 2026-10-26 全天 ｜ 当日邮件量： 3,018 封 ｜ 唯一作者： 684 人

【L1 · 大版本发布】 无 merge window 动静（合并窗口已于 10-11 结束，当前处于 rc 阶段），今日是纯粹的后 rc 修复面：140 个 0/N 系列首帖在飞，版本分布为 v2 23 个、v3 24 个、v4 11 个、v5 4 个、v6 2 个、v7 3 个、v8 2 个，v10 以上仅 2 个。主题集中在驱动修复（net/sm/genest/ath9k、drm/msm/vc4、iio、SATA for NSP SoC）；另有 63 封 [RFC PATCH]，其中一整组 8 封是 x86/fs/resctrl 的非对称 L2 cache 分配——这是「Intel 平台的资源分配策略要变成 ABI」的前哨讨论，不是今天要合并的东西。

【L2 · 治理结构】 域名的头把交椅依旧是 kernel.org 643 封，但里面要拆开看：纯机器人 134 封（netdev-bot+sashiko 50、pr-tracker-bot 25、kernel test robot 18、netdev-bot+sinfo 16、syzbot 13、patchwork-bot+netdevbpf 7、bot+bpf-ci 5），人工 kernel.org 约 509 封。企业侧真正的施力点是 Qualcomm：oss.qualcomm.com 245 封、分布于39 个不同地址，Konrad Dybcio 一人 64 封；Intel 108+60 封、26 个地址；AMD 64、NVIDIA 51、Red Hat 52。这不是「厂商压场」，是厂商在各自 SOC 分支上平行推进，谁都不需要说服谁——因为 review 的责任被分散到各子系统 maintainer 身上。

【L3 · 新人加入与社区活力】 7 日窗口内无新域名（今日脚本对 7 日窗口的 NEW 段返回空，1 日窗口也未列出），3 日窗口内的新域名是 alepacheco.dev、artiphishell.com、asseily.com、deq.rocks——全是个人域名，规模很小。前 20 位作者合计 687 封（含机器人），即 22.7%，长尾极厚——这是 lkml 与 Git 列表在结构上最根本的差别。

📌 开源之道判断 Kernel 今天给出的最重要事实是判定的并行性：39 个 Qualcomm 邮箱、26 个 Intel 邮箱在同一天各自提交驱动修复，没人需要中心裁决——因为子系统的 OWNERS/Maintainer 层已经完成了「判定权下放」。用 Williamson 的话，这是 L3 治理「私有 ordering」做到极致的形态：交易成本被压到只剩邮件的一来一回。但代价藏在数字里：134 封机器邮件里 syzbot 与 kernel test robot 占了 31 封，AI/自动化已经接管了「发现问题」这一环，人只剩下「判定问题成不成立」。这与今日 LF 调查的结论（大项目 burnout 排第一）是同一件事的两面：发现变便宜，判定没变便宜，人力缺口就全部落在 maintainer 身上。

项目：Git (git) 数据范围： 2026-10-26 全天（lore.kernel.org/git）｜ 当日邮件量： 179 封

【L1 · Patch 系列】 在飞的系列不多但都很「基础设施级」：fetch: add remote.<name>.refmap（v10，浅克隆拉全分支的老问题）、repack: 别让中途出现的 .keep 丢对象（v4）、branch: --delete-merged 识别 squash merged（v4）、ci: 构建失败要真失败（v3）。另外16 封 Outreachy 相关（申请人自我介绍 + microproject 修订），说明这个项目的实习生管道是活的、而且是公开在列表上跑的。

【L2 · 治理结构——今日真正的头条】 10-21，Emily Shaffer（Google）提交 [PATCH] Documentation: propose community voting process，新增 100 行的 Documentation/CommunityVoting.adoc。它不是 AI 政策，是「万一共识失败时怎么决策」的程序法——起因写在 commit message 里：九月 Contributor Summit 上，AI 贡献该不该收、怎么收，被认为不可能靠共识解决。这份文档定义三阶段（4 周提案收集 + 2 周投票 + 合并）、提案必须以 patch 形式提交、需另一位合格投票人 Seconded-by: 联署才能上票、投票机制本身还写着 <mechanism TBD>。 真正引发争议的是投票资格：草案写的是「有一个 commit 进了 next，或提供过 2 次以上 code review」，且每人一票、不论资历。Junio 明确反对：「这个门槛太低」，并主张「把规则搞复杂才是危险」，要求「一人一票 + 一条简单的判定规则」。10-24 至 10-26 的讨论转向量化：Peff 用 git shortlog 给出的分布是 44 人 ≥200 commits、133 人 ≥50、439 人 ≥10、2,388 人 ≥1，并给出「总 commit 数 × 近 N 年仍有活动」的交叉表；Patrick Steinhardt 认为 10 太低、倾向 50 配 N=2/3、折中 25–30，理由是门槛定得低会把投票推向新人，定得高会推向被雇来写 Git 的老将；Tuomas Ahola 用 git shortlog -s 的平均值 25.7 作为「看起来挺合理」的锚点；brian m. carlson 关心的是「别让人为了投票去刷低质量 review」。

送信结构补充一个观察：24 小时内 gitster@pobox.com 35 封（19.6%）、ps@pks.im 32 封、gitgitgadget 27 封（15.1%，机器代投），gmail 85 封但个人 AD 极多——这个列表的「人情结构」仍是个人主导，企业邮箱除了 pks.im 几乎不显形。

【L3 · 社区参与结构】 新域名 10 个，其中最值得记的是 atos.ai 与 openai.com（24 小时内 4 封）。OpenAI 出现在 Git 列表上本身不是新闻，但在「是否引入正式投票」这条线程里出现企业邮箱，正是 Patrick 那句「老将们往往是被雇来写 Git 的」的注脚。

📌 开源之道判断 今天最有制度分量的东西不是代码，是Git 正在给自己立宪。一个二十年靠 Junio 的品味 + 列表默契运行的项目，第一次承认存在「共识不可能达成」的议题，并为它准备程序。这是奥斯特罗姆八原则里冲突解决机制层次化的教科书式补课——从「没有投票」到「有投票，且规定谁能投、投几次、怎么计」，中间隔着的正是「谁属于这个共同体」这个最难的边界问题。 更值得记的是争论的走向：没人反对「该投票」，所有人都在争「门槛定在哪」，而门槛的本质是用贡献量代理「利害相关性」。Patrick 说得最坦白：门槛高低就是老将与新人的权力配比。这暴露了 meritocracy 的一个隐痛——当决策从「代码好坏」转向「路线取舍」时，代码量就不再是能力的度量，而变成了股权的度量。Git 现在做的，是自愿给这套股权定一个显式的换算率，而不是继续靠默契。这是它二十年来最大的一次制度自觉，也是最可能翻车的一次：投票机制还是 <mechanism TBD>，门槛还在 10 与 50 之间摇摆，一旦 AI 政策真的上票，「谁算成员」的判词会被永久写进历史。

第二部分 · 基金会治理：Apache Software Foundation

项目：Apache Software Foundation 数据范围： 2026-10 月度（lists.apache.org PonyMail：announce / incubator / kafka / httpd / hadoop）

【L1 · 项目生命周期】 本月 announce@ 共 116 封，其中 CVE 公告 100 封、发布公告仅 4 封——比例是 25:1。更要看分布：这 100 封里有 89 封集中在 10-01 一天（Thrift 61 封，全部发在 10-01 23:45–23:57 的十二分钟内；HTTP Server 20 封，10-01 18:03–18:13 的十分钟内），10-02 七封，10-05 四封。也就是说，ASF 的月度安全公告不是「持续披露」，而是「批量倾倒」。Kafka 侧 VOTE 3 条（KIP-1349 共享组快照频率、4.4.0 RC3、4.3.2 RC0）、DISCUSS 有 KIP-1379（server-side rack-aware assignment 改为 opt-in）与 KIP-1165（Diskless 的对象合并）。

【L2 · 制度治理动态】 孵化器本月冷清：13 封、9 位参与者，唯一实质线程是 [VOTE] Release Apache Fesod (Incubating) 2.1.0-incubating-RC7——RC7，意味着同一版本已经投到第七轮。httpd 24 封，只有 5 位参与者，Eric Covener 一人 17 封（70.8%）。hadoop 本月 0 封。

【L3 · 社区参与结构】 announce 116 封由 10 人发出，Jens Geyer 一人 61 封（52.6%）——说明发布/公告这一层已经高度角色化：少数人被授予「对世界说话」的权限，多数人只在其项目内部活动。kafka 73 封中大量是 [jira] 机器人转发与 GitHub PR 桥接，Chia-Ping Tsai（Jira）10 封居首。

📌 开源之道判断 ASF 与 Kernel 的分野今天看得特别清楚。Kernel 是自发秩序：判定权散在 maintainer 层，谁都能开线程，公共性由大量并联的小决策累加而成。ASF 是委员会治理：一切要过 [VOTE]，而 [VOTE] 的代价是可量化的——一个孵化版本投到 RC7，意味着七轮「差一点」的否决，每轮都要重走绑定投票；hadoop 一个月 0 封，则说明当项目失去活跃贡献者时，PMC 制度不会自动修复它，只会安静地记录它已经不在了。 最刺眼的是 CVE 的批量倾倒：89 封挤在一天、几乎全部来自同一批维护者在十几分钟内发完。这不是安全问题，是制度绩效的展示方式问题——ASF 用「一个月倒了 100 条」证明自己在治理安全，而不是用「平均披露时延」证明。当治理的合法性靠数字密度而非过程质量维持时，公告就越像财报。奥斯特罗姆会说，这是监督机制从「过程可见」退化成「结果可数」。

第三部分 · AI 原生基础设施：AAIF / vLLM / SGLang / Kubernetes

项目：Agentic AI Foundation (AAIF) 数据范围： 2026-10-27（GitHub API + aaif.io 抓取）

【L1 · 项目脉搏】 goose（block/goose）⭐55,779（+333，7 日）、518 open issues、最近 commit 10-26（chore: remove ACP client-delegated developer tools #13144）；agentgateway ⭐5,665、292 open issues（issue/star ≈ 0.05，早期采用者问题密集）；agents.md ⭐25,138、186 issues，最后 push 2026-09-10——而那天提交的两个 commit 是 add Technical Charter 与 Rename agents-md_Charter.pdf to Technical_Charter.pdf。MCP 组织 45 个公开仓库，spec 版本停留在 2026-07-28。

【L2 · 治理动态】 AAIF 今日站点内容全是营销面（工作组成员招募、周边商店「Agents & Standards 卫衣」、活动预告：11-05 旧金山、11-19/20 内罗毕、2027-04-28/29 旧金山、2027-09-15/16 伦敦），没有一条治理文本更新。MCP 侧合规关键词命中 0/10。

【L3 · 社区参与】 mcp.directory 2,303 个 server / 1,907 个 publisher，前十里企业只有 cloudflare(9)、microsoft(8)，全部企业 publisher 占比 15%；中国区 gongrzhe(9)、aliyun(9)。

📌 开源之道判断 agents.md 的状态值得单独立一条：规范仓库在 09-10 提交完 Technical Charter 之后就停了，此后 47 天零 push，而 star 仍在涨（25k）。这不是「维护失能」，更像规范已经交付、治理壳已建好、然后没有人需要它动了——一个文档型标准达到稳态的样子，跟 Kernel 的 governance.md（2023 年后未改）是同一类信号。 但 AAIF 与 Kernel 有一个关键区别必须指出：Kernel 的稳态是判定权已经分散到几百个 maintainer之后的稳态；AAIF 的稳态是判定权还没分散、只是暂时没人争。goose 是 Block 捐出的企业项目、agentgateway 是 LF 系连接器、agents.md 是一份静态规范、MCP 是 Anthropic 起源的协议——四者共享一个基金会，却没有任何一个经历过「被公开挑战规则」的时刻。三方对比：ASF 靠投票制造合法性（代价是 RC7），Kernel 靠分布式 maintainer 制造合法性（代价是 burnout），AAIF 现在靠还没出事维持合法性。MCP spec 自 07-28 未动、合规关键词 0 命中，说明「协议不管合规」的分层设计仍稳——但这也意味着，一旦哪天 EU AI Act 或 CRA 要 MCP 给出审计接口，这套「没人负责合规」的结构会一次性暴露。

项目：vLLM (vllm-project/vllm) 数据范围： 2026-10-27 ｜ ⭐95,624 ｜ 周均 403 commits ｜ 9,504 open issues ｜ 最新 release v0.32.0（10-18），节律稳定为 13 天/版（0.28 08-26 → 0.32 10-18）

【L1 · 发布与提交】 今日提交重心是「为特定模型做适配」：Kimi-K3 的 GB300 AgentX xPyD preset 刷新（含 3P1D DEP16）、Kimi K3 KV-balanced FP8 MLA decode、batch-sharded draft logits（spec decode 采样）、NIXL 升到 1.5.1、llama3_json 工具调用解析器迁到 parser engine。 【L2 · 制度】 PyTorch Foundation 伞下项目，Governing Board + Technical Advisory Council，Meta 主导；vLLM 自身无独立 TSC。 【L3 · 社区结构】 贡献者以创始团队 + 企业（NVIDIA/AMD/云厂）为主，提交信号高度「面向某家芯片/某个新模型」。

📌 开源之道判断 vLLM 今日的提交列表本身就是一份制度证词：几乎每一条 commit 都在为某个具体型号的 GPU 或某个具体新模型做最优化。这在技术上是好事，在制度上是议程设定权的外包——「下一个版本优先支持谁」不由社区辩论决定，由市场发布节奏决定。403 commits/周的速度下，任何治理讨论都会被淹没。这与 SGLang 对照着看才有意思：见下。

项目：SGLang (sgl-project/sglang) 数据范围： 2026-10-27 ｜ ⭐38,215 ｜ 于 6,238 ｜ 最新 v0.5.22（10-19），17 天/版（v0.5.18 08-22 起稳定 13–17 天）

【L1 · 发布】 今日提交同样密集指向硬件适配：AMD 平台 MiniMax-M3 的 SGLANG_MINIMAX_M3_INDEX_TOPK_FREQ 默认值、AMD dsv4 fp8 lm_head GEMM、QSA 长前缀 prefill indexer 优化、spec 在 target 上抓 aux hidden states。 【L2 · 治理】 无基金会、无 Governing Board、无 TSC，Stanford 起源，核心团队主导。 【L3 · 参与】 issue/star 比 vLLM 更高（6,238/38,215 ≈ 0.16 vs 9,504/95,624 ≈ 0.10），说明同等人均下，SGLang 的「没用上的需求」积压更厚。

📌 开源之道判断 vLLM 与 SGLang 今天走的是同一条技术路线（为最新模型做最优 kernel），但制度命运不同：vLLM 已被基金会收编，SGLang 仍是原生社区。基金会收编的实际效果，从数据上看是「多了一层合法性，不多一分判定容量」——vLLM 的 9,504 个 open issue 不会因为挂在 PyTorch Foundation 名下而减少。这提醒一件事：制度不是解决 backlog 的工具，制度是解决冲突的工具。SGLang 至今没建立治理，原因很简单——它还没遇到必须裁决的冲突。要盯的信号不是「何时建 TSC」，而是「第一次出现两家芯片厂商要求互斥的默认行为时，谁裁决」。

项目：Kubernetes (kubernetes/kubernetes) 数据范围： 2026-10-27 ｜ ⭐128,720 ｜ 7 日 commits 100（周均 153）｜ 3,254 open issues ｜ 最新 v1.38.0-alpha.2（10-07）

【L1 · 发布与提交】 10-26 一天内有一条值得记的完整回路：#142743 store-validation-deepcopy 被合并，同日晚间就被 revert（#143448）——从合到撤不到 24 小时。同时段其他合并：#143421 watch cache 一致性、#143394 prune-smp 补丁、#143284 kubelet error metrics、#143378 DRA tracker 陈旧 slice、#142509 CRI API security profile → OCI。 【L2 · 制度基础设施】 kubernetes/enhancements 7 日仅 5 个提交，其中 4 个是 kubernetes-prow[bot] 合并，唯一真人提交是 10-23 Update SIG cluster lifecycle leadership（#6474，Ciprian Hacman）——这是今日 K8s 治理面唯一一条实质 L2 事实：一个 SIG 的 leadership 换届。KEP 侧两个别名修正（#6340/#6341，KEP-1645 clusterproperty 命名与冲突提示）、一个新增（#6457 add Work API KEP）。 【L3 · 社区结构】 合并动作几乎全由 prow bot 落地，真人只负责 /lgtm 与 /approve。域名层面 GitHub 已不给可靠信号（上一轮已确认 24/40 为 users.noreply）。

📌 开源之道判断 今天这条 revert 比任何 KEP 都更能说明 K8s 的制度形态：合并→撤销 24 小时内完成，没有讨论、没有委员会、没有投票。这不是程序失灵，恰好是程序在运转——PR 级的判定已经被 OWNERS + CI + bot 完全自动化，人的角色被压缩到「按下批准」和「发现不对再撤」两下。制度的隐身化到了这一步，外部观察者能看到的只剩 bot 的脚印。 但 SIG leadership 换届这条要专门盯：enhancements 7 天才 5 个提交，其中一个是 SIG Cluster Lifecycle 换领导层，而它由单人提交、bot 合并，没有伴随任何邮件列表讨论的痕迹。这不是违规（SIG 治理本就自治），但这正是昨日 Pulse 预告的那处盲区——当治理写进流程，权力转移可以静默完成。要盯的下一问：这次换届的候选人是如何产生的？SIG 内部有没有可查的提名记录？

第四部分 · 语言与发行版治理：PyTorch / Python / LLVM / Debian

项目：PyTorch (pytorch/pytorch) 数据范围： 2026-10-27 ｜ ⭐105,105 ｜ 周均 353 commits ｜ 17,829 open issues ｜ 最新 v2.14.1（09-30）

【L1】 今日提交以 CI/基础设施为主：[BE][CI] 干掉最后的 Python 3.10、[CI] 在 vLLM CI 里升 uv/pip 修 eMudhra CA、ROCm GPU sleep 标定、[AOTI] 让 test_aoti_inference 能跑 CI 产物、caffe2 的 unreachable break 清理。 【L2 · 制度】 PyTorch Foundation（2023）成员含 Meta/Apple/Amazon/Google/NVIDIA，治理目标是「从 Meta 主导转多方治理」，但实际贡献结构仍以 Meta 工程团队为核心。 【L3】 外部贡献在增长，审查权仍在 Meta 系的模块 owner 手里。

📌 开源之道判断 最值得记的是 PyTorch 的提交里出现了 [CI] Bump uv and pip in vLLM CI for the eMudhra CA fix——一个项目在修另一个项目的 CI。这是跨项目依赖的日常，也是「基金会收编」的实际收益：vLLM 挂在 PyTorch Foundation 下，所以 PyTorch 的 CI 团队顺手就把 vLLM 的构建链一起修了。基金会的价值往往不在治理条款里，而在这类「顺手」里——它把跨项目的交易成本降到了不用开会。反过来看，PyTorch Foundation 的「制度空壳」批评也要修正：壳确实存在，但壳里长出了共享的 CI/发布/合规设施，这层公共品比投票权更实在。

项目：Python (cpython + discuss.python.org) 数据范围： 2026-10-27 ｜ ⭐77,776 ｜ 9,240 open issues ｜ 7 日 commits 100（GitHub Releases 为空，版本走 PSF 发布基础设施）

【L1】 本周最重要的不是代码而是一次多线并发发布：10-26 Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 are out——五个分支同日出补丁。提交侧围绕 free-threaded GC（跟踪运行中的函数对象）、except* 的 BaseException 测试、macOS x86_64 tail-call CI 因 LLVM 超时下线。 【L2 · 制度】 Discourse 侧最热的一条是 Information for Python users regarding eMudhra / emSign CA certificate security incident（10-20 起，37 回复、155,501 次浏览），其次是 PEP 841 相关的 Tuple comprehensions revisited（26 回复）与 Amend PEP440 to limit version identifiers（10 回复）。 【L3 · 包容性】 提交作者名单极度分散（Stan Ulbrych ×2、Pengyu Lee ×2，其余各 1）——没有单一作者超过 20 个提交样本的 10%，这是十一项目里作者分布最平的一个。

📌 开源之道判断 同日给 3.11 到 3.15 五个版本发补丁，只有一种制度能解释：有承诺的维护窗口。Python 的 3.11 早已进入仅安全修复期，仍照发——这是「制度性版本承诺」的硬证据，也是 PEP 制度最容易被低估的部分：PEP 管的是「怎么改」，真正让社区信任的其实是「什么时候不改、什么时候一定修」。 另一条必须记：eMudhra CA 事故一条公告 15.5 万次浏览、37 个回复，远超所有 PEP 讨论。这说明 Python 社区的注意力已经不在语言设计上了——供应链安全成了事实上的第一议题。这与今日日报正文那篇《Open Source as Regulatory Infrastructure》正好接上：能检查证书的人，比能设计语法的人，现在更决定生态的稳定。Steering Council 的议程若不跟上这一迁移，PEP 制度会继续是「高质量但边缘」的讨论。

项目：LLVM (llvm-project) 数据范围： 2026-10-27 ｜ ⭐41,207 ｜ 41,140 open issues（十一项目最高）｜ 最新 llvmorg-23.1.4（10-20），14 天/版稳定

【L1】 今日提交跨子项目并行：[lldb] 断点 callback setter 返回 llvm::Error、[lldb][CMake] 静态库链接顺序、[ci] 新建 monorepo 级 LNT 提交流程（Louis Dionne）、[mlir][math] convert-math-to-funcs 加 set-llvm-linkage、[WebAssembly] GISel pass 的 analysis preservation。[Bazel] Fixes 由 forking-google-bazel-bot[bot] 提交——构建系统这一层已经机器人化。 【L2 · 制度】 LLVM Foundation 2023 年转独立 501(c)(6)，TSC + 维护者委员会，monorepo 把跨项目治理成本压到一次 review。 【L3】 41,140 个 open issue 是今天所有项目里最高的，但它对应的是 100+ 编译器后端子项目，人均积压并不算异常。

📌 开源之道判断 LLVM 的 monorepo 是一个被低估的制度设计：它把「跨项目协调」从会议变成了目录。Clang 要改 IR，MLIR 要改 pass，lldb 要改 CMake——在 monorepo 里这是一次 atomic commit，在 multi-repo 里这是三个项目的三次协商、三套 CI、三个 maintainer 开会。用 Coase 说：monorepo 是用「内部化」替代「市场交易」的经典案例，它买下的正是跨边界交易成本。 但代价今天也露了：[ci] Create a monorepo-wide workflow 这条提交说明 CI 也要跟着 monorepo 化，而 forking-google-bazel-bot 在替所有人修 Bazel——边界内化之后，维护边界的成本也内化了。41,140 个 issue 就是这个成本的价格标签。

项目：Debian (Stable 13) 数据范围： 2026-10（debian.org News / micronews 采集于 10-06）

【L1 · 稳定版发布】 Debian 13.7（trixie）已于 2026-09-23 发布；micronews 近 30 日 20 条，最新条目 09-12。 【L2 · 治理动态】 本期 20 条里 14 条与治理/社区相关，但内容是 DebConf26 视频上线、MiniDebConf Winterthur 总结、CERN 2,200+ 工控与嵌入式系统年底前迁到 Debian——没有 DPL 选举、没有 GR（General Resolution）动向。 【L3 · 参与结构】 20 条 micronews 由 2 人贡献，头部 Jean-Pierre Giraud 19 条（95%）。

📌 开源之道判断 Debian 今天给的是「纯 meritocracy 的静默期」标本：无选举、无 GR、无争议，一切按半年一个 point release 走。而参与数据却很难看——micronews 95% 由一个人写。这不是 Debian 病了，而是志愿制在「对外叙述」这一环的必然萎缩：技术维护有人，讲故事没人。与 ASF 的 announce（10 人、Jens Geyer 占 52.6%）放在一起看，同一种角色化在两个基金会里以不同浓度出现。 CERN 全面迁 Debian 那条才是真信号：当公地项目被关键基础设施采纳，它的稳定性就从「优点」变成「他人业务的前提」——此后 Debian 的每次 x.7 发布都不再只是社区内部事件。

署名： 「开源之道」·窄廊

声明： 本文基于 Linux Kernel Mailing List（lore.kernel.org，2026-10-26 全天 3,018 封）、Git 开发邮件列表（lore.kernel.org/git，2026-10-26 全天 179 封）、Apache lists.apache.org PonyMail JSON（2026-10 月）、aaif.io 与 modelcontextprotocol GitHub org、以及 GitHub API 实时同步（kubernetes/pytorch/vllm/sglang/cpython/llvm-project，2026-10-27 08:0x CST）公开数据，结合适兕开源经济学知识体系分析，仅供参考。所有比例为脚本实测值，未做推测性补全；「治理判断」部分为分析视角，不是定论。