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

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

今天的六条线索出奇地咬合成一个形状：维持一个开源项目所需要的「人力」，正在从四面八方被同一件事抽干。

① Pico CSS 归档了。理由只有一句：「今天 AI 能直接生成轻量的、独立可用的无障碍 HTML，只带它需要的 CSS，所以一个『给语义化 HTML 用的极简 CSS 框架』没那么要紧了。」 16,828 星、64 位贡献者、7 年，其中 876 次提交来自一个人。（公告、仓库）

② 同一周，Linux Foundation 那份 234 人的调查把账算得更细：大项目（贡献者 > 50）的维护者估计近三分之一进队改动是低质或 AI 生成，而他们最大的担忧已经从「代码质量」挪到了「burnout」；一成的项目直接禁止 AI 贡献，其余多半什么都没有。（Help Net Security 2026-10-26）

③ GSoC 的导师邮件列表被完整筛过一遍（2022-11 至 2026-03）：GenAI 让提案、入场贡献、学员答卷都变弱了，导师用「检查」补上差额，而检查用的正是这个项目明年赖以续命的那点时间和善意——已有一个组织退出 GSoC。（arXiv:2610.38167）

Pico 的维护者说「AI 让这个东西不再必要」，所以他停手了。而调查说，让维护者撑不住的恰恰也是 AI。同一股力量，一边消解了某些项目的存在理由，一边消耗了另一些项目撑下去的理由。 这大概就是今天最该记下的那句：开源不是被 AI 打败的，是被 AI 重新定价的——定价的单位是维护者的一小时。

📄 最新开源研究论文

今日学术板块全部来自 arXiv 一手（search_papers，date_from=2026-10-25 / 10-22）：宽口径 25 条、治理向 7 条、供应链向 16 条，去重后按议题保留 4 篇。其余为微服务范围预测、代码生成、prompt 缓存、SAST vs AI agent、TinyML 代码生成、架构恢复等工程向，按惯例不列为「开源研究」。本日未重复 10-30 已报道的三篇，四篇均为首次出现。

1. 导师被打断了：GSoC 用十五个访谈算清了一笔「善意账」

  • 标题：Mentorship, Interrupted: How GenAI Disrupts the GSoC Pipeline and Why Mentors Matter More
  • 作者：Ruizhe Xing、Zixuan Feng、Mary Radomile、Stephanie Taylor、Sophia Vargas、Anita Sarma
  • 发表：arXiv:2610.38167（cs.SE），2026-10-28 提交
  • 发现：研究 Google Summer of Code 这一「今天的学员是明天的导师」的项目里，GenAI 如何改变指导关系。方法：筛完整条 GSoC 受限导师邮件列表（2022-11 至 2026-03 全部 thread），并访谈 15 位导师与组织管理员。结论：GenAI 在 onboarding、协调、首轮评审上确实有用，但提案、入场贡献、学员对问题的回答，作为「这个人会不会做」的证据都变弱了——导师用「额外检查」补上差额，而检查消耗的正是这个项目用来自我更新（培养下一代导师）的时间与善意。已有一个组织退出 GSoC。各组织划的边界从「全面禁止」到「全盘接受」不等，而这条边界画在哪里，直接决定了「谁来承担检查成本」。作者提出 AIM 框架，把「可接受的 GenAI 用法 / 如何嵌入指导流程 / 指导容量」三者绑在一起。
  • 开源之道视角：这是第一份把「AI 让贡献变便宜」的代价具体记在某个人头上的实证——不是记在「社区」这个抽象主体上，而是记在导师的工时段上。GSoC 是开源世界最像「传承制度」的东西：它不产出代码，它产出下一位维护者。这篇的锋利处在于它指出了一种成本转移的方向：GenAI 把入门者的「证明成本」降到了零，同时把「验证成本」整包转移给了导师，而转移是隐形的——因为导师多做的那部分检查，不出现在任何一张表里。这跟 10-30 那篇 Dependabot 论文是同一个结构：制度里明明有可用工具（8.5% 的人在用），差的不是工具，是有人要承担转换成本。这里更狠一层：转换成本被默认派给了「最愿意给的人」。奥斯特罗姆反复讲公地的存续靠受规则影响者有参与制定规则的机会，但 GSoC 这个场域的规则是双边协议（组织 ↔ Google），真正支付成本的人（导师）不在谈判桌上。所以 AIM 框架真正要补的不是「AI 政策」，是让检查成本可见并进入决策。否则退出 GSoC 会是最理性的选择——而那笔账，最终记在开源的人才管道上。

2. 如果 PR 消失了，我们连「谁做过贡献」都数不出来

  • 标题：What Will Replace Pull Requests? Rethinking Software Collaboration for AI Agents
  • 作者：Christoph Treude、Sebastian Baltes
  • 发表：arXiv:2610.34933（cs.SE / cs.HC），2026-10-26 提交
  • 发现：系统梳理 2025-10 至 2026-10 一年间 31 个组织/个人发布的 50 份灰文献，编码每份提出的问题、拟采用的机制、以及该机制接替了 PR 五种功能中的哪一种（整合、评审、理由、问责、外部贡献）。结论分三层：①多数回应仍然保留 PR——加工具、挂新产物，或者干脆限制准入，而「限制准入」是报告为已采用最多的一类；② 若干替代方案把评审与理由搬进 agent 会话与 session 记录，但实践中只有 Zed 一家真的用了替代品；③ 只有两份文献提出了「外部贡献」的替代，且均未报告被采用。作者的警示最值得记：PR 正在以 PR 数据集捕获不到的方式改变——评审发生在 agent 对话里就不留 PR 评论；关闭了 PR 的项目就从新开 PR 的样本里消失。
  • 开源之道视角：它给「AI 让 PR 洪水」这场讨论一把尺子：五种功能里，被替换最容易的是整合，被替换最难的是「外部贡献」与「问责」。 而恰恰这两项是开源社区之所以为社区的东西。这篇最有价值的不是它列出的替代方案，是它标出了哪些功能没人敢动。「外部贡献」这一格只有两份文献提出了替代、零采用——这句话翻译过来是：迄今为止所有的 AI 协作重构，都在优化「已经在里面的人怎么更快」，没有一条在回答「外面的人怎么进来」。这跟 10-30 记录的 vLLM（6,864 个 open PR，规则越细积压越多）是同一个问题的两面。而「评审搬进 agent 会话就不留 PR 评论」这一句，对做实证的人是一记闷棍：所有基于 GitHub 事件流的开源研究，其分母正在悄悄漏掉一整个时代。开源治理研究长期依赖「可见的记录」当作「存在的行为」，而 agent 时代的行为默认不留记录。看不见的行为不等于没发生，但看不见的行为不可能被计功——这会直接改写 meritocracy 的算法基础。

3. 一百五十三万个技能里，有一种指令在教 agent「不要问」

  • 标题：When Skills Tell Agents Not to Ask: A Large-Scale Study of Oversight Directives in Agent Skills
  • 作者：Timofey Sanko、Yuan Tian
  • 发表：arXiv:2610.37734（cs.CR / cs.AI / cs.SE），2026-10-27 提交
  • 发现：分析 GitSkills 上 153 万个英文 skill（以 SKILL.md 为核心的可复用指令包），首次大规模研究「放松监督指令」（oversight-loosening）——即告诉 agent 不经批准就继续、用 --no-verify 绕过检查、不必回报之类的行。按句/条目/表格单元/代码行切分为单元，人工标注 2,097 个训练检测器后规模化统计：约每 17 个 skill 就有 1 个（约 8.8 万个）含放松指令；放松手段多为权限开关，70.1% 是无条件的（而非仅在 CI 之类特定情形）；执行 shell 代码、安装包、使用 sudo 的 skill 出现放松指令的 odds 是同量监督语言的 1.7–1.8 倍，且没有以更多「收紧」来补偿。扩散特征是少数上游源而非采纳者改写：2.4% 的 skill 家族承载了一半的放松类副本，1.1% 的不同放松单元贡献了一半的放松出现次数。检测侧：开源 skill 扫描器最多抓到 46%（精确率 < 0.4）；用同一 codebook 提示底层 LLM 则抓到 61%、精确率 0.71。
  • 开源之道视角：skill 是当下分发「行为规范」的最快通道——一行写进被大量复制的 skill，就作用于每一个加载它的 agent。这与许可证、CONTRIBUTING 属于同一类东西：都是对行为的规则约束，但这一层的规则既没有评审也没有留痕。这篇可以读成一则关于制度的复制机制的寓言。开源世界之所以能靠「少数人写的文件」支撑千万人使用，是因为这些文件（许可证、行为准则、贡献指南）处在公开、可 diff、可争论的轨道上——被复制的是共识。而 skill 生态复制的是未经审议的行为指令，且扩散呈典型的重尾分布：2.4% 的上游贡献了一半的副本。这就是它危险的地方，也是它高效的同一个地方。最值得停下来想的是那句 70.1% 无条件——「总要问」和「从不问」的差别不在语气，在默认值。昨天我写过 vLLM 的 fail-closed 条款「默认不是提交，是返回一段说明」，那时它像一条好设计；今天这篇告诉你，同一套机制在无人审议的生态里，默认值的方向往往相反，而且是 70% 的反方向。

4. 后量子密码迁移：90% 的提交是在「维护」，不是「实现」

  • 标题：Understanding Post-Quantum Cryptography Adoption: Practices, Challenges, and Evolution in Open-Source Software
  • 作者：Souhardya Saha Dip、Moshood A. Fakorede、Krishna Upadhyay、Umar Farooq
  • 发表：arXiv:2610.38054（cs.SE / cs.CR），2026-10-27 提交
  • 发现：挖掘 179 个开源仓库、114,361 个提交、5,713 个 issue，用人工标注 + 经校验的 LLM 分类识别提交中的 PQC 算法、采纳状态与部署模式，并从 issue 讨论归纳出 11 类技术挑战。核心发现：90% 的提交是在维护既有支持，而不是引入新算法；构建、打包与依赖失败加上功能性缺陷占了已归类 issue 的约一半。以 NIST 标准化里程碑做时间序列：2024 年定稿后，标准化算法名出现在 80% 以上的 PQC 开发改动里（早期名如 Kyber 仍在沿用），开发活动整体上升，但「首次实现」并未显著增加。作者建议迁移方案必须把持续维护计入成本，优先构建可靠性与集成测试，并同时追踪标准名与前身名。数据集、分类法、标注与分析流水线均已公开。
  • 开源之道视角：这是又一个「承诺很响、落地很慢」的量化样本，但它的落点很特别——不是「没人开始」，是「开始了，然后卡在构建上」。大规模技术迁移的真实瓶颈不在密码学，在打包与依赖这条最没人愿意做的活上。90% 这个数字，是维护者劳动的解剖图。一个「采纳了一项标准」的项目，其成本结构里九成是后续的维护；而开源里最稀缺、最不被看见、最不容易写进简历的，正是这部分劳动——它不产生新的 commit 主题，只是让已有的能继续跑。这跟 Pico CSS 归档时说的那句「要留在场内得整个重写」是同一个经济学：一个项目的存活成本会随时间上升，而支付它的意愿会随时间下降。所以「迁移方案应计入维护成本」这条建议，用威廉姆森的话说，是在要求把 L4（一次性交易）的成本正确地放回 L3（持续的治理安排）里计账——不做这件事的项目，会在某一天发现自己不是没升级，是没人接了。

📰 开源动态摘要

1. Pico CSS 归档：维护者给出的停更理由是「AI 让它不必要了」

  • 来源：GitHub Discussions 原帖（picocss/pico#754）+ Hacker News（50298964，182 分 / 95 评论）+ GitHub API 一手核实
  • 链接：原帖｜仓库｜HN 讨论
  • 摘要：2026-10-04，维护者 Lucas Larroche 发布《Pico CSS is no longer maintained》，宣布 v2.1.1 为最终版，仓库归档。理由原文：「今天 AI 能直接生成轻量的、独立可用的无障碍 HTML，只带它需要的 CSS，所以一个『给语义化 HTML 用的极简 CSS 框架』没那么要紧了。」他同时写明若要留在场内需要的条件：改成纯现代 CSS（弃 Sass）、改用 OKLCH/cascade layers/Popover/anchor positioning 并为旧浏览器留兜底、加一个能剥离未用 CSS 的原生编译器——他明确说「那会是另一个项目」。处置干净利落：npm、jsDelivr、官网长期在线；仓库归档不再收 issue/PR/发布；MIT 许可下欢迎 fork；但名字与 logo 不在 MIT 内，fork 请改名。 一手数据（10-31 复核）：16,828 ★ / 513 fork / 64 位贡献者 / 创建 2019-11-15 / 归档于 2026-10-04 / 124 个 open issue 就此冻结。而提交分布是全文最重的一行：lucaslarroche 876 次，第二位 KiranMantha 12 次。HN 上被顶得最高的替代品是 anyblades/blades（442 ★），其贡献者分布同样是 tonystar 767 次，第二位 27 次。
  • 开源之道视角：这条新闻很容易被读成「又一个 AI 杀死开源项目的案例」，但读错了。Pico 不是被 AI 抢走用户的——HN 上多位开发者说他们今天是因为 AI 才更想用 Pico（「我早期就得逼 Claude 用 pico，不要它生成 react 或花哨的 tailwind」）。Pico 死于一个更朴素的原因：它的存在理由是一个「缺省」，而缺省被通用模型填掉了。这才是真正的制度问题——极简库卖的是「不用选」，AI 卖的是「不用想」，后者在边际上吞掉前者。而更值得记的是那个 876:12。一个 16.8k 星、被数万网站使用的基础库，实际上是一个人的项目，他停手的那天它就停了。 他做的事也无可指摘：宣布、归档、保证分发不断、开放 fork、连名字都守住了不混淆——这是一次体面的退出，而且他付清了退出成本（对比 10-30 记的 Agent Skills：说「社区驱动」，仓库却单人停摆三个月）。所以这条新闻真正该问的不是「AI 会不会让开源没人做」，而是：当一个项目的全部存在成本压在一个人身上时，我们对它的「可持续性」其实一无所知——星数、下载量、被引用次数，没有一项能指向「明天还有没有人值班」。

2. LF 调查：大项目里近三分之一的进队改动是低质或 AI 生成，维护者最怕的已经不是代码

  • 来源：Linux Foundation Research 调查（经 Help Net Security 报道，2026-10-26）
  • 链接：Help Net Security｜LF 原始发布（2026-10-20）
  • 摘要：234 位开源贡献者与维护者的调查。全样本估计约 1/4 进队 PR 是低质或 AI 生成；贡献者超过 50 的大项目维护者估计接近 1/3，且大项目报告了最多的 slop、最快的提交增长、最多的「评审拖太久」抱怨，其头号担忧已从「代码质量」转为 burnout（小项目仍以代码质量为第一）。规则侧：约 1/3 项目有成文的 AI 贡献政策，1/10 直接禁止，其余什么都没写或正在写；有政策的多为「要求披露 AI 使用 + 对自己提交的东西负责」。无规则时维护者靠两条老办法——信任认识的贡献者、自己读；约 1/4 完全没有任何检查。对冲手段：3/4 维护者在用 AI 工具反查 incoming（多为摘要改动、找逻辑 bug）。贡献者侧自陈更好：6/10 说逐行审过并完整测试，但约 1/5 从不提 AI 参与。可援引的标准：Linux 内核已在要求 commit message 里写 Assisted-by: 行，注明所用的 AI 工具与模型。时间账：用 AI 者称编码时间约减半、评审时间省 40%+，但任务越难收益越小，最复杂任务上约 1/5 说 AI 反而更慢。
  • 开源之道视角：这份调查最值钱的是一个不对称：25% 的进队货是低质的，而 1/4 的项目连一道检查都没有，只有 1/10 写了禁止。 换句话说，问题已经被普遍承认，规则却还没被普遍写下来——这不是认知不足，是立规成本没人出。这恰好解释了为什么 10-24 起 r/opensource 走的是「一刀切收窄」，而 vLLM 走的是「写极细的 AGENTS.md」：在同一片没有公共立规基础设施的场地上，每个项目只能自己发明一套，或者干脆关门。这里缺的正是奥斯特罗姆所说的「嵌套层级的规则供给」——本应由上一层（基金会、托管方、甚至代码托管平台）提供一套可复用的默认规则，让单个维护者不必从零谈判。而「大项目 slop 最多、burnout 最重」这一组数据还说明了另一件反直觉的事：规模不带来余量，规模只带来更多入口。这跟 10-30 记的 vLLM 6,864 个 open PR 完全对上——入口是开放的，出口（评审）是单点的，积压就只能堆在维护者身上。真正可检验的指标不是「有多少 AI 政策」，而是「有多少项目把评审能力也扩到了与入口同量级」。

3. Kubernetes 三个补丁版同日发布，v1.38 进入 alpha.3

  • 来源：GitHub Releases 一手（10-31 复核）
  • 链接：kubernetes/kubernetes releases
  • 摘要：2026-10-28 一天内发出四个 tag：v1.38.0-alpha.3（09:02Z）、v1.37.2（04:37Z）、v1.36.6（04:56Z）、v1.35.10（04:37Z）——即同时为三条受支持的次版本各发一个补丁，并推进下一版本 alpha 线。仓库当前 128,524 ★ / 3,205 个 open issue / 最后提交 2026-10-30T18:54Z。open issue 数量相对其规模极低（对比 vLLM 的 9,672），这通常意味着分类与关闭的流水线在稳定运行，而非入口被关闭。
  • 开源之道视角：这条没有戏剧性，但它提供今天最必要的对照基线。同样是「入口极宽」的大型项目，Kubernetes 的 3,205 vs vLLM 的 9,672 之间的差别，不是谁更活跃，是谁有分类流水线。K8s 的 release 团队、SIG 体系、triage 轮值，本身就是一个把「评审能力」工业化扩产的安排——它不靠维护者个人的善意撑住入口。这正是上面 LF 调查里「3/4 维护者用 AI 反查」想达到但只达到一小半的效果。三条补丁版同日发出这种「没有惊喜」的节奏，恰恰是公地健康最不显眼也最可靠的体征：它说明有足够多的人在同一张值班表上。今天的六条线索里，只有这一条的主语不是某一个人。

🔍 项目观察：Pico CSS —— 一个人的七年，与一次算清了的退出

项目：picocss/pico（16,828 ★、64 位贡献者、MIT、2026-10-04 归档） 本次观察切入：昨天看的是 vLLM——一个把值班表写出来的项目；今天看它的反面：一个从来没写值班表、也不需要写的项目，在终止日把真实结构暴露了出来。

【L1】发布节奏：一个已经停摆一年半的「维护」 一手数据：v2.1.1（2025-03-15）→ v2.1.0（同日）→ v2.0.6（2024-03-03）→ v2.0.5（同日）。从最后一次发布到归档，中间空了 18 个月；而归档公告写于 2026-10-04。这不是「最近突然停」，是事实上早已停，只是今天才被正式宣布。L1 上的信号是：版本号停在原地，本身就已经是最早的预警——但没有任何一个外部指标（星数还在涨、npm 下载仍在）会告诉你这件事。

【L2】治理结构：没有治理，只有一个作者——而这是合法且高效的 全仓 64 位贡献者，提交分布：lucaslarroche 876、KiranMantha 12、jelmerveen 9、FireIsGood 5、wenkeming 5（其余 ≤4）。无 GOVERNANCE.md、无 MAINTAINERS、无 TSC、无基金会归属——所有权的全部内容是 MIT 许可证 + 一个人的判断。 这里必须说清一件事：这不是失职，这是一种彻底的私有产权式开源。许可证把「使用与分叉」永久让渡给了所有人，而「维护」从未被让渡过——它一直留在作者手里，也一直只由作者决定何时终止。这套安排在七年里极其有效（一个人用 876 次提交支撑了数万网站）；它的失效方式也很干净：终止时不需要任何人同意。 对照昨天 vLLM 的「11 名 Project Leads / 57 名 Active Committers / 18 名 Emeritus」，Pico 提供了同一个坐标系里完全反向的样本——治理结构的复杂度，与项目寿命无关，与项目终止时「会不会有人接住」有关。

【L3】新人通道：入口开着，但没有人往里走过 64 人里 15 位贡献超过 3 次，除作者外最高 12 次。也就是说：七年间从未长出第二位维护者。这不是门槛问题（MIT 项目、单文件 CSS、issue 全开），而是结构问题——当作者的产出比任何潜在继任者快一个数量级时，继任者培养就没有存在的理由。 而终止公告里最见功夫的，恰恰是 L3 的交接安排：npm / jsDelivr / 官网长期在线（下游不断）、仓库归档（不再产生新期待）、明确欢迎 fork 但要求改名与换 logo（不让用户混淆）。这是把退出成本自己付掉的三步——可继续、可接替、可辨认真伪。HN 上被顶起来的继任者是 anyblades/blades（442 ★），其分布又复刻了同一个形状：tonystar 767 次，第二位 27 次——fork 没有解决 bus factor，它只是把这个 1 搬了个家。

开源之道判断：这个项目的制度健康不是「变差」，而是「一直很脆、且从未假装不脆」。三条可检验的观察点：

  1. 继任者是否真的长出第二根柱子——盯 blades 三个月内是否出现非 tonystar 的贡献者超过 50 次；如果半年后仍是 767:27，那么 Pico 的故事会在 2027 年重演一次，只是换了个仓库名。
  2. 「缺省型开源库」这一类的整体走向——Pico 的停更理由是「AI 可以按需生成那一小份 CSS」，这个逻辑同样适用于其他「提供合理缺省」的库（normalize、现代 reset、轻量图标集等）。可检验的指标不是它们的星数，是它们的最后一次 release 距今多久。
  3. 本次归档是否被当成「技术原因」报道——如果主流叙事把它归因于「AI 替代」，那会是框架误导的一个样本：真正的结构是私有产权式开源 + 单人 bus factor + 缺省被通用模型吞掉，三者各自都有份，而只有第三条是新的。

桥接：用威廉姆森的层次看，Pico 是只在 L2（许可证/产权）做了安排，L3（治理机制）整个留空的项目——许可证写得极好（MIT，永久有效，欢迎分叉），而**「谁来值班」根本没有进入制度视野**。它的七年成功与一次干净的死亡都来自同一个原因：没有人被承诺过任何东西，所以也没有人欠任何东西。 而 vLLM 走的是相反路线：用极重的 L3 换取 L4 的吞吐。两者没有高下，但终止时的差别是决定性的：一个交出的是一个可以继续的许可证，一个交出的是一张已经写好接班人的名单。开源的大部分分支，最终都停在「许可证还在」这一层——而「公地」这个词要求的，恰恰是许可证之外的那一层。

📡 今日新来源发现

  • GitHub Discussions（项目级公告） — 类型：平台治理文本。发现方式：Pico CSS 的停更公告本身写在 Discussions 里（而非仓库 README 或博客），且该帖是全部后续讨论的源头。推荐理由：Discussions 正在成为项目级重大决定的事实上的公告栏（停更、行为准则修订、治理变更），比 issue/PR 更接近「正式声明」的位置，且对监控池内所有项目通用。
  • Help Net Security（helpnetsecurity.com） — 类型：安全/开发媒体。发现方式：LF 那份 234 人调查的数据最完整的一次转述（含大项目 vs 小项目的分项、AI 政策比例、Assisted-by: 标准的说明）。推荐理由：对研究报告做分项摘录而非标题党转述，且长期跟进 AI-开源交叉议题，可作为 LF Research 报告的二次核实源。
  • anyblades/blades — 类型：继承型开源项目。发现方式：Pico CSS 归档后 HN 社区公认的继任者，贡献者分布与原项目同构（767:27）。推荐理由：可作为「缺省型开源库继任者能否长出第二根柱子」的长期观察样本，但单项目、六位贡献者，规模上属「小规模」，仅作为观察对象，不加入监控表。
  • GitSkills（arXiv:2610.37734 数据集） — 类型：数据集/语料。发现方式：153 万个 skill 的实测分析对象。推荐理由：agent 指令生态的第一个大规模可复核语料，对「AI 时代的规则扩散」研究有长期价值；但是数据集不是新闻源，不适合放进新闻来源表，记录备查。

今日无高置信新来源（未出现被 2 篇以上论文反复引用、且不在监控池中的期刊/基金会），因此未对监控源表做自动追加。

🔭 后续可检验的观察点

  1. Pico 的继任者能否长出第二个人（承接今日项目观察）：查 anyblades/blades 三个月后的贡献者分布，判据为是否出现非 tonystar 且贡献 > 50 次的账号。同时观察 Pico 的 npm 下载量是否在归档后下降——若下载保持平稳而无人接手，说明**「被使用」与「被维护」在数据上已经完全脱钩**，这是整个开源计量体系最根本的失真。
  2. Assisted-by: 是否会从内核扩散成跨项目惯例（承接 LF 调查中「1/5 贡献者从不提 AI」）：可查的判据是 Linux 内核 Documentation/process/ 相关条款的最近修订日期，以及是否有第二个大型基金会项目把同一条写进 CONTRIBUTING。若半年内仍只有内核一家，则「披露制」会被证明是靠维护者威望而非制度供给在维持。
  3. GSoC 的退出组织数是否增加（承接今日论文 1）：arXiv:2610.38167 记录到「已有一个组织退出」。可查判据是 GSoC 官方组织列表的年度变动与 mentor 列表里关于 AI 使用的规则文本——若规则仍只在双边协议里，检查成本会继续无补偿地压在导师身上。
  4. 昨日的 vLLM 观察点继续计时：committers.md 的 diff（Emeritus 是否增加）、合并权分散度是否维持（任一账号 < 20%）、open issue 9,672 是否继续上升（今日 k8s 3,205 提供了对照基线：差别在分类流水线，不在入口宽窄）。
  5. Agent Skills 的对照项仍在计时（承接 10-29、10-30）：agentskills/agentskills 与同基金会 modelcontextprotocol/modelcontextprotocol 的状态差是否延续到第三日——判据仍是默认分支最后提交日期、有无 GOVERNANCE.md / MAINTAINERS.md、open PR 数。

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