「开源之道」 2026-08-25 搜集事件和材料

「开源之道」 2026-08-25 搜集事件和材料

本期聚焦：Basecamp/DHH 推出的 Omarchy Linux 发行版（约 3 万 GitHub star）正式通过 Omarchy Foundation 获得 800 万美元初始资金，以"慈善基金（charitable foundation）“形式支撑开源桌面 Linux 长期维护——这是**“个人品牌操作系统"通过基金会制度寻求可持续性**的典型案例；Kubernetes v1.37.0-rc.1（2026-08-20）进入准稳定候选；Linux Foundation 的 Akrites 项目九月正式上线运行；Apache Software Foundation 命名 Apache Fluss（湖仓流存储）与 Apache Pony Mail（Web 邮件）为新 Top-Level Projects；Open Source Summit Europe 2026 于 10 月 7-9 日在布拉格举办，与 Linux 35 周年同庆。

📄 最新开源研究论文

制度分析视角：今日从 OpenAlex/CrossRef 数据库检索开源治理相关论文，未发现"最近 2 天内发布"的新论文——这再次印证**“实践先行，学术滞后”的结构性张力。AI 时代的开源治理实践（Akrites、Glasswing、Omarchy Foundation、Tokenomics Foundation）已密集推进，而学术界仍在消化 2006–2024 年间发表的经典文献。两篇近期制度分析相关的代表性论文**（非近日发布但值得今日语境下再读），从"制度设计"而非"技术实现"的角度与当前的新闻事件形成对话。

论文 1：『Stewardship』as a Fair, Accountable and Transparent Model for Free and Open-Source Software Governance? Looking Beyond the EU’s Cyber Resilience Act

• 作者：Jennifer Tridgell, Jatinder Singh
• 发表：2025-06-23
• 摘要：政策制定者正在提议将"stewardship”（托管/受托治理）作为 FOSS 的治理模式，指定"被选中的托管者"承担特定开源项目的责任。论文批判性地审视了 EU Cyber Resilience Act 中的这一构想，指出"stewardship"隐含的假设——即开源项目可以被"指定给"某个主体来负责——与开源社区自发秩序和 meritocracy 传统存在根本张力。论文追问：谁有资格被选为"steward”？被选中的"steward"如何对被服务的社区负责？托管关系中的激励机制设计是否会导致治理权的"汲取性化"（extractive institutionalization）？
• 为什么与开源之道相关：这篇论文直接对话今日的行业实践——Omarchy Foundation 本质上就是在做"指定托管者"（Designated Steward）的事情：800 万美元资金明确投向 DHH 的 Omarchy 发行版。论文提出的核心问题——“托管者如何对社区负责”——是 Omarchy Foundation 未来必须回答的制度设计问题。
• 开源之道视角点评：Tridgell & Singh 提出的质疑，恰好是大分流 2.0 叙事中"特许工程代码 → FLOSS 过渡态"的经典困境。“托管"不是"治理”——Ostrom 的自组织八原则强调治理权应从使用者社区内生，而"stewardship 模型"将治理权外移到被指定的"托管者"，在 Williamson L2 层面是制度环境对治理机制（L3）的外部嵌入，可能削弱社区的自主演化能力。Omarchy 的 800 万美元资金能否避免陷入"托管者捕获治理权"的陷阱，是未来 2-3 年值得追踪的制度实验。

论文 2：Rethinking open source generative AI: open washing and the EU AI Act

• 作者：Andreas Liesenfeld, Mark Dingemanse
• 发表：2024-06-03（截至 2026 年 8 月，引用 62 次）
• 摘要：论文批判性地分析了 AI 时代"开源"概念的语义漂移——许多前沿 AI 公司宣称的"open source AI model"实际上只是"open weights"（开放权重），并未满足开源软件传统定义中的四项基本权利（使用、研究、分发、改进）。论文称之为"open washing"（开源漂绿）——借用"greenwashing"的概念框架，揭示 AI 行业正在用"开源"标签抢占制度合法性，而实际上并未承担开源社区的权利义务。论文进一步分析了 EU AI Act 对"open source AI"的监管回应，指出法律定义与社区定义之间的差距。
• 为什么与开源之道相关：这篇论文是理解"Mojo 半开源"（Apache 2.0 but no contributions accepted）、“AI 模型开源”、“open weights"等当下热议话题的理论基础。适兕此前在 2026-08-24 日报中分析的"Mojo 开源产权释放而非协作开放”，本质上就是论文讨论的"open washing"的一种变体。
• 开源之道视角点评：Liesenfeld & Dingemanse 的核心洞察是：“开源"作为一个概念，正在经历从"自由软件传统的权利束"向"技术产品的营销标签"的语义漂移。这与大分流 2.0 的核心判断一致——“大分流 2.0"中区分"真开源（FLOSS）“与"特许工程代码"的关键判据，恰好是社区是否拥有修改权和改进权。当一家公司（如 Modular/Qualcomm）公开源代码但保留合并权，或 AI 公司发布模型权重但不开放训练数据/代码/改进权时，它们实质上是在做"开源的产权释放“而非"开源的治理开放"。

📰 开源动态摘要

今日筛选了 8 月初以来的主要新闻（部分 8 月中下旬的报道在前几天简报中已有初步分析，今日聚焦8 月 20-24 日的新信号，以及尚未深入展开的8 月初事件的制度分析）。

1. Omarchy Foundation 成立，获 800 万美元初始资金

• 来源：Open Source For You (2026-08-24)
• 摘要：Omarchy Foundation 于 2026 年 8 月正式宣布成立，获得 800 万美元初始资金，以慈善基金会（charitable foundation）形式，为 Omarchy 发行版提供长期的开发、生态建设与硬件整合支持。Omarchy 是 Basecamp 联合创始人 David Heinemeier Hansson (DHH) 基于 Arch Linux 打造的桌面发行版，截至 2026 年 8 月已在 GitHub 获得约 29,697 stars、3,004 forks（MIT 许可证），代码仓库活跃（6,145+ commits）。基金会成立的目标是确保 Omarchy 在 DHH 个人主导之外获得可持续的制度支撑。
• 开源之道点评：这是一个**“个人品牌 → 基金会制度"的经典跃迁案例**。800 万美元的初始资金相当于为 DHH 的个人 OS 梦想购买了一份制度保险——用基金会的永久法人身份替代了个人开发者"人走茶凉"的生命周期风险。从 Williamson 框架看，这是在 L2（制度环境）层面为 L1（嵌入性实践）提供稳定性保障。但问题在于：Omarchy Foundation 的治理权如何分配？DHH 是否保留 veto 权？社区 maintainer 的路径是否通畅？ 如果基金会只是"以基金会之名行个人庄园之实”，则落入"赛博庄园"的窠臼；如果能建立 meritocracy 的贡献通道和多元治理结构，则可能成为 Linux 发行版生态中"个人魅力 → 制度化治理"的成功样本。800 万美元能否买到"治理合法性”，而不仅仅是"治理延续性”——这是 Omarchy Foundation 面临的核心制度设计问题。

2. Kubernetes v1.37.0-rc.1 发布（2026-08-20）

• 来源：GitHub kubernetes/kubernetes releases
• 摘要：Kubernetes v1.37.0-rc.1 于 2026 年 8 月 20 日发布（rc.0 于 2026-08-06 发布）。同日发布还有 v1.36.4（8月20日）、v1.35.8、v1.34.11 等补丁版本。v1.37 系列 CHANGELOG 涵盖 API Change、Feature、Bug Fix 等标准发布内容。
• 开源之道点评：Kubernetes 的双月发布节奏（v1.37 于 8 月进入 rc，预计 9-10 月 GA）已经稳定运行多年——这是"slow-and-steady wins”（慢聚漫奏）治理模式的典型体现。相比 Mojo（“开源但不开放贡献”）、Omarchy（“个人品牌+基金会”）等正在探索治理边界的开源项目，Kubernetes 的治理模式已经制度化——SIG（Special Interest Group）机制、CNCF 托管、多公司 maintainer 分布。当新兴项目还在讨论"什么才是开源"时，Kubernetes 已经在回答"如何长期治理一个关键基础设施”。

3. Linux Foundation Akrites 项目九月正式上线

• 来源：Infosecurity Magazine (2026-08-19)
• 摘要：Linux Foundation 此前于 2026 年 6 月与 19 家行业领先企业联合发起的 Akrites 项目（取自希腊神话中守护工匠的精灵），旨在为关键 OSS 提供协调漏洞修复的统一流程。2026 年 8 月 19 日消息确认该项目将于 2026 年 9 月正式上线运行，此前已宣布获得 1250 万美元的联合资助（2026-03-17）。
• 开源之道点评：Akrites 的核心问题是**“谁有资格调度修复流程”——当 AI 驱动的自动化扫描加速漏洞发现，而修复能力仍依赖志愿者时，“调度权"成为一种稀缺资源。Akrites 选择了“基金会化集体行动"替代"市场化安全服务”**的路径，本质上是 Ostrom 的公共池塘资源治理在开源安全领域的具体应用。与 Anthropic 3500 万美元安全基金（2026-08-21）形成对比：Akrites 走"多边协调"路线，Anthropic 走"单边资助"路线——前者是"包容性制度”，后者是"防御性贡献"。

4. Apache Software Foundation 命名 Apache Fluss 与 Apache Pony Mail 为新 TLP

• 来源：ASF 官方博客 (2026-08-06)
• 摘要：ASF 于 2026 年 8 月 6 日命名 Apache Fluss（湖仓一体实时流存储，面向实时分析/AI）和 Apache Pony Mail（基于 Web 的邮件系统）为新的 Top-Level Projects (TLP)。
• 开源之道点评：Apache 的 TLP 晋升机制（Incubator → TLP）是**“meritocracy 制度化"的经典范本**——一个项目能否成为 TLP，取决于它是否满足 ASF 的社区健康度标准（贡献者多样性、治理文档完整、决策透明），而非技术性能或商业价值。Fluss 作为 AI 时代的流存储新选择，其 TLP 晋升标志着ASF 正式接纳 AI 基础设施项目进入基金会体系。这与 Python 3.15 PEP 争议、Mojo"半开源"形成对比：ASF 用 TLP 机制定义了"什么是有资格进入基金会的项目”，本质上是"行动的定义权**“在机构层面的制度化行使。**

5. Open Source Summit Europe 2026：10 月 7-9 日布拉格，与 Linux 35 周年同庆

• 来源：Linux Foundation Events (2026-08-05)
• 摘要：Open Source Summit Europe 2026 于 2026 年 10 月 7-9 日在捷克布拉格举行，与 Embedded Linux Conference Europe 同步举办。本届特色包括：①与 Linux 35 周年同庆（1991-2026）；②多轨道议程——Cloud & Orchestration、Open AI + Data、Digital Trust、Embedded Linux、Safety-Critical Software、Zephyr Developer Summit 等；③Zephyr Project 10 周年庆典（Community Awards，提名截止 2026-09-01）；④LF Member European Forum（10 月 6 日，仅邀请制）。
• 开源之道点评：Linux 35 周年是一个制度经济学意义上的里程碑——35 年前 Linus Torvalds 在内核邮件列表（comp.os.minix）上发帖"我：操作系统”，35 年后全球每年 OSS 产值超过数千亿美元。35 年的持续运作，本身就是对"为什么市场无法替代开源协作"这一科斯问题的最强实证。当 Mojo、Omarchy 等新兴项目还在讨论"什么才是开源"时，Linux 用 35 年的时间给出了答案——开源的生命力不在于定义，而在于持续的"keep movement"。

6. HN 热议：“AI Agent 生态的治理工具竞赛”

• 来源：Hacker News（8 月热点帖）
• 摘要：近期 HN 上出现一批与"AI Agent 平台化 + 开源"相关的 Launch HN/Show HN——OneCLI（YC S26，开源 sandboxed agent harness for teams，87 pts）、Proliferate（open-source, self-hostable Codex for coding agents）、Vendo（YC S26，let users build features on top of your product，61 pts）、Speko（YC S26，OpenRouter for Voice AI，118 pts）。这与"AI Agent 治理工具化"的趋势（MCP、AGENTS.md、AAIF）形成呼应。
• 开源之道点评：开源 AI Agent 工具在 YC 2026 夏季批次中批量出现，标志着**“AI 协作"正在从闭源实验转向开源基础设施**。OneCLI 的核心价值主张——“sandboxed agent harness for teams”——揭示了企业采用 AI Agent 时的核心焦虑：“如何在一个可审计、可恢复的环境中运行自主式 Agent”。这与 Akrites（开源安全）和 Anthropic 安全基金形成了同一问题的不同解法——前者用开源工程解决，后者用企业资助解决。

🔍 Project Pulse：Kubernetes v1.37.0-rc.1 与 Apache TLP 晋升

项目 A：Kubernetes（cloud-native 事实标准）

• 【L1】 2026-08-20 发布 v1.37.0-rc.1（rc.0 于 8-06），同日发布 v1.36.4、v1.35.8、v1.34.11 三个 LTS 分支补丁。发布节奏稳定——v1.37 从 alpha（约 6 月）→ beta → rc 的标准 3 个月周期。发布节奏在"慢聚漫奏"的区间，未出现加速或异常。
• 【L2】 治理结构延续既有 SIG 架构，无公开的重大治理结构变化。CNCF 托管模式稳定。
• 【L3】 v1.37 CHANGELOG 中的 Bug Fix/Feature 更新涉及数千个 commit，maintainer 分布继续呈现多公司特征（Red Hat、Google、Microsoft、Intel、VMware 等）。
• 开源之道判断：Kubernetes 的治理健康度稳定——发布节奏可预测，治理结构清晰，maintainer 多元。它不是"正在探索治理边界"的项目，而是"治理已成制度"的项目——这与 Mojo、Omarchy 等新兴项目形成对比。适兕在 8-24 日报中关于"开源是俱乐部品"的判断在 Kubernetes 上得到了正面验证——Kubernetes 的"俱乐部准入条件”（SIG + CNCF 毕业）已经制度化，新 maintainer 的路径（Contributor → Reviewer → Approver → Owner）清晰可查，是"包容性制度"的典范。

项目 B：Apache Software Foundation（TLP 治理机制）

• 【L1】 2026-08-06 命名 Apache Fluss（湖仓流存储）与 Apache Pony Mail（Web 邮件）为 TLP。同期 8 月其他 TLP 晋升动态（Apache HertzBeat、Apache Teaclave、Apache Training）也在进行。
• 【L2】 TLP 晋升机制本身是 ASF 的核心治理资产——一个项目能否晋升为 TLP，取决于社区健康度（贡献者多样性、决策透明度），而非技术实力。Fluss 的 TLP 晋升意味着 ASF 对"AI 基础设施"进入了孵化/接纳阶段。
• 【L3】 TLP 决策过程由 ASF Board + PMC 共同审议，全程邮件列表公开——这是**“治理即文档”（governance-as-documentation）** 的经典实践。
• 开源之道判断：Apache 的 TLP 机制是meritocracy 制度化最完整的样本——它回答了 Coase 的"企业为什么存在"问题的开源版本：“项目为什么要进入基金会？” 因为基金会提供了跨企业的治理公共品（法律人格、品牌信任、贡献者保护），这是单个企业无法单独提供的。Fluss 的 TLP 晋升标志着 ASF 正式把"AI 基础设施"纳入其治理覆盖范围——这与 PyTorch Foundation（2025-10 CNCF 接纳 Ray）、AAIF（2025-12 成立）共同构成了"AI 基础设施开源治理"的新格局。

📡 今日新来源发现

🔍 关键项目洞察（Project Pulse）

本期深看三个最显著信号：Linux Kernel 的 7 日 12,116 封邮件制度惯性、Git 的单人治理极限、AAIF/MCP 生态剩余控制权的真实分布，与今日日报其他内容形成制度经济学视角的横向对照。

项目：Linux Kernel (lkml) 数据范围： 2026-08-18 ~ 2026-08-24（7 日） 邮件总量： 12,116 封

【L1 · 大版本发布与 PATCH 系列】 本周无重大版本发布，但 PATCH 流水线密集：RTL8723BS 无线驱动 OOB 读修复（staging）、nvme-tcp I/O 队列并行化、s390/vfio-ap 驱动 bug 修复、ALSA usb-audio 多版本迭代（v5/v6）、openvswitch use-after-free（v9）、PCI/HMAT P2PDMA 可达性 RFC 等 30+ 系列并行流动。syzbot 自动化 fuzz 报出 net/bpf/sound/acpica/io-uring/btrfs 等模块的 KASAN 越界读、lockdep 警告、page fault，其中 exfat 的 fat_ent_write WARNING 已被明确要求回退（“Please drop 64d9183203eeb”）。自动化测试与人工修复之间的节奏是判断制度健康的关键——syzbot 报告量与回退量同频，说明反馈回路通畅。

【L2 · 治理结构变化】 域名分布信号（前 5）：kernel.org 2,218（LWN/B4 Relay 中转，制度基础设施本身）> gmail.com 2,017（个人贡献者主体）> oss.qualcomm.com 821 > intel.com 427 > linux.dev 425。后续 redhat.com(295)、nvidia.com(291)、google.com(261)、linux.ibm.com(195)、amd.com(176) 等企业域均匀分布——无单一企业主导超过 5%。Top 个人贡献者中 Konrad Dybcio（195 封）、pr-tracker-bot（162，自动化）、Krzysztof Kozlowski（152）、Abel Vesa（149）均为 subsystem maintainer 级别。值得关注的新信号：kylinos.cn 出现在 Top 20（129 封），麒麟软件作为企业贡献者进入 lkml 常规流量——这是中国开源"效率求生"路径在 Kernel 层面的具体嵌入，但不构成治理结构变化。

【L3 · 新人加入与社区活力】 syzbot（syzkaller.appspotmail.com）207 封占自动化流量首位，kernel test robot 78 封——自动化测试基础设施的活跃度本身就是社区活力的代理指标。新人域分布广但单域量级低，说明 lkml 仍维持低门槛、高并发、分布式的准入模式。

📌 开源之道判断 lkml 的制度健康度：🟢 稳定。无版本发布不等于无活动——30+ PATCH 系列 + syzbot 反馈回路的节奏本身就是制度运行的证据。Williamson L2 层面的多企业参与均匀分布（无 >5% 主导）是包容性制度的实证。kylinos.cn 的进入是"中国企业嵌入真开源基础设施"的最新实例——与今日日报中的 Omarchy Foundation 形成对照：一个是从个人品牌到基金会的制度上移，一个是从企业实验室到全球公地的制度嵌入，路径相反但都指向"制度化可持续性"。

项目：Git (lore.kernel.org/git) 数据范围： 2026-08-24（当日） 邮件量： 433 封

【L1 · PATCH 系列】 当日 10 个 PATCH 系列在飞：hook: introduce the report hook for git-receive-pack(1)（v3，3 系列）、reftable/stack: avoid reloading the stack when locked（v2, 4 系列）、config: read both home and xdg files for --global（v2, 3 系列）、worktree add: improve message for ambiguous remote branch name（v7，已进入第 7 版）等。v7 版本号暗示某些改动经历了多轮 review 迭代——Git 的 review 文化是严苛的，但这正是 meritocracy 的保障机制。

【L2 · 治理结构变化】 域名分布：gmail.com 183 封 > pks.im（Junio C Hamano 个人域）84 封 > pobox.com 78 封 > fastmail.com 31 封 > peff.net（Peff Ryan 个人域）14 封。个人域占比极高（pks.im+peff.net+mvdan.cc+antmicro.com 等），企业域仅 linux.microsoft.com（5 封）进入 Top 10。Junio C Hamano 作为唯一 maintainer 的主导程度从 pks.im 的活跃度可以侧面推断——这不是治理，而是权威的制度化。

【L3 · 新人加入】 新邮箱域名（首次出现）：anselmschueler.com、antmicro.com、arcor.de、fahldieck.de、fordltc.net、grrlz.net、his.com、lengemann.net、linux.microsoft.com、mvdan.cc。新人来源以个人域（.de、个人域名）为主，Microsoft 首次出现——暗示Git 在吸引企业级关注（可能是 Git LFS 或 Azure DevOps 相关贡献）。

📌 开源之道判断 Git 的治理是自发秩序的极限形态：无正式制度、无基金会、无 TC、无 RFC 流程，全靠 Junio 一人 20+ 年的权威与社区默契。Coase 企业边界理论的极端案例——制度成本趋近于零，单点风险趋近于无穷。与 lkml 的多 maintainer 分布式治理对比：lkml 的 bus factor 是数十人，Git 的 bus factor 是 1。与今日 Kafka KIP-1318（MCP Server for Apache Kafka）的讨论形成对照——Kafka 选择协议扩展 + 制度化讨论，Git 选择代码直接进入 + Junio 权威裁决，两种路径各自合理，但不具有可迁移性。

项目：Agentic AI Foundation (AAIF) + MCP 生态 数据范围： 2026-08-25 当日

【L1 · 项目脉搏】

• goose（Block 捐出）：⭐ 53,389（+472），🐛 243，本周活跃
• AGENTS.md（社区驱动规范）：⭐ 23,842，🐛 168，已 166 天无 Push——规范冻结还是维护失能？
• agentgateway：⭐ 4,515，🐛 328，本周活跃（🐛/⭐ 比率 0.07，早期 adopter 问题密度信号）
• MCP 生态：servers ⭐ 89,832，python-sdk ⭐ 24,111，typescript-sdk ⭐ 13,244，今日均有 Push

【L2 · MCP 治理演化】 MCP spec 版本：2026-07-28（已 1 个月未更新，稳定期）。mcp.directory 生态：2,303 个 Server / 1,907 个 Publisher。Publisher 分布中，Top 10 全部是个人/社区驱动（clauxel 16、cyanheads 14、spences10 11），企业 Publisher 仅 Cloudflare（9）、Microsoft（8）、Google（6）、Anthropic（5）进入，企业生态占比约 15%。中国区 Publisher 首次明确：gongrzhe（个人，9 个 Server）和 aliyun（阿里云，9 个 Server）。合规关键词命中：0/10 页——协议层完全无视合规概念，“协议不管合规"的分层设计稳定。

【L3 · 社区参与】 AGENTS.md 的 166 天静默是核心观察信号。一个社区驱动的 Agent 行为规范文档，在达到 2.3 万星后陷入停滞——这不是失败，而是规范的自然冻结：当规范足够稳定，更新频率下降是健康信号。但需与 goose 的持续活跃做对照：Block 的 goose 是"企业维护 + 基金会伞下”，AGENTS.md 是"社区发起 + 无企业支持"——前者有持续资源注入，后者靠自愿维持。AGENTS.md 的维护模式是否可持续？ 这是一个开放问题。

📌 开源之道判断 AAIF 的制度实验意义在于：它证明了 LF 子基金会的第三种治理形态——不是 lkml 的自发秩序，也不是 ASF 的 PMC 委员会，而是"企业把核心基础设施捐入基金会 + 社区自发生长规范 + 协议层与合规层完全分离"的复合结构。MCP 生态 85% 个人 Publisher 占比是社区主导的真实信号——不是企业赞助的假象，而是真正开放的协议生态。AGENTS.md 的静默与 goose 的活跃形成张力：一个是"规范的生命周期"问题，一个是"企业赞助的生命周期"问题，开源的两种可持续性路径在此分叉。MCP Con China（9月6-7日，上海）的举办，让 AAIF 首次在中国落地——这是"开放协议 + 中国企业参与"的最新实证，值得持续追踪。

其他信号速览（1 句/项）：

• Apache Software Foundation：Incubator 本月讨论 [DISCUSS] 三个议题——Aegis MCP Governance Gateway（将 MCP 治理网关引入 ASF 孵化）、Graduate Apache Iggy（消息队列毕业）、Pre New Podling: MEA；Kafka 11 个 [DISCUSS]，最显著是 KIP-1318 (MCP Server for Apache Kafka)——Kafka 主动对接 MCP 协议，消息队列进入 Agentic AI 时代。OpenDAL 0.58.1 发布（数据访问层持续迭代）。
• Kubernetes：v1.37.0-rc.1（2026-08-20）进入准稳定候选，7 日 commits 8（低于均值 149），处于发布窗口期正常减速。v1.34/1.35/1.36 三条 LTS 并行维护。
• vLLM：v0.27.1（2026-08-11），周均 306 commits 高速增长；PyTorch Foundation 正式项目，“基金会收编"路径样本。
• SGLang：⭐ 32,380，🐛 4,935，周均 100 commits；原生社区自治路径，与 vLLM 的同领域制度分野——一个是基金会制度化，一个是社区自治演化。

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

📌 Project Pulse 数据源声明： Linux Kernel 数据来自 lore.kernel.org/lkml 邮件列表（7 日 12,116 封）；Git 数据来自 lore.kernel.org/git（当日 433 封）；AAIF/MCP 数据来自 aaif.io + GitHub API + mcp.directory；ASF 数据来自 lists.apache.org（PonyMail JSON API）；K8s/vLLM/PyTorch/SGLang 数据来自 GitHub API。所有数据为公开信息，分析视角参考适兕开源经济学知识体系（Coase、Williamson、Acemoglu、North、Ostrom），仅供参考。