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

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

一、今日核心命题：开源作为主权工具的第一个可核验制度案例

荷兰税务与海关总署取消 Microsoft 365 云迁移，转向本地开源方案（2026-10-13）

• 来源：ZDNET / Hacker News（99 pts）
• 制度路径：荷兰税务与海关总署（Belastingdienst）于 2025 年启动 Microsoft 365 公有云迁移（覆盖约 5000 名员工），2026 年 6 月荷兰 ICT 评估委员会（Adviescollege ICT-toetsing）出具正式意见书，指出信息处理、供应商锁定、数字主权、退出策略四大问题；7 月政府暂停；10 月正式转向本地部署 + 欧洲开源方案。2027 年邮件/日历落地，2027-2028 逐步替换个人存储与协作工具。

四项具体制度要求（这是本次事件的分析重点——不是「我们要用开源」，而是「我们的制度要求是什么，开源方案满足了」）：

• 谁发布规则：荷兰 ICT 评估委员会（独立评估机构）出具建议 → 财政国务秘书致议会信函
• 谁被纳入/排除：Microsoft 365 从「默认供应商」降为「仅存量使用」
• 资源如何分配：预算不削减，但重新分配到本地开源部署

开源之道点评：这是「开源作为主权工具」命题的第一个可核验制度案例——不是笼统的国家叙事，而是四个可检验的制度要求驱动的一次具体决策。适兕「制度怎么设计」而非「批判制度」的分析框架在这里落地——荷兰没有说「我们要用开源」，而是说「我们的制度要求是什么，开源方案满足了」。这与 LF Europe 2026 报告里笼统的「数字主权」话术形成鲜明对照：同样是「主权」二字，一个是四项具体规则，一个是叙事标签。

二、LF 三项目同周成立：开源基础设施向三层新公地延伸

1. BUILD Foundation（2026-10-14）

• 来源：Linux Foundation / PR Newswire
• 摘要：LF 宣布成立 BUILD Foundation，专注于大规模多语言构建与测试系统的可持续维护——包括 Apache Mesos、DistributedBuild、BuildGrid、Buildbuddy 等构建基础设施项目的托管。
• 开源之道点评：把 build/test 这类「元基础设施」（meta-infra）纳入基金会托管。制度设计意图：把过去由企业私有承担的 CI/CD 基础设施公共化。Williamson L3 治理层的一次下沉——从「代码托管」延伸到「构建流水托管」。

2. OpenGrid 项目（2026-10-07 首报，10-08 扩展报道）

• 来源：Linux Foundation 官方 / datacenter.news
• 摘要：LF 成立 OpenGrid 项目，目标是构建开放的、共享的电力基础设施数据层，用于电网规划与运营。
• 开源之道点评：这是「物理基础设施开源化」的新样本——从数字公地延伸到物理电网。关键问题：电网数据是公共品、俱乐部品还是可以私有化的资源？三种产权定位对应三种治理规则，需要在项目章程里看到。

3. Tokenomics Foundation（LF 正式设立，HPCwire 2026-10-09 确认）

• 来源：HPCwire（2026-10-09）
• 摘要：LF 内部流程正式设立 Tokenomics Foundation，专注于 AI 时代 token 的成本与价值度量标准。已发布 tokenomics.com 官方站点。
• 开源之道点评：制度经济学视角的核心案例。Coase 提出「度量成本」是市场交易的前提。当 AI 世界的「交易单元」变成 token，Tokenomics Foundation 试图把 token 度量标准化——这是新的产权-定价制度基础设施。

三条共同信号：LF 在 2026-10 单周成立三个新项目，把开源基础设施从「软件标准层」扩展到了三个新层级——

• BUILD Foundation = 元基础设施层（构建/测试流水）
• OpenGrid = 物理基础设施层（电网）
• Tokenomics Foundation = 度量层（AI token 计价）

这三层的叠加构成开源的「全栈基础设施」雏形——过去 LF 治理的是软件标准，现在治理的是「软件 + 构建 + 电力 + 度量」的完整协议栈。

三、HashiCorp Boundary CE 归档：OSS Core→SaaS 迁移的制度化证据

• 来源：GitHub / Hacker News（86 pts）
• 事实：HashiCorp 于 2026-10-09 将 hashicorp/boundary（4066 stars, 321 forks, 183 watchers）仓库归档为只读状态。最后提交者 learhy 提交信息为 Revise README for Boundary CE archiving (#6788)。
• 开源之道点评：Boundary 是 Hashicorp 的「零信任」身份访问管理产品。CE 版归档意味着上游开源版本停止接收新提交，商用版本继续维护。这是**「OSS Core → SaaS 迁移」的经典制度化案例**——适兕「开源是俱乐部品非公共品」命题的直接证据。
• 核心张力：当一个公司用开源做生态入口，但用归档决定「贡献定义权」的边界，社区如何反应？这是适兕 2026-10-13 收录的 xz 后门事件之后，产权置换的第二条路径——xz 是渗透型（外部攻击者进入治理），Boundary CE 是收编型（上游主动关闭贡献）。两条路径都指向同一个制度后果：开源的公共性依赖上游的持续承诺，而这个承诺本身可以单方面撤回。

四、最新研究论文：Agent 治理与开源类型学的制度化

1. arXiv 2607.15769 · Making Agent-Mediated Contributions Governable: A Project-Level Governance Manifest for Open-Source Projects（2026-07-17）

• 链接：arxiv.org/abs/2607.15769
• 摘要：针对 AI Agent 代理人类贡献者向开源项目提 PR 的新现象，提出项目级「agent-mediated contributions」治理清单——如何区分「人写的代码由 agent 递交」vs「agent 独立产出」，如何设定责任归属。
• 开源之道点评：这是适兕长期追踪的**「行动的定义权」命题在开源治理层的第一次具体落地。真正的制度设计问题不是「要不要允许 agent 贡献」，而是「贡献的价值标准谁定」**——这个标准在过去三十年由开源社区的 meritocracy 决定，AI agent 时代这个决定权正在漂移。Williamson L3 治理机制层：这是开源治理机制层面临的一次结构性重构——过去 review/CODEOWNERS/CI 都假设「贡献者是人」，Agent 代理贡献意味着 review 必须重新定义。

2. arXiv 2607.19022 · From Collaboration to Regulation: Characterizing Governance Practice in Three Deep Learning Open-Source Projects（2026-07-21）

• 链接：arxiv.org/abs/2607.19022
• 摘要：以三个主流深度学习项目为案例，刻画从「自愿协作」向「规则化监管」演进的治理实践。
• 开源之道点评：把 Acemoglu 的「包容性/汲取性制度」框架放到深度学习开源社区做实证。值得追问——作者是否已经区分了「规则增加」与「制度转型」？规则的增多不必然等于汲取性化，需要看决策权是否集中、外部贡献者的可及性是否下降。

3. arXiv 2607.01750 · Open Source Is Not One Thing: A Typology of Open-Source Software Sub-Genres（2026-07-02）

• 链接：arxiv.org/abs/2607.01750
• 摘要：提出开源软件的子类型学，避免把不同开源形态混为一谈。
• 开源之道点评：直接对应适兕「大分流 2.0」命题——真开源（FLOSS）vs 伪开源（特许工程代码/局域网共享/赛博庄园）需要一个类型学基础。这个类型学是否用可观察的治理规则（谁有 merge 权、外部贡献者门槛、许可条款）而非叙事标签做区分？这是判断该论文是否有用的分水岭。

4. SSRN 7543479 · Open Source as Regulatory Infrastructure: Where the Open/Closed Line Should Sit for AI Governance（2026-01）

• 链接：ssrn.com/abstract=7543479 / Zenodo 镜像
• 摘要：主张把开源作为 AI 治理的「制度基础设施」——用开源的透明性、可核验性作为规制 AI 模型的替代路径，明确讨论开放/封闭之间的边界应在何处划定。
• 开源之道点评：把「开源」从许可证层抬到治理层，直接回应「AI 能不能用开源范式治理」这个大问题。Williamson L2（制度环境）→ L3（治理机制）的下沉讨论。但要警惕——把开源「当作」监管基础设施，本身可能在把开源从「自发秩序」改造成「行政工具」，这是需要警惕的框架滑坡。

5. LF 2026 State of OSPOs and Open Source Management: Expanding Open Source Management for AI Systems（2026-10-01）

• 链接：Linux Foundation Research / DOI 10.70828/uclw3741
• 摘要：LF 年度 OSPO 报告，追踪全球企业 OSPO 在 AI 系统管理上的角色扩展——从合规合规到战略赋能，再到 AI 治理与 token 成本管理。
• 开源之道点评：这是 OSPO 演化「合规→赋能→AI 治理」三阶段的最新证据。Williamson L2 制度环境层：企业 OSPO 是「内部交易成本节约」（Coase 正统）还是「外部公共品搭便车」？两种解释的政策含义完全不同——前者意味着企业 OSPO 是企业边界的自然延伸，后者意味着企业 OSPO 是公共品的私有化。Coase 意义上「企业为什么存在」的边界正在向 AI 迁移。

6. LF 2026 State of Open Source in Europe（2026-10-01）

• 链接：Linux Foundation Research / DOI 10.70828/olta8310
• 摘要：LF Europe 年度开源报告，讨论欧洲在 AI 与数字主权背景下对开源的战略定位。
• 开源之道点评：与荷兰 M365 事件形成对照——欧洲把「开源」作为主权工具的框架选择，是「开源被行政化」命题的欧洲样本。「数字主权」话术与开源的「公共性」是不同范畴——用开源工具支持主权是可以的，用主权叙事收编开源会损伤开源的协作公共性。荷兰案例是「用开源满足具体制度要求」，LF Europe 报告是「用主权叙事论证开源」——前者是制度设计，后者是叙事框架。

五、AI 时代治理的实证信号

1. Microsoft Patch Tuesday 单日推送超过 2025 全年（2026-10-13）

• 来源：The Stack
• 摘要：Microsoft 10 月补丁日推送的补丁数量超过 2025 年整年。
• 开源之道点评：这是**「闭源基础设施的漏洞管理」极端案例**。适兕的分析框架在这里反过来验证——当闭源系统的漏洞处理跟不上攻击速度，「开源=可审计」的制度优势就变成生存必需而非可选。这不是「开源替代闭源」的技术命题，而是「闭源已经无法自证安全」的制度命题。

2. JPMorgan：「量化 AI 收益是浪费时间」（2026-10-14）

• 来源：The Stack
• 摘要：JPMorgan 高管公开表示量化 AI 收益投入是「浪费时间」。
• 开源之道点评：与 Tokenomics Foundation 试图量化的「AI 成本/价值」命题形成制度层无法通约的直接证据。适兕「评价体系不可通约性」命题在这里获得金融巨头样本——金融巨头已经在承认 AI 的绩效度量在制度层无法标准化，而 Tokenomics Foundation 试图建立度量标准。两个方向的对峙不是技术问题，而是制度问题——如果度量的边际成本高于度量带来的治理收益，Tokenomics Foundation 的治理尝试可能遭遇「度量悖论」：度量的行为本身改变了度量的对象。

3. Starling 银行在主权英国云训练 AI 模型（2026-10-14）

• 来源：The Stack
• 摘要：英国零售银行 Starling 宣布在「主权英国云」上训练模型，其 CIO 就 AI 集中风险发出警告。
• 开源之道点评：金融机构是**「AI 治理」的具体行动层**。当「AI 集中风险」进入银行 CIO 的正式议程，说明治理问题从研究层传导到了商业决策层——这与 JPMorgan 的「量化 AI 收益无意义」形成金融内部治理的两极：Starling 用「主权云」应对风险，JPMorgan 用「不量化」应对不确定性。

六、项目动态与其他

• AWS 升为 Linux Foundation Platinum 会员（2026-10-07，PR Newswire）——「公共基础设施的准入规则」的具体表现：会员层级直接对应治理权分配。需要观察 AWS 加入后哪些 TC/SIG 席位变化。
• xFusion（超聚变）加入 Linux Foundation（2026-10-07）——一家硬件厂商加入 LF 是常见商业行为，制度含义在于它获得了 LF 治理结构的准入席位。
• Apache Subversion 1.15 发布（2026-10-14，ASF）——「Pristines On Demand」优化大文件仓库工作流。属于 L4 层资源配置，制度含义较弱，但值得记录 ASF 项目仍在活跃迭代。
• Apache 新 Top-Level Projects 公告（2026-10-14）——ASF 的晋升路径（Incubator → TLP）作为治理层级仍在运作。
• MITRE 将 Caldera 捐给 ASF（2026-05-26，回顾）——「国防研究→开源公地」的制度路径，是「包容性制度」的具体样本。

🔍 Project Pulse

项目一：Kubernetes v1.38 alpha 节奏稳定，SIG 治理权三家均衡

• 项目：Kubernetes（kubernetes.io）
• 来源：GitHub releases / Kubernetes blog

【L1】大版本发布：

• v1.38.0-alpha.1（2026-09-29）→ v1.38.0-alpha.2（2026-10-07），间隔 8 天
• 三个稳定分支 v1.35/1.36/1.37 都在 2026-09-23 同一日发 patch

【L2】治理结构：

• SIG Apps spotlight（2026-09-22）由 VMware/Broadcom 员工主导撰写
• Pod-Level Resource Managers Beta（Google 员工 Kevin Torres Martinez）
• Memory QoS Beta（Red Hat 员工 Qi Wang, Sohan Kunkerkar）
• SIG 治理权在 Google/Red Hat/VMware 三家公司之间相对均衡

【L3】新人加入：

• DaoCloud Paco Xu（2026-10-06）、Ocean Xie + Yuan Wang（Node Swap，2026-10-05）——新人贡献者来源多样化

开源之道判断：Kubernetes 的「制度健康」良好——SIG 治理权在主要公司间形成制衡（Acemoglu 意义上的「包容性」），新人加入路径通畅。这是**「慢聚漫奏」型节奏的典范**，不是「效率求生」。Williamson L3 治理机制层：CNCF 的 LTS 政策 + SIG 结构 + TC 治理层级共同构成 Kubernetes 的治理机制资产。

项目二：Apache Software Foundation——晋升机制 20+ 年持续运作

• 项目：ASF（apache.org）

【L1】：Subversion 1.15 发布 + 新 Top-Level Projects 公告（2026-10-14）

【L2】：ASF FY2026 Report 显示 302 个活跃项目——规模在扩张。MITRE 捐赠 Caldera（2026-05-26）——「国防研究→开源公地」的制度路径

【L3】：Incubator → TLP 晋升路径仍是 ASF 的核心治理机制

开源之道判断：ASF 保持了 20+ 年的稳定晋升机制（Incubator→TLP），这个治理层级设计是 Williamson L3 治理层的成熟案例。稳中有升——但需要警惕「规模扩张 = 治理稀释」的风险。ASF 从 20+ 年积累的 302 个项目看，扩张的边际成本可能已经开始显现。

七、今日新来源发现

八、今日核心命题总结

「开源作为主权工具」的两种实现路径——

1. 荷兰 M365 案例：制度要求驱动——四项具体规则（Double Key、E2E 默认、反锁定、退出策略）驱动的制度决策。这是「用开源满足具体制度要求」，是制度设计的正路径。
2. LF Europe 报告：主权叙事驱动——笼统的「数字主权」话术包裹的开源战略。这是「用主权叙事论证开源」，是叙事框架的路径。

两条路径的共同结论：开源在中国的语境里不能被简化为「我们要不要拥抱开源」的技术选择，而是**「我们要不要用开源工具满足具体制度要求」**的制度设计问题。适兕「制度怎么设计」而非「批判制度」的分析框架在这里落地——荷兰没有说「我们要用开源」，而是说「我们的制度要求是什么，开源方案满足了」。

同时，今天还有一个反方向信号——HashiCorp Boundary CE 归档揭示：开源的公共性依赖上游的持续承诺，而这个承诺本身可以单方面撤回。这与「开源作为主权工具」命题形成结构性张力——如果开源本身可以被上游收编（Boundary CE），那么「用开源满足制度要求」的安全性如何保证？

这是今天开源治理命题的核心张力：开源既可以被主权工具化，也可以被上游收编——两种力量方向相反，但共享同一个前提：开源是一个可以被制度化的对象。

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