「开源之道」 2026-11-13 搜集事件和材料

「开源之道」昨日阅读 · 2026-11-12

今天三条线索收束于同一个动作：当 PR 的供给成本塌到零，准入就必须从「看产出」改成「看人」。

① 先看可合并性。 ExpertCrowd-SWE 用 100 个执业工程师写的真实仓库任务、3,495 次计分运行，测的不是「代码能不能跑」，而是「这段代码能不能进这个仓库」——它把「维护者会拒绝合并什么」写成了有名字、可执行、可复现的判据。一个反直觉的数字：中位票据 148 词，中位参考解 471 行；而步数从 33 到 166，与分数几乎没有关系。产出量不是质量的代理。

② 再看可解读性。 OpenRE-Bench 把五个真实项目的 3,000 条 issue 挖成可复现的实验底图，并把过滤后完整的 1,396 条 issue 池一并交出来。它揭示的制度事实是：每一条 issue 都先经过某个人的解读才变成任务，而那一层解读不可见、不入任何指标——现在它被切成两段可测量的接口。

③ 最后看价值在哪一层。 LF Research 问 225 家商业开源公司「你的第一竞争优势是什么」：57% 答品牌与信任，远高于企业功能、集成与社区规模。报告自己写的那句最诚实：「AI 现在几乎免费地写代码……如果代码的成本接近于零，软件的价值在哪里？」

Project Pulse 逐字读了 11-04 同日落地的两份章程：NVIDIA/OpenShell 把「谁能投票」写得极干净（Maintainer 身份由个体人类持有，AI agent 与公司不能持有，也不能行使投票权；活动计数明说不算品质代理），却对「谁可以把自己的代码合进去」保持沉默——抽查的 12 个已合并 PR 里，11 个的合并者与作者是同一人。agentskills 的《捐赠章程》同样完备，但捐赠当日两笔 PR、包括规定所有人如何成为 Maintainer 的章程本身，都是 Lead 写、Lead 合。

📄 论文两条

1. 可合并性是一套规则，不是一段代码：把「维护者愿意合什么」变成有名字的评分块

ExpertCrowd-SWE: Measuring Frontier Coding Agents on Expert-Authored Engineering Tasks in Unfamiliar Codebases · Josip Vrdoljak、Akash Singh、Bas Steunebrink、Alex Yarotsky、John Lorenzo、Achille Nicoletti、Sam Pigott（arXiv:2611.13246，cs.AI / cs.SE，2026-11-09）

链接：arXiv:2611.13246｜DOI 10.48550/arXiv.2611.13246

摘要：EC-SWE 是 100 个由执业工程师撰写的、面向大型陌生代码库的多文件软件工程任务基准。每个任务都是针对某个真实仓库的固定 commit 写的变更请求，配一份密封的参考解，以及一个任务专属的评分器——评分器的加权判据大部分是可执行检查，给部分分；此外还设了必须通过的阻断项（must-pass blockers）与闸门（gates），用来编码「维护者会拒绝合并什么」。任务跨 87 个开源项目、11 种语言，中位数票据 148 词，而中位数参考解改动 471 行。每个任务镜像在发布前都做过标定：参考解得 1.0，未改动的仓库与惰性变更得 0；近半数任务还附带「替代解 / 敷衍解 / 对抗解」控制补丁，评分器必须能把它们判对。最终 100 个任务是按当前前沿模型的难度筛出来的。七款前沿模型各跑五次（3,495 次计分运行），在给予各家原生工具接口的统一 harness 下：Claude Opus 5.5（67.3%）与 GPT-6 Astra（63.7%）领先且差距不显著，其后是 Claude Fable 5.1（46.5%）、Gemini 3.8 Flash（40.0%），Qwen 3.8 Max、DeepSeek V4.1 Flash、Grok 4.6 三者在 32–34% 区间统计不可分。没有任何一个任务被所有模型全解；有 80 个任务没有任何模型在五次运行中拿满分；分数跨度 35 个百分点。每次运行的中位步数 33 到 166 步，与分数几乎没有关系。发布 24 个任务的完整环境、评分器与结果，留出 76 个以限制污染。

为什么与「开源之道」相关：这份基准最重要的不是分数榜，是它构造评分器的那一步——「must-pass blockers 与闸门，用来编码维护者会拒绝合并什么」。也就是说，它不测「代码能不能跑」，而测「这段代码能不能进这个仓库」。这在方法上完成了一件此前一直靠争论完成的事：把「什么算有价值的贡献」显式写成一组有名字、可执行、可复现的判据。它同时给出一个反直觉的数字：中位票据 148 词，中位参考解 471 行——真实变更的信息比远高于「一句需求一段码」的想象；而步数（33→166）与分数几乎无关，则说明产出量不是质量的代理。这条结论在经验层面支持了 OpenShell 与 Agent Skills 两份新章程里那句方向相同的话：活动指标是资格下限，不是记分卡。

「开源之道」点评：这篇给 11-12 简报里那个落差（LF 实测 25% 入站 PR 判为 AI slop）补上了下半句：既然「什么算好贡献」是可以被写成规则判据的，那么 slop 就不是审美问题，而是判据缺位的问题。但也要看到它自己的边界：这套判据由出题方定义。87 个真实仓库的维护者并不知道自己参与了这场评判——基准拿他们的「会拒绝什么」做了编码，却没有问过他们。这正是衡量公地贡献时那个最老的难题：定义权归谁。把判据写清楚，是进步；把判据的所有权写清楚，才是制度。

2. 把别人的 issue 变成实验底图：维护者与 agent 的「解读」不是同一个函数

OpenRE-Bench: A Benchmark Harness for Multi-Agent Requirements Engineering with Mined GitHub Issues · Haowei Cheng、Milhan Kim、Bowen Jiang、Weixing Zhang、Yuhong Fu、Zhixu Liu、Naoyasu Ubayashi、Hironori Washizaki（arXiv:2611.13925，cs.SE，2026-11-10）

链接：arXiv:2611.13925｜DOI 10.48550/arXiv.2611.13925

摘要：基于 LLM 的多 agent 需求工程（RE）框架越来越多，但它们各自使用不同的 agent 角色、协商策略与输出形状，并且通常在各自的运行时、各自的指标和一小批手工整理的场景上评估，这使公平、可复现的比较变得困难。OpenRE-Bench 用四个可复用部件应对：统一的运行 harness（一个输入契约 + 阶段产物契约 + 指标契约）；单一的 adapter 机制（框架只需实现一个 adapter 即可接入，不触动用例、指标与其他 adapter）；可复现的 GitHub issue 挖掘流水线（让语料从真实的功能请求中生长）；以及带版本的用例套件。示范运行：从五个项目（三语言、五领域）抓取 3,000 条 issue，挖出五个用例，加上五个手工用例打包为 v1.0 精简套件；三个异构框架（MARE 与 iReDev 为忠实于论文的重实现，另加 QUARE）在同一协议下运行。该基准最初是 QUARE 研究的评测后端，此后已被同组另两项研究复用。随发布提供固定环境、Docker 镜像、冻结的 API 快照、651 个测试，以及被挖用例背后完整的 1,396 条过滤后 issue 池。

为什么与「开源之道」相关：需求工程在开源里的真实名字，一直是维护者读 issue。这批 issue 来自五个真实项目，而基线之下藏着一条极少被明写的制度事实：每一条 issue 都先经过某个人的解读，才变成任务——删掉什么、补什么假设、写到多具体，是不可见的、高度个人化的、不进入任何指标的一层。OpenRE-Bench 把「解读」变成一个可被多套框架并行执行、可被分数比较的对象，这是进步；但也在同一个动作里把这一层标准化掉：一旦所有框架都对着同一张契约做解读，判据的谱系就只剩契约自己能表达的那部分。它对「开源之道」的价值，恰恰是它在方法论上的克制——它公布完整的 1,396 条 issue 池而不只公布五个用例，这在 AI 时代的基准里是少见的公共品伦理：把底料交出来，别人才可能推翻你的挑法。

「开源之道」点评：这篇与上一篇构成一对：一个在合并之前（可合并性）设闸门，一个在合并之前的之前（可解读性）设契约。两者叠加就是 AI 时代开源贡献的完整收口——从一句话到一个 PR，中间原来只有人的判断，现在被切成了两段可以测量的接口。但要警惕一种误读：契约清晰不等于公地健康。奥斯特罗姆的八原则里，最有生命力的从来不是「边界清晰」本身，而是边界由受其约束的人共同设定并可修改。一个由研究者定义、由 agent 执行、由分数裁决的需求流水线，是高效的；它是不是公地，取决于维护者在这条流水线上还剩不剩一票。

📰 开源动态

225 家商业开源公司：57% 说自己的第一竞争优势是「品牌与信任」，而不是代码

来源：Linux Foundation Research × Serena《2026 年商业开源现状》，Web Summit 发布，2026-11-10｜报告页

摘要：Linux Foundation Research 与欧洲投资机构 Serena 合作、AWS / Red Hat / Futurewei / CNCF 赞助，在里斯本 Web Summit 发布第二年度《State of Commercial Open Source 2026》，样本为 225 位商业开源创始人与企业负责人。要点：72% 报告 AI 净正面影响（8% 负面）；收益目前主要发生在公司内部——内部生产力 73%、市场扩张 46%、新变现机会 39%；AI 相关岗位是唯一净增长的招聘类别；策略上多数公司未因 AI 改变，但一旦调整，开放核心产品的公司数量接近变封闭的两倍。差异化来源：57% 点名「品牌认知与信任」，远高于企业功能、集成、社区规模；信任通过支持与服务（63%）、托管云（49%）、开放核心（43%）变现，65% 同时跑两种以上收入模型，且是叠加而非替换（托管云从 ARR < 500 万美元公司的 35% 升到 > 2000 万美元公司的 66%；VC 支持的公司更偏开放核心 53% vs 38%）。买方结构：46% 的采购由 CTO 或研发副总裁批准，「开发者采纳、高管买单」的分裂在每个收入阶段都成立，于是 GTM 也是叠加的（后期公司 57% 跑两种以上，早期 40%）；建设成熟的企业销售能力是排名第一的规模化挑战（47%），也是未来两年的首要优先级；在追踪该指标的公司里，5 家中有 4 家在 12 个月内收回获客成本。

「开源之道」点评：这份报告最有信息量的地方，是它把一个关于成本的问题换成了关于位置的问题。报告开篇自己就这么写：「AI 现在几乎免费地写代码……如果代码的成本接近于零，软件的价值在哪里？」——而 225 家公司的答案不是「更强的功能」，是品牌与信任。用制度经济学的语言：代码这一层的交易成本塌了，价值就整体位移到了「可预期的可靠性与可追责的履约」这一层。这恰好解释了为什么「开放核心」这种形态在 AI 时代反而更普遍（53% VC 支持公司采用）：开放的那部分是可信度的抵押品，闭环的那部分是履约能力的变现口。要读得保守的一点是：这是自陈式调查，被问的是「你的竞争优势是什么」，答「品牌」在任何行业都政治正确。更硬的问题报告没有问：当 25% 的入站 PR 是 AI slop（Linux Foundation 自家数据），「信任」是靠什么维护住的？ 如果答案是靠品牌投入而非靠贡献流程，「商业开源」和「商业软件」的界线会以比人们想象更快的速度变模糊。

🔍 Project Pulse

今日深看：NVIDIA/OpenShell（L2 治理结构 · 章程与名册）｜agentskills/agentskills（L2 治理结构 · 捐赠后的名册与决策权） 选择理由：11-12 简报已报道过 OpenShell 捐赠的新闻面，却把「章程里写了什么」留给了今天；而 Agent Skills 的待确认状态今天可以靠公开档案结掉。两个仓库的证据都来自章程原文与 API 端点，不是新闻稿。

项目一：NVIDIA/OpenShell — 章程把「谁能投票」写得极干净，但合并不是

仓库：github.com/NVIDIA/OpenShell｜Apache-2.0｜21,503★｜2,101 fork｜2026-02-24 创建，2026-11-12 仍在推送

【L1 · 仓库现状】 仍在 NVIDIA 自家组织下，尚未迁入 cncf/ 命名空间。但入会不是新闻稿说的那样一蹴而就：CNCF Sandbox 申请 #522 于 2026-09-08 关闭，标签 gitvote/passed + contribution-agreement/signed——即在 KubeCon 宣布之前近两个月，TOC 的表决与贡献者协议签署就已经完成；#535 [PROJECT ONBOARDING] 至今仍开着，工作尚未收尾。另：GOVERNANCE.md / MAINTAINERS.md / CONTRIBUTING.md 齐备，CODEOWNERS 与 OWNERS 均返回 404。

【L2 · 治理结构】 章程（GOVERNANCE.md，13,590 字符）是目前读到的最干净的 AI 时代章程之一，三处值得逐字记下：

  • 「Maintainer 身份由个体人类持有。AI agent、自动化系统、服务账号、公司及其他组织不能成为 Maintainer，也不能行使 Maintainer 投票权。」
  • 「使用 AI 或 agent 既不使候选人有资格，也不使其失去资格。」 候选人的评估项是理解力、判断力、问责能力、社区参与，以及「对自己用 AI 工具或 agent 产出之工作的个人问责」；并明说**「原始贡献速度、代码行数、超出资格下限的活动计数，都不是这些品质的代理指标」**。
  • 资格下限写得很具体：≥3 个月持续参与、≥3 个实质 PR 合并、≥5 个实质 PR 的实质性评审，且「实质」被定义为需要真实技术或项目判断的工作——机械性改动、生成量、改动行数、成串的近似 PR 都不算实质。移除：六个月不活跃或失职，三分之二票；章程修订：三分之二票；日常决策：lazy consensus。

名册（MAINTAINERS.md）14 人，其中 11 人 NVIDIA、3 人 Red Hat——CNCF 明确把「维护者雇主多样性」列为评审考虑项，这里呈单极分布，但存在一个非零的第二组织。

【L3 · 社区活力】 近 30 天合并 312 个 PR；10-05 之后开出的 PR 中，至少 24 个来自名册之外的账号（grs、rafamolina1、dmonakhov、Varshith-Kali、getrou，以及一个格外显眼的名字：freeqaz-openai，11-10 提「给 Gateway 签名加一条替代 SPIFFE 的路径」）。新人入口通畅，这与 21.5k 星、2.1k fork 的体量相称。

但今天最硬的一条信号在合并侧：抽查 11-08 至 11-12 窗口内、成功读到的 12 个已合并 PR，11 个的 merged_by 与作者是同一人（purp、alangou、elezar 反复自合；样本内唯一的异例是 rhuss 的 PR 被 SDAChess 合并）。同一批 PR 各自获得了 APPROVED 评审，所以不是无人看；问题在于章程写了「评审与合并」却没写「禁止自合自审」——这份章程对「谁有资格投票」苛刻到逐字，对「谁可以把自己的代码合进去」则保持沉默。

「开源之道」判断：把这条放进威廉姆森的四层：L2（章程）已经写成了一份相当接近公地治理的文本——角色阶梯、个体持有、AI 不投票、量不作为质；而 L3（日常合并）仍按单一组织的节奏在跑。这两层并不矛盾，它们是同一件事的两个时间点：章程是捐赠时点写下的承诺，自合是运营时点延续的习惯。真正决定这个项目三五年后是不是公地的，不是 GOVERNANCE.md 里那几句漂亮话，而是**「自合率」这个指标会不会被写进章程**——因为这正是 meritocracy 与 powerocracy 的分界处：在功绩制里，合并权是别人给的；在权力制里，合并权是自己行使的。与 11-12 报道的 ANS 章程（五个 TSC 席位三个来自发起方）合看，可以说得更直接：AI 时代的新章程都很擅长规定「谁不能投票」，都很不擅长规定「谁不能自己盖章」。

项目二：agentskills/agentskills — 11-04 同一天补齐了「章程」和「最后两个文件」，然后两个 PR 都自己合了

仓库：github.com/agentskills/agentskills｜Apache-2.0｜27,223★｜2026-08-13 创建

【L2 · 治理结构（今日结算待确认状态）】 此前的观察结论是「根目录无 GOVERNANCE.md、无 MAINTAINERS 文件」。这两条今天可以结掉：2026-11-04 同时落地了 GOVERNANCE.md 与 MAINTAINERS.md，提交信息为 AAIF Donation: Add governance and maintainers (#648)。新章程值得注意的结构：

  • 采纳层级 Lead → Core → Maintainer → Contributor，Lead + Core 组成 TSC；Lead Maintainer 拥有对任何决定的否决权，并是全部基础设施的管理员；章程修订只能由 Lead Maintainer 提案，需 Core 三分之二 + LF Projects 批准，且仍受 Lead 否决。
  • 名册：Lead Maintainers 2 人（Mahesh Murag、David Soria Parra）；Core Maintainers 5 人；Maintainers「None at this time」；TSC Representative「Not yet designated」。
  • 章程第三节明写：项目结构「类似 Model Context Protocol、Python、PyTorch」，并在文末注明治理文本改编自 MCP 的 Governance 与 Contributor Ladder（CC-BY-4.0）。Core 层可核对到的雇主：Aiden Cline（Anomaly/OpenCode）、Harald Kirschner（Microsoft VS Code）、Kurtis Van Gent（Google Cloud）、Colin Daymond Hanna（Earendil），Nick Cooper、Mahesh Murag、David Soria Parra 未公开公司。跨组织超过一个，符合章程自陈的「Core 来自不止一个组织」。

【L1 · 发布节奏】 11-04 之前，默认分支最后一次提交停在 2026-08-09；此后除捐赠当日两笔外，至今（11-12）再无任何提交，空档约三个月。

【L3 · 社区活力 —— 今日最刺眼的一段】 捐赠之后新开的 PR 有多个（11-01、11-05、11-08 ×2、11-12 ×2 等），无一合并：#665 Add DeepSeek Harness to the Client Showcase（11-12）、#663 docs: complete name constraints in spec frontmatter table（11-12，只补两条已在 spec 里、validator 已实现的规则）、#650 Add Theia IDE、#642 docs: test descriptions against neighboring skills……开着的 PR 已达 68 个。更要紧的是合并者的行为：11-04 的两个捐赠 PR，作者与 merged_by 均为 maheshmurag——包括那份规定了后续所有人如何成为 Maintainer 的章程本身。章程第 8 节说「Maintainer 身份按功绩授予每一位候选人，无论其雇主是谁」，章程自己则是由 Lead 写、Lead 合、无人批准。

「开源之道」判断：这个项目的制度健康在 11-04 那一天是最好的，此后又开始下滑——不是因为章程写得差（它其实相当完整：提案需 sponsor、六个月无 sponsor 转休眠、接受后需至少一个可运行实现才算 final），而是因为章程与它的第一批执行样本在同一个账号手上完成。用奥斯特罗姆的话说：规则文本齐了，监督与冲突解决这两条链还没有一个非当事人的实例。用一句更简单的话说：「开源之道」的分水岭不是有没有章程，是章程第一次被别人引用、并在当事人之外被执行的那一刻。 一个可检验的下一个节点很清楚：#663——一条纯粹的技术补正，两条规则都已经在 spec 和 validator 里，它被谁合并，就是这份新章程的第一次真实测试。

🧭 明日观察与误判风险

  • 待检验节点：agentskills/agentskills 的 #663 由谁合并；NVIDIA/OpenShell 的 #535 onboarding 何时收尾、是否随迁入 cncf/ 命名空间而补充 CODEOWNERS / OWNERS。
  • 可量化指标：OpenShell 的自合率（抽查窗口内 merged_by == author 的占比）——这是「章程是否进入 L3」最直接的单一指标。
  • 误判风险一：自合不等于无人评审。样本内 12 个 PR 各自都有 APPROVED 评审，问题在评审与合并由同一主体串行完成；把自合率读成「无评审」会高估问题。
  • 误判风险二：11-04 两个捐赠 PR 的「作者 = 合并者」也可能是迁移窗口的过渡安排（新的 Reviewer 名册尚未激活，TSC Representative 仍是 Not yet designated）。这一条要等第一个非 Lead 账号完成合并动作再定性，今天只能记录形态，不能定罪。
  • 误判风险三：LF 调查为自陈式样本（225 人），「品牌与信任」在这个题型下带有社会赞许偏差；把它当作「商业开源已转向服务型」的硬证据是过度解读。

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