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

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

今日主线可以压成一句：一个社区把「谁能进来」写成了规则，一个项目把「谁在合并」写成了名单。

两条互不相干的消息，指向同一件事——公地的边界正在从「有没有许可证」迁移到「有没有人值班」：

① r/opensource（Reddit 最大的开源讨论区）10-24 发布新规：含 AI 的项目、单人项目、非英语提交一律不收。10-25 一篇《Adjustments will be made》软化了口径，但原帖仍挂着。同日，共同版主 Dan Brown（BookStack 作者）自请卸任，写下这个自治社区最刺骨的一段自白：「这些规则看不出任何版主讨论的痕迹，据我所知是我们无法移除的；而 Wolvereness 是实际上唯一在做版务的人。」

② vLLM 在同一周用一手文件回答了相反的问题：docs/governance/ 下三份文档 + 根目录 AGENTS.md，把谁有合并权、谁拥有哪块代码、agent 贡献怎么算写成可复查的名单——11 名 Project Leads、57 名 Active Committers、18 名 Emeritus、9 个 Area Owner 分组，外加一句硬话：“No one buys their way into governance. Committer status belongs to individuals, not companies.”

一个用收紧规则回应压力，一个用扩大名单回应压力。而两者真正的差别不在规则宽严，在规则背后有没有一张能对上人的表。

📄 最新开源研究论文

今日学术板块全部来自 arXiv 一手（search_papers，date_from=2026-10-23）：宽口径 29 条、治理向 4 条、供应链向 12 条，去重后按议题保留 3 篇。工程向（agent 测试生成、prompt 缓存、TinyML 代码生成等）按惯例不计。

1. 上游修好了，下游四个月后才装上：832 个 CVE 的时间账

  • 标题：A Fine-Grained Empirical Study of Upstream Security Events and Downstream Mitigation in Maven
  • 作者：Kazi Amit Hasan、Enrong Pan、Yuan Tian、Mariam Guizani、Steven H. H. Ding
  • 发表：arXiv:2610.36603（cs.SE），2026-10-27 提交
  • 发现：追踪 Maven 生态 832 个 CVE，把上游事件链（报告 → 修复 → 发版 → NVD 披露）与下游采纳顺序完整还原，区分静默修复与透明修复。核心数据：约 82% 的 CVE 其修复版本早于 NVD 披露；其余 17.9% 的下游项目在披露后「从几天到四个多月」没有可采纳的修复。下游暴露高度集中——前 10% 的 CVE 占 72.1% 的暴露量；1,677 次观测到的采纳中 85.3% 发生在披露之后（静默修复情形升至 88.3%）。用 Dependabot 的采纳，发版到采纳中位 10.4 天；不用的中位 110.6 天——而采纳当时已配置版本更新的，只占总采纳的 8.5%。
  • 开源之道视角：它把「开源供应链安全」从道德问题变成时序与信息问题。刺眼的是那组对照——同一个动作（自动更新），把 110 天压到 10 天，却只有 8.5% 的人在用。10.4 天 vs 110.6 天不是技术差距，是制度采纳差距：工具早就在那儿，人们不用它。诺斯讲制度变迁时反复强调，制度供给与技术供给不是一回事，前者需要有人承担转换成本。另一个细节是那 82%——绝大多数修复在披露前就已存在，只是没人知道。所谓「响应速度」很大程度上不是响应问题，而是信号问题：上游早就补了洞，下游在等一封没人发的通知。

2. 打开 AI 提交的黑箱，能开到什么程度

  • 标题：Agent or Human? Detecting Commits by AI Coding Agents in the Absence of Authorship Signatures
  • 作者：Kosei Horikawa、Hao Li、Yutaro Kashiwa、Youssef Esseddiq Ouatiti、Mohammed Sayagh、Bram Adams、Hajimu Iida、Ahmed E. Hassan
  • 发表：arXiv:2610.36229（cs.SE / cs.AI），2026-10-26 提交
  • 发现：用 1,226 个仓库的 7,837,946 个提交检验去掉署名签名后能否把 agent 提交与人类提交分开。三层结论：①排得开但排不准——ROC AUC 最高 0.859，且大部分信号来自提交信息的冗长度与改动规模，不是代码本身；②放到真实占比下就崩——全测试集上最好的检测器精确率只有 0.332；③跨 agent 迁移极差——TF-IDF 对 Claude Code 的 AUC 只有 0.524（等于抛硬币）。作者结论克制：无签名检测只能给评审排优先级，不能替代记录在案的归属。
  • 开源之道视角：最该被引用的不是 AUC，是 0.332。它意味着在真实比例下，检测器每标出 3 个「这是 AI 提交」，就有 2 个是冤枉的。这正是 r/opensource 新规「如果明显看得出来是 AI，我们就不收」在技术上会遇到的那堵硬墙：肉眼判断没有比「只看冗长程度」的模型更强。而千万级样本量还揭示一个残酷事实：区分 agent 与人的最有效特征，是「话说得多、改得多」——这恰恰是最容易被伪造、也最容易误伤的特征。想收窄入口的社区，手里没有一把能用的尺子。

3. 编码 agent 的隐藏指令栈：你看到的 prompt，不是模型看到的 prompt

  • 标题：Hidden in Plain Sight: an Empirical Study about The Instruction Stacks of Coding Agents
  • 作者：Felipe de Sant’Anna Paixão、Dhyego Tavares、Eduardo Almeida、Iftekhar Ahmed
  • 发表：arXiv:2610.37332（cs.SE），2026-10-27 提交
  • 发现：纵向抓取 1,886 个版本（Claude Code、Codex、Gemini CLI、Qwen Code、OpenCode）首个模型请求中的完整指令栈。工具定义在最新请求中占主导；存在偶发的集中式修改，涉及工具使用、归属（attribution）与编码风格；而只有 48% 的变更单元能直接解释修改动机。作者主张：发布 agent 时应同时公开其指令栈，并保留每次修改的理由。
  • 开源之道视角：它是「AI 贡献无法归属」的上游解释——归属规则本身就是指令栈里被改动的一个变量。当归属不由社区公约决定，而由某家公司在某个版本的 system prompt 里改写，贡献的「行动的定义权」就整体转移了。48% 这个数字是全文分量所在：一半以上的指令栈改动没有可追溯的理由——不是没写，是改动本身就没被记录成可审的对象。开源世界里任何一处行为变更（API、许可证、CONTRIBUTING）都被要求留痕，因为无人可查的变更等于无主授权；编码 agent 作为「贡献者」，其行为规范却处于完全不需要留痕的状态。把它称为贡献者是有代价的——贡献者的前提是其行为可被问责。

📰 开源动态摘要

1. r/opensource 封禁令的两天后：软化、卸任、与一个只做版务的人

  • 来源：r/opensource 原帖 + 后续帖 + Danb 博客 + HN 讨论
  • 链接：原帖（10-24）｜Adjustments（10-25）｜Danb 博客｜HN 50231722
  • 事实：10-24 起要求被推广的项目同时满足：存在满一年且仍在维护、多位贡献者（「主观上 3+」）、有既有社区、OSI 许可证、不像课程作业；明确不收「面向 AI」的项目；发帖账号需满一年且记录可观；「如果你不说英语，请去别的社区」，理由是「我们无法区分 AI 写作与 AI 翻译」。10-25 版主 Wolvereness 发《Adjustments will be made》，给出三条保证——Linux 永远不会被封禁、「两个 Claude Code 会话额度里做出来的宠物项目」不受欢迎、「界线在两者之间，且随时间移动」——但原帖未删。同日，共同版主 /u/ssddanbrown（BookStack 作者）宣布卸任并公开三点：规则出台前没有任何版主讨论；其他版主无法移除这些规则；Wolvereness 是唯一真正在做版务的人。他鼓励分歧者去 fork 社区，并指出已出现多个替代板块（r/OpenSourceAIAllowed、r/TrueOpenSource、r/ActualOpenSource 等）。
  • 开源之道视角：这次收紧既是判定成本问题，也是人力问题，而且后者是前者的因。Dan Brown 那句「他是唯一在做版务的人」，把整件事从意识形态之争还原成一个人一天只能看这么多帖。于是出现了一个开源治理里极经典的失效组合——规则由单人制定，执行由单人承担，纠错没有通道。奥斯特罗姆八原则里这里至少缺两条：集体选择安排与冲突解决机制。而 Brown 给出的建议恰好是第八原则——不要在这套规则里争，去 fork。这大概是今天最耐人寻味的一句：当一个公地的治理失灵，最开源的回应不是修正它的规则，是在旁边再开一块地。 代价也说清楚了：注意力的公共池被切小，两边的版务人力都更薄。

2. Show HN 174 分的「开源 Claude 替代品」：3 个贡献者、311 个提交

  • 来源：Hacker News（50246238，174 分 / 43 评论）+ GitHub 一手核实
  • 链接：HN｜FrigadeHQ/hob
  • 事实：Frigade（YC 背景 SaaS 公司）10-14 建仓、10-26 上 HN 的项目 Hob：MIT、本地运行开放权重模型（Gemma / gpt-oss）、跨平台、主打「免费·私密·离线」。首页写"Backed by Y Combinator"，导流回 frigade.com。仓库一手数据（10-30 复核）：365 ★ / 31 fork / 创建 15 天；贡献者共 3 人（christianmat 188 次提交、brownrout 17 次、itschaindev 1 次）；近 100 个提交中 agent 署名痕迹 1 条；根目录无 GOVERNANCE / MAINTAINERS，有 CONTRIBUTING.md；10-28 一天连发 0.2.3 / 0.2.4 / 0.2.5 三个版本。
  • 开源之道视角：把它当成 r/opensource 新规的反面测试样本很有用：这个项目如果去 r/opensource 发帖会被新规挡下（成立 15 天 < 1 年、贡献者 3 人处于「主观 3+」的边界、由公司主导）。但它同时是当前「开放权重 + 本地推理」浪潮里最典型的产物形态：公司拿开源当分发渠道，用 MIT + 本地化当卖点，用 HN 首发换冷启动。这不是道德问题，是开源作为营销基础设施的又一次正常使用——问题在于它和「公地」没有关系：一个人写 188 个提交、15 天冲 365 星、三个版本一天发完，这不是社区在长，是产品在发。真正值得盯的不是它现在多小，而是三个月后它的 CONTRIBUTING 通道有没有被用过——如果没有，它就从「公司开源的产品」变成了「公司开源的源码」，两件事在许可证上完全一样，在制度上完全不同。

3. 补记：vLLM 的 AGENTS.md 把所有 agent 贡献者写进了一条会封号的规则

  • 来源：vLLM 仓库一手文件（/AGENTS.md、/docs/governance/*.md）
  • 链接：AGENTS.md｜process.md
  • 事实：规范开头就是硬句：“These instructions apply to all AI-assisted contributions. Breaching these guidelines can result in automatic banning.” 具体条款：纯 code-agent 提交不允许（须有能端到端理解并为改动辩护的人类提交者）；低价值琐碎 PR 不允许（单个错字、孤立风格改动、一个可变默认值；机械式清理只能打包在实质改动里）；重复工作检查给出可直接执行的 gh 命令；用户可见变更须在同一 PR 内更新渲染文档；「fail-closed」条款——「如果工作是重复/琐碎的忙碌活，就不要继续，返回一段简短说明缺什么」。
  • 开源之道视角：这是目前看到的最完整的一份agent 时代的贡献契约。值得学的地方不在严格，在可执行：道德语言（「披露、测试、mentorship」）换成了能跑的命令和能触发的后果。特别是 fail-closed——它把「不要提交垃圾」从一个道德要求变成一个有默认行为的规则：默认不是提交，是返回说明。默认值就是制度，这一条比一百条 CONTRIBUTING 里的「请保持高质量」更硬。

🔍 Project Pulse：vLLM —— 把「谁在合并」写成名单的项目

项目：vllm-project/vllm（95,854 ★，Linux Foundation 托管） 切入：周二的论点是「基金会接收项目转移的是所有权，不是值班表」。今天换一个方向验证同一命题——找一个把值班表公开写出来的项目，看它长什么样。

【L1 · 发布节奏】一台 12 天周期的机器，没有假期 GitHub Releases 一手数据：v0.28.0（08-26）→ v0.29.0（09-09）→ v0.30.0（09-22）→ v0.31.0（10-05）→ v0.32.0（10-18），间隔稳定在 12–14 天。最新提交在 10-29T18:32Z。发布节奏稳定到这种程度，通常意味着背后有一个按周排班的核心组，而不是「谁有空谁发」。

【L2 · 治理层】57 人在编、18 人退休、9 个领域分组，而且名单是活的

  • 11 名 Project Leads（其中 5 人组成 Lead Maintainers），文档明确写这个委员会即 Linux Foundation 项目治理定义的技术指导委员会（TSC），每周开会；
  • 57 名 Active Committers，每人标注主责领域（如 @njhill：分布式/API server/引擎核心；@pavanimajety：NVIDIA GPU 集成；@hongxiayang：AMD GPU / ROCm）；
  • 18 名 Emeritus Committers——这是全文最重要的一栏。名单里有 @russellb（Anyscale）、@patrickvonplaten（Hugging Face）、@pcmoritz（Ray）等知名名字，标注「曾大量贡献但已不活跃，谢谢」。一个项目愿意公开「谁已经不是 committer」，说明它真在维护这张表，而不是把它当荣誉墙。
  • 9 个 Area Owner 分组（Engine Core / Model Implementations / Entrypoints / Features / Code Base / External Kernels / Integrations / Hardware / Ecosystem），细到 Scheduler 归谁、KV Connector 归谁；
  • 硬话一条：“No one buys their way into governance. Committer status belongs to individuals, not companies.”

再看实际谁在按合并键（GraphQL 一手，近 60 个已合并 PR）：khluu 7、DarkLight1337 6、wzhao18 5、orozery 5、vllm-bot 4、hmellor 4、gau-nernst 4、WoosukKwon 3——没有一个账号超过 12%。对照 10-29 记录的 Agent Skills（83 个已合并 PR 的 merged_by 全为 null、近 100 个提交中 83 个来自一人），这是两种完全不同的治理形态：一个合并权高度分散且有明确名单，一个合并权不可追溯。

【L3 · 新人通道】宽进，但有硬闸 开放侧：open PR 6,864 个、open issue 2,718 个（10-30 复核）——入口宽到积压本身就是问题。窄出侧：committer 提名须由任一现役 committer 发私信列表提名，附 PR/评审/RFC/基准/采用证据，共识决定，争议时由 Lead Maintainers 裁决，同时考核「持续、高质量的贡献」与「对设计哲学的契合」。agent 侧的门槛不在「人」而在流程：纯 agent PR 不允许、琐碎 PR 不允许、重复工作必须先跑三条 gh 命令自查、违规可自动封号。 这意味着什么：vLLM 没把「谁能进来」当成需要严防的口子，而是把**「什么算贡献」**定义得极细。这是和 r/opensource 完全相反的方向选择——r/opensource 说「我们判断不了，所以收窄」；vLLM 说「我们定义得够细，所以能判」。代价也真实：6,864 个 open PR 就是这套精细规则自己生成的账。

开源之道判断：这个项目的制度健康在变好，但改善方式是「加固判定标准」而非「扩大参与面」。三条可复核的观察点：

  1. 下一版 committers.md 的 diff（轮次、新增、转入 Emeritus 的人数）——只进不出，名单就退化成荣誉墙；目前 Emeritus 有 18 人，说明还没退化。
  2. 合并权的分散度是否维持——若某账号占比持续超过 20%，说明在向「单点值班」滑。
  3. 6,864 这个数字的走向——若继续上升而 committer 数不变，则精细规则的边际成本开始超过收益，下一步大概率不是放宽规则而是提高合并速率（自动化），那才是真正的 L3 变化。

桥接：用威廉姆森的层次看，vLLM 做的是把 L3（治理机制）写得足够细，以换取 L4（资源配置）的吞吐——每一条 AGENTS.md 条款都在降低单次评审的交易成本。而 r/opensource 做的是在 L2 层直接设边界（谁能算社区成员）。同一周、同一种压力（AI 让进来的人变多），一个选择加固 L3，一个选择收紧 L2。层次选错了，成本就会转移到最贵的地方：改规则是一句话，长出一个能执行规则的人要几年。

🔭 后续可检验的观察点

  1. r/opensource 的「Adjustments」承诺是否落地成文字（复核 r/opensource/about/rules 与置顶帖）——若两周内规则文本仍未修改，则「回应反馈」只是回应，不是修正。另观察替代板块的实际活跃度，因为 fork 社区的成本最终体现在两边人都不够。
  2. Agent Skills 的对照项仍在计时（承接 10-29）：agentskills/agentskills 今日复核仍为默认分支停在 2026-08-09、无 GOVERNANCE.md / MAINTAINERS.md、57 个 open PR 未动；同基金会 modelcontextprotocol/modelcontextprotocol 今日提交在 10-29T18:27Z、有 GOVERNANCE.md 与 MAINTAINERS.md、50 个 open PR。同一天、同一基金会、同一份新闻稿下的两种状态，已连续两天成立。
  3. vLLM 的 Emeritus 转出人数（下一次 committers.md 变更时的 diff）——这是「名单是否还在维护」最便宜的温度计。
  4. Dependabot 式的「制度已就绪但未被采用」是否会在别的领域重现（承接今日论文 1 的 8.5%）——SBOM、release attestation、AI 贡献披露标签，都可以用同一个口径量：有多少项目早已具备能力却没打开开关。

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

声明： 本文基于公开信息检索（arXiv、Hacker News、Linux Foundation、GitHub API / GraphQL、Reddit 原帖与当事人博客等公开来源），结合开源经济学知识体系分析，仅供参考。学术引用已追溯至原始论文；所有仓库层面的数字（提交日期、贡献者数量、merged_by 分布、文件清单、open PR 计数）均于 2026-10-30 经 GitHub API / GraphQL 一手复核。「治理判断」部分为分析视角，不是定论。