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

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

今天三件事压成一句：一件事能不能成，不看它对不对，看它有没有把判定的位置换成对自己有利的位置。

📄 最新开源研究论文

1. 欧盟为什么「不再爱」开源：EIF 的亲开源条款是怎么被稀释的

摘要：2000 年代初，微软垄断了欧盟的桌面与服务器操作系统以及生产力软件市场。2004 年，一群决心坚定的开源倡导者与欧洲委员会里少数技术专家联手，通过欧洲互操作框架（EIF），试图终结这一垄断——他们几乎成功了，一度让微软的游说团队疲于应对。研究用扩展的多源流框架（multiple streams framework，加装「技术流」）解释随后发生的事：2010 年 EIF 修订时，其中的亲开源条款被稀释。三条机制同时起作用——亲开放的政策企业家失去了政治支持；既得利益方的游说在技术流（标准与许可动态）发生变化后变得更有效；新的政策耦合点最终落在「商业模式中立 + 许可灵活性」这一措辞上。作者明确指出这段历史的现实意义：布鲁塞尔当下围绕开源人工智能的拉锯，是同一部剧本的重演。

开源之道点评：这篇论文的价值不在结论，在它拿掉了「政策为什么开倒车」这个问句里的道德成分。多源流框架逼着读者承认一件事：政策场里没有裁判，只有耦合点。 2004 年那批人赢，是因为问题流、政策流、政治流恰好同时打开，而他们手里握着一个具体的技术依据——互操作性。2010 年输，不是因为道理讲不圆了，是因为技术流变了：许可实践在演化，标准制定迁移，原本用来撬动市场的「互操作」这个词被重新定义了。用威廉姆森的层次说，这是一次 L2 层（制度环境）的漂移，而漂移的触发点在技术流，不是意识形态转向。

更能对上的是措辞史。「商业模式中立」听起来是价值中立，实际效果是把「谁有权使用接口」这个问题从公共讨论里挪走——一旦中立成为默认，剩下的唯一议题就是许可条款的灵活性，而灵活性的解释权落在合同双方。中性措辞永远是重新分配的前奏，这一点在 2010 年的 EIF 和 2026 年的 AI 政策辩论里用的是同一个句式。

对本土读者尤其要紧的是：这篇论文证实了政策企业家是一种需要持续政治供给的角色，不是一次性的提案成功。2004 年那批专家还在委员会里，但他们背后没有了政治意愿，于是同一个人、同一套论证，在不同的政治流里就失去了杠杆。这比「监管被俘获」的老叙事精确得多——不是被俘获，是支持方没有续费，而反对方一直在场。

2. 开源作为一种「技术—监管」策略：开放没有消灭价值，只是把攫取搬到了相邻层

摘要：文章把开源当作推进数字主权（定义为「理解、开发并规制数字技术，从而对数字资产行使自决与控制的能力」）的技术—监管策略。核心论点有四层。第一，开源不应被理解为与知识产权对立，而是一个建立在 IPR 之上的生态：开放许可需要可执行的产权才能被实施，它重构而非废除了排他权。第二，开源通常是专有策略的补充，而不是替代；它越来越多地被用作削弱竞争者的手段，从而转移价值攫取的位置。第三，即使代码或模型权重开放，行为体仍然通过拥有商业秘密、隐性知识、专有数据集与算力来构建权力——开放往往把价值攫取迁移到栈的相邻层，而不是消解它。第四，开放能否增强主权取决于许可之外的条件：治理、产业与能力。三个案例构成渐进逻辑：巴西用开放许可获得法律上不可撤销的访问权（防御之盾），但没有本土能力，访问只是把依赖换了个主人；韩国把开源嵌入发展型国家的产业政策，把访问转化为共同开发能力与出口实力；印度把开放、模块化的数字公共基础设施变成标准制定权，出口的不只是软件，而是一套数字治理模式。结论：对新兴经济体（以及数字意义上的大多数国家），开源只有在「开放 + 对制度、技能与产业能力的长期耐心投入」的生态战略中才真正增强主权。

开源之道点评：这是今年把「开源是俱乐部品而非公共品」讲得最清楚的一篇学术文本，而且它的落点比批判更狠——它不否认开放，它论证开放之后价值的落点会发生位移。许可有效性依赖可执行的产权这一条，直接击穿了「开源 = 反版权」的民间叙事：copyleft 之所以有力，恰恰因为它是一次用产权工具做互惠外化的极致操作，它必须有产权可依才发现得了违约。

案例的排序才是文章真正的论点。巴西、韩国、印度三种结果不是发展水平的差异，而是制度补位的差异：巴西拿到了访问权但没建能力，于是依赖二次化；韩国把开源编进产业政策，访问权变成了共同开发权；印度把开放当作标准输出，做出的是规则层面的出口。这和「生态是结果，不是手段」是同一件事的两面：能通过政策「构建」出来的是产业能力，不是生态；真正的生态只在规则自定、成本共担、边界清晰之后才出现。

最实用的是它对「伪开源」判准的间接回应：看开放之后价值攫取的落点有没有变。 如果代码全开而判定标准、数据集、算力与隐性知识仍锁在一处，那么开放只是把入口让出来，把出口留着。这比数许可证数量精确，也比数 star 有意义。

📰 开源动态摘要

1. systemd 合并 Rust 支持：先立规矩，再进代码

  • 事实：PR systemd/systemd#44324「rust: support programs written in Rust」，2026-10-24 合并，+5,144 / −11，54 个文件，提交者 brauner。
  • 边界被写死在方案里：只允许用于新的叶子组件，现有 C 代码不迁移；不用 cargo，全程 meson；no_std，只用 core/alloc/libc；libsystemd-shared 与 dlopen 机制不动；Rust 程序通过 .note.dlopen 声明依赖；按类型做机密擦除（Vec<u8, Erasing>）；test-cli-parity.sh 逐字节比对新旧组件的 --help / --introspect-cli 输出。构建开关新增 -Drust=（auto/enabled/disabled）。
  • 首个用户：systemd-keyring-setup；NEWS 明确标注它是「第一个用 Rust 写的 systemd 组件」。

开源之道判断：这是「先立规矩、再进代码」的教科书样本。把一个本来会被吵成审美之争的问题（该不该用 Rust），拆成三个可以在 CI 里判定的技术问题：能不能被构建系统完整描述（不用 cargo）、能不能不扩大信任边界（不碰 shared/dlopen）、能不能行为等价（逐字节比对 CLI 输出）。规矩先立在构建与测试层，争议就失去了入口。

这里有一个值得记住的治理动作：限制进入的范围，同时不禁止进入。叶子组件是可控的试验田——失败成本被隔离，成功再谈扩散。这跟很多项目「先放开再补规矩」的顺序正好相反，也和昨天 oneDNN 那种「先宣布再补治理」正好相反。制度设计的顺序，比制度内容更能预测结果。

（顺带一条：今天是 systemd，昨天是 FreeBSD 系的 Daemonarchy——同一个行业里，一个用多年时间把 Rust 纳入受控边界，一个用 10 天做出 10 个 release。速度与治理不是同一根轴。）

2. AMD 与 Intel 把 x86 CPU 优化并进 oneDNN：宣布已经过了一周，治理文件里 AMD 的席位还是空的

  • 事实：AMD 与 Intel 于 2026-10-20 宣布合作，把 x86 CPU 的 PyTorch 优化合并进 oneDNN（由 UXL Foundation 治理），这是 x86 Ecosystem Advisory Group 的建议；AMD 把自家 ZenDNN 的优化并入 oneDNN，并加入 UXL Foundation 成为 Steering Member（年费约 $20,000）。AMD 新闻稿 ・ 技术报道 ・ Tom’s Hardware
  • 落地侧的实测（2026-10-28 复核）：oneDNN 的 MAINTAINERS.md 里 AMD 区块仍然是 Vacant. Maintained by Core team.，NVIDIA 区块同样是 Vacant。核心团队全部为 Intel；AArch64 一节由 Arm 占 9 席；近一个月提交按邮箱域统计为 intel.com 82、arm.com 8、amd.com 6。
  • 实际合并已经在走：AMD 域名的提交集中在 2026-10-15 至 10-21，内容是 build: integrate ZenDNN from source via framework module、cpu: x64: zen: convert and copy zen_packed weights、build: zendnn: add package support and pin release tag 等；ZenDNN 自己的主分支最后一次提交停在 2026-10-14（[ZenDNN BUILD] Fixes issues discovered in oneDNN integration effort）。

开源之道判断：这条是「宣布的治理 vs 落地的治理」最好的当期货样本，而且它比一般样本更值钱，因为它不是「说了不做」，而是代码往前走、制度还没走。

三件事同时为真：AMD 的代码正在真的并进来（不是 PPT）；AMD 在 UXL 的会员身份已经付款（Steering Member，$20k）；AMD 在 oneDNN 的 Maintainers 表里还没有人。用威廉姆森的层次说，L4（资源配置，代码合并）已经在动，L3（治理机制，席位与审版权）还没动。这中间的时滞不是形式主义——席位空着，意味着这段窗口里 AMD 相关路径的审版权仍然归 Intel 的核心团队，而恰恰是这段窗口提交最多。

把这条和昨天的 oneDNN 判断接上：昨天记的是「宣布治理 vs 落地治理的落差」，今天的复核让落差更清楚了——落差不在意图，在会议的日历上。 MAINTAINERS.md 不是自动更新的文件，它是人际流程的产物；而代码合并有 CI 催着。任何「治理先行」的宣称，都可以用同一个方法测：看治理文件最后一次改动的时间，和代码最后一次来自新成员的时间。 前者落后于后者，就是宣称跑在了制度前面。

3. FreeBSD 创始人 Jordan Hubbard 十天做出十个 release：一个人 + 一个 agent harness

  • 事实：jordanhubbard/daemonarchy（把 Omarchy 桌面带到 FreeBSD 的安装镜像与构建工具），仓库 2026-10-01 建立，截至 2026-10-27 169 星、713 次提交、19 个 release，其中 10 个集中在 2026-10-15 至 10-25 的约十天内（10-15、10-16×3、10-17、10-18×2、10-24、10-25×2）。
  • 参与结构：贡献者列表只有 jordanhubbard 一人；84 个已合并 PR 全部由他本人合并。他自己仍在往 FreeBSD 官方 ports 提交（2026-10-01 一天提了 18 个新 port，含 x11/owe、editors/omarchy-nvim、audio/cliamp）。
  • 仓库里躺着的东西：AGENTS.md（指向 SKILL.md 作为项目权威）、SKILL.md（name: literate-ai）、.literate/、literate.project.json、以及一份自建的 litai 命令行。
  • 规矩怎么写的（原文摘）：SKILL.md 里几条值得抄下来——「Specifications record intended behavior. Existing source remains implementation and release authority」，规格记录意图，现存的源码仍是实现与发布的权威；「A discrepancy is work to reconcile, not permission to delete or regenerate implementation」，出现不一致是要去调和的活，不是删掉或重新生成实现的许可；「never synthesize a passing receipt or conversion status from historical logs」，绝不从历史日志里合成一个「通过」的凭据；原生 FreeBSD/VM/硬件的结果必须来自真实 worker 与确切产物，「macOS 上的元数据检查不能替代它」。

开源之道判断：先纠一个常见误读。这不是「社区扩容」，正好相反，是把社区这一层暂时省掉：19 个 release、84 个 PR，没有第二个人的名字。

真正值得看的是它为什么能这么快。答案不在 LLM 会写代码，在 SKILL.md 那三句话——它把「判定」这件事写成了可执行的约束：规格不等于实现（不许拿规格去覆盖源码）、不一致不等于可删（删是最省事的假修复，被明确禁止）、日志不等于凭据（不许从历史里合成成功）。这三条正好封掉了 agent 干活时最容易滑过去的三条捷径：以文档为准覆盖代码、以重写代替修复、以上次的日志当这次的证据。

所以它是**「一个人 + 一个 harness + 官方身份」的三元结构**：人的价值在于定规矩与签名，agent 的价值在于把判定劳动摊成流水，官方身份（FreeBSD 创始人）提供了别人拿不到的合法性。速度不是靠人变多，是靠判定被程序化。

但这条也有它自己埋的雷：169 星、单一贡献者、十天十个 release——这三个数字组合起来，意味着这套流程的可继承性尚未验证。一旦这个人停下来，litai 这套自建工具链本身就成了新的进入门槛。这跟昨天 Debian 的「纯 meritocracy 静默期」是同一个问题的两端：一边是人多但没人讲故事，一边是故事讲得很快但没人接手。

4. vLLM：一个外部贡献者改了「agent 写测试」的规矩，当天被接受

  • 事实：2026-10-21，aoshen02（vLLM 的 CONTRIBUTOR，非核心）连开两个 PR 并都在当天合并：#62599「Require docs for user-visible changes」（08:40Z 合并）、#62601「Raise the bar for agent-written tests」（10:02Z 合并，+41 / −1，3 个文件）。
  • #62601 改的是什么：修改 tests/AGENTS.md（该文件当前约 2.6 KB），把「agent 写的测试」的门槛抬到：用真实路径测试、先复现失败再修、不得为了绿 CI 而放宽阈值 / 重跑 / 跳过、构造要决定性、确保 CI 真的会跑。
  • 仓库已有的相关规范：docs/contributing/editing-agent-instructions.md 对 agent 指令文件本身有体量约束（AGENTS.md 限 200 行、domain guide 限 300 行，超出要拆不要压）；vLLM 至今没有 GOVERNANCE.md / MAINTAINERS.md，规则分散在 AGENTS.md + PR checklist + docs/ 里。

开源之道判断：这条的价值不在「vLLM 又立了一条规矩」，在谁立的、多久被接受。一个非核心贡献者，在同一天里改了这个项目对待 agent 的证据标准，并被当天合入——说明这条规则不是维护者自上而下颁布的，而是在争议现场长出来的，而且这一层的进入成本低到一天。

对比昨天的 PyTorch 数据更有意思：PyTorch 的做法是收窄入口（PR 必须 link 到 actionable issue 或点名同意的 maintainer，AI_POLICY.md 明确不接受全自动 agent 贡献）；vLLM 的做法是抬高证据（可以让 agent 写，但必须能出示先失败后通过的复现）。两条路都在回应同一个压力，但一个动的是门，一个动的是秤。收窄入口省的是判定成本（直接少收），抬高证据花的是判定成本（多要材料）。哪个更可持续，取决于维护者能不能承受那份材料——而 #62601 恰恰是让提交方自己生产材料，把判定工作前移给提交者。

顺带一条结构性观察：vLLM 没有 GOVERNANCE.md 和 MAINTAINERS.md，规矩散落在 AGENTS.md、PR checklist 和 docs 三处。这不算缺陷，但它意味着这个项目现在的制度记忆是文件化的、不是机构化的——每一条规则都能追到某一天的某一个 PR，但也因此没有任何一个地方写着「谁有权改这些规则」。当这类项目大到需要席位表的时候，第一个问题就会是：#62601 这类规则，该由谁来改？

📡 今日新来源发现

  • onlinelibrary.wiley.com（Wiley Online Library / Regulation & Governance） — 今日头条论文的正式发表版，CC BY 4.0 开放获取。监管研究（regulatory studies）的核心期刊之一，对「政策为何开倒车」这类制度动态有稳定的方法论文献，可作为「制度变迁经验研究」的来源补充。建议加入（高置信）
  • github.com/oneapi-src/oneDNN 的 MAINTAINERS.md — 不是新闻源，是治理档案源：厂商宣称与实际席位表在同一份文件里对照，可逐日 diff。所有「厂商合作 / 加入治理」的新闻，都可以用这份文件复核。同类可推广到 Kubernetes OWNERS、PyTorch CODEOWNERS。建议加入（高置信）
  • cyberbrics.info（FGV CyberBRICS 项目站）— 第二篇论文的预印本一手发布渠道，聚焦新兴经济体的数据治理、平台监管与数字主权，与「大分流」问题域高度重合，提供非欧美视角的制度研究。建议加入（中置信）

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

🔭 后续可检验的观察点

  • oneDNN 的 AMD 席位什么时候补上：这是本周最干净的一个可验证点。若 11 月中旬前 MAINTAINERS.md 的 AMD 一栏仍为 Vacant，而 AMD 域名的提交继续增长，则「宣布治理 vs 落地治理」的时滞就不是个案，而是厂商参与中立基金会的结构性特征。反向证据：AMD 提名 Maintainer 且其人有审版权。
  • EIF 剧本会不会在 AI 上重演：论文作者明说历史在布鲁塞尔重演。可检验的是措辞：「商业模式中立」这个词会不会出现在 AI 相关的欧盟文本里。措辞一旦出现，就说明耦合点已经移到了有利于既得利益方的位置——这比等立法结果早半年。
  • systemd 的 -Drust=enabled 会不会成为发行版默认：这是「先立规矩再进代码」的验收关卡。若一年内主流发行版默认开启 rust 且没有出现 ABI / 依赖回退，则这条路径可被其他基础库复制；若长期停在 auto，说明叶子组件的边界本身就在承担质疑。
  • Daemonarchy 的可继承性：单贡献者 169 星的项目，检验方法不是看 star，是看第一份非 jordanhubbard 提交的 PR 需要多久被审。若超过一周或无人应答，说明 litai 自建工具链已经把门槛内化成了个人门槛。
  • vLLM 会不会出现规则层的主权问题：tests/AGENTS.md 这类规范目前由谁改都行（#62601 已证明）。可检验的是：下一个改动这类文件的人如果不是长期贡献者，是否仍会在当天被合并。若开始被拖延或要求 maintainer 联署，说明非正式治理正在自发机构化。
  • 误判风险：今日四条判断的数据基础分别是——论文两篇（其一无开放获取，仅依据摘要页与预印本通告，未读全文，凡涉及论证细节仅引用作者自述的框架与命题）；oneDNN 席位以 MAINTAINERS.md 单次快照为准，可能在该文件更新前已通过邮件列表实际产生席位；Daemonarchy 的 release / 合并数据来自 GitHub API 实时查询，反映的是代码托管平台上的记录，不等于项目全部活动；vLLM 的 PR 合入时间取自 API 时间戳，不代表决策发生的时点。方向性判断（制度宣示与制度落地的时滞、判定成本被前移给提交方、速度来自判定程序化）相对稳，具体比例与天数不宜过度引用。

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

声明： 本文基于 Wiley Online Library（Regulation & Governance，doi:10.1111/rego.70217）、SSRN（doi:10.2139/ssrn.7612258）、CyberBRICS 预印本通告、GitHub API（systemd/systemd、oneapi-src/oneDNN、jordanhubbard/daemonarchy、vllm-project/vllm，2026-10-28 03:1x CST 实时同步）、AMD 新闻稿及技术媒体报道等公开来源，结合开源制度经济学视角分析，仅供参考。两篇论文中一篇为开放获取、一篇无开放获取（仅依据摘要与预印本通告，未读全文），已在正文中标明。所有计数为脚本实测值，未做推测性补全；「开源之道判断」部分为分析视角，不是定论。