一

2021 年 2 月 19 日，瑞典斯德哥尔摩郊外的一个家里，Daniel Stenberg 打开自己的 inbox。这天他收到一封邮件，主题是 “I will slaughter you”——我要屠杀你。

发件人不知名。邮件内容直接、具体、带威胁。

Stenberg 那时候已经维护 curl 25 年。curl 是一个命令行 HTTP 客户端——它是几乎所有现代设备里都有的小工具，被估计部署在 200 亿到 100 亿台设备上：每台 Mac、每台 Linux 服务器、每台 Android 手机、每个 Tesla、每个汽车娱乐系统、每个家用路由器，几乎所有内嵌 Linux 的设备1。

Stenberg 1996 年开始写 curl。当时他没想到这个小工具会被部署到这种规模。他在不同时期受雇于不同公司，但 curl 一直是他的个人项目。2019 年他加入 wolfSSL——一家做嵌入式 TLS 库的小公司——作为 curl 项目的“正式” maintainer。wolfSSL 支付他部分薪水维护 curl，作为商业服务的一部分。

但他仍然是 curl 唯一的全职 maintainer。所有 release、所有重大决定、所有重大安全响应——都是他一个人。

那天的 “I will slaughter you” 邮件不是第一封。Stenberg 在他的个人 blog 里维护着一个 “Emails” 归档页——记录他多年来收到的有趣或有威胁的邮件。归档里有各种东西：来自非英语母语国家的奇怪英语 bug report，来自青少年的“我的电脑被黑了请帮帮我”求救信，来自高级用户的精彩技术讨论。但也有：来自陌生人的死亡威胁、来自自称政府机构的伪造邮件、来自被骗者的“为什么你的 curl 让 hackers 偷了我的钱”指责2。

那天的邮件不一样在于它的直接性。Stenberg 当天写了一篇 blog post，标题就是 “I will slaughter you”。他公开了邮件大部分内容（隐去发件人）。他没有报警——他说他选择把这件事公开，是因为他想让外界知道开源 maintainer 长期暴露在什么样的环境里3。

读那篇 blog 让人想起一个简单的事实：Daniel Stenberg 是世界上几个 most under-appreciated 工程师之一。他维护的代码每天在几十亿台设备上运行；他的工作让 https 在每个家用设备上工作；他没有从这种规模中得到任何匹配的金钱回报。然后他在自己家里收到死亡威胁邮件——也没有匹配的支持系统。

二

2025 年 5 月，Stenberg 开始尝试一个新政策：对所有 AI 生成的 bug bounty 提交立即封禁4。

背景是 2024-2025 年开源世界面对的一个新现象：AI slop——AI 生成的、看起来专业但完全错误的 bug 报告。

事情是这样的。HackerOne 等 bug bounty 平台让安全研究员可以为发现漏洞获得奖金。curl 有一个 bug bounty 项目，2019 年成立，6 年里累计支付了大约 $86,000——主要给少数几位真正有发现的研究员。这是一个相对成功的项目。

2024 年下半年，提交量开始急剧上升。Stenberg 注意到提交的“质量分布”在变化：大量看起来技术性很强、引用具体代码片段、使用专业术语的报告——但仔细看每一份都是错的。它们描述的“漏洞”在代码里根本不存在。

研究后发现：有人在用 ChatGPT、Claude、Gemini 等大模型批量生成 bug 报告，然后用脚本提交到 HackerOne。生成报告几乎不需要时间。如果碰巧蒙对了一个，就能赚到几千美元。蒙错了也没成本。

到 2025 年 7 月，curl 项目的提交量已经是正常的 8 倍。Stenberg 估计大约 20% 是 AI slop——技术看起来对，但里面没有真东西5。

5 月那次尝试——“对 AI 提交立即封禁”——没解决问题。因为没办法可靠地识别 AI 生成的内容。Stenberg 试着用各种 heuristic（“这个用了 LLM 的典型句式”“这个引用了不存在的代码行”），但工作量本身就压垮了他。

2026 年 1 月 21 日，Stenberg 在 blog 上发了一篇标题为 “End of curl bug bounty” 的文章。他宣布：经过 6 年和 $86,000 总支出，curl 的 bug bounty 程序到此终止6。

他写道：

“We need to make moves to ensure our survival and intact mental health.”

这是 2026 年这个时刻一个值得停下来读的句子。

curl 没有失败——它仍然是地球上部署最广的 HTTP 客户端。Stenberg 没有放弃维护——他仍然每天工作。但他被迫关闭一个对 curl 安全有帮助的项目——bug bounty 本来的目的是让外部研究员有动力发现 curl 的真实漏洞——只为了保护团队的心理健康。

curl 团队的应对不是“扩张”——他们没有招更多人。他们也没有“接受现状”——继续被淹没。他们选择撤退——关掉一个已经无法承载的协作渠道。

这是 2024 年后开源维护者的新常态。在 xz 后门那种“被国家级 social engineering 攻击”的极端之外，还有一种更普遍的状况：被 AI 工业化骚扰淹没。前者一年发生一次或几次，后者每天发生。

三

Lasse Collin 是另一种处境。

Collin 是芬兰人，长年生活在芬兰某个城市（公开材料里他自己不强调具体位置）。他是 xz Utils 的主创和长期单人维护者。在 xz 后门事件之前，外界对他知之甚少——他不写 blog，不上电视，不参加大会，他的 GitHub profile 没有头像。

但通过 xz 后门事件，他成了一个不情愿的公众人物。

我们在第 4 章已经看到了 Collin 2022 年 6 月 29 日那封关键邮件：

“my ability to care has been fairly limited mostly due to longterm mental health issues, but also due to some other things.”7

这是事件发生 2 年前 Collin 自己写的话。它在事后被 Russ Cox、Securelist 等团队反复引用——作为 Jia Tan 之所以能成功 social engineering 的关键节点。

但读这段话不是为了责备 Collin。读它是为了理解一个事实：Collin 做的所有事都是合理的。

他承认自己 mental health 状态——这是诚实，不是疏忽。 他在多方施压下接受帮助——这是开放，不是软弱。 他对 Jia Tan 的“真实贡献”做出 reasonable 的信任评估——这是正常的开源协作。 他作为单人维护者承担过劳——这不是他的问题，是结构的问题。

Russ Cox 在他的 timeline 复盘里有一段非常清楚的话：他不是疏忽的维护者。他做的所有事都符合开源协作的最佳实践。问题是当对手是国家级行为者时，“最佳实践”不够8。

xz 后门事件之后，Collin 发了一份简短的公开声明，承认 Jia Tan 利用了他的 mental health 状态。他没有自我责备，但也没有把全部责任推给攻击者。他说：

“I have not been involved with the work of Jia Tan beyond reviewing some commits.”

然后他继续做自己的工作。Tukaani 组织恢复了正常运作，社区成员（不是 Collin 个人）做了清理和补救。xz Utils 项目至今仍在维护。Collin 仍然是名义上的 maintainer，但承担较少日常事务。

Collin 没有从这件事中获得任何金钱回报。他没有出书。他没有接 media 采访。他没有“事件后转型为安全专家”。他做了他的代码工作——这是他过去 20 年一直在做的事——只是这次他成了世界上“国家级 social engineering 受害者”的最知名案例。

如果 Stenberg 是“被骚扰但坚持工作”的版本，Collin 是“被利用但坚持工作”的版本。两种处境的共同点是：他们没办法保护自己——开源生态没有给他们提供任何系统性的保护机制。

四

Andres Freund 在 xz 后门事件中扮演的角色完全不同。他不是受害者——他是发现者。

Freund 在 Microsoft 工作。具体岗位是 PostgreSQL 上游核心开发者——这意味着他被 Microsoft 雇佣的工作之一就是维护开源 PostgreSQL。这是 Microsoft 跟很多大公司一样的开源参与模式：付员工的薪水让他们贡献给特定开源项目，作为公司基础设施投资的一部分。

但 Freund 不是安全研究员。他是性能工程师。他研究 PostgreSQL 在不同硬件上的性能特征，写复杂的 benchmark，找瓶颈。这是一个相当 niche 的专业方向9。

3 月 28 日那天他不在做 xz 研究——他在做 PostgreSQL benchmark。SSH 慢 400ms 是个完全意外的发现。

Freund 在 Mastodon 后续复盘里有几段重要的话。一段是说他“运气”——如果他不是性能工程师，他大概率不会注意到这个延迟；如果他在做其他任务，他大概率不会停下来追究10。另一段是说他不是安全研究员，发现是偶然的，制度上没有任何机制能保证下一个 xz 类型的攻击也会被发现。

这是 Freund 在媒体光环下保持的清醒。xz 事件后，他成了全球安全圈的英雄人物。但他自己反复强调：他做的事任何注意细节的工程师都能做；问题是大多数工程师在大多数时间没有停下来注意。

Freund 在 Microsoft 的工作并不要求他做这种“全开源生态扫描”。Microsoft 雇他维护 PostgreSQL，不是当 xz 守卫者。他做的额外工作——周末和工作日晚上花时间挖那 400ms 异常——是他个人选择。Microsoft 后续给了他认可（不是金钱奖励，是声誉），但没有任何制度机制说“以后类似情况会有专人做”。

这点也很重要。如果 Freund 是被 Microsoft 雇来做 OSS 供应链安全的——比如 OpenSSF Alpha-Omega 项目下的全职安全工程师——那么 xz 发现是工作产物。但他不是。他是性能工程师。他发现 xz 是偶然。

下一个 xz 是不是会被发现——取决于又有没有一个 Freund 类型的人，恰好碰上一个让他停下来挖的异常。这种“偶然依赖”是当前 OSS 安全模式的根本脆弱性。

五

Ralph Goers 是另一种状态。

Goers 是 Log4j 的初始作者之一，2001 年开始写代码。他的全职工作是另一家公司的软件开发——他在那家公司做的工作跟 Log4j 没关系。Log4j 是他工作之余的志愿者贡献11。

2021 年 11 月 24 日，Chen Zhaojun 向 Apache 报告 Log4Shell 漏洞。接下来三周，Goers 和另外两个志愿者维护者（Volkan Yazici、Gary Gregory）在自己的业余时间内紧急修复漏洞。三个人，三周，全球紧急 patch 几亿设备。

12 月 11 日他发了那个被反复引用的声明：“The Apache Log4j project is being maintained by three people who volunteer their time.”12

这句话的言外之意是：我们没有承担义务。Apache Log4j 是 Apache 2.0 license——你可以拿去做任何事，没有保证。Goers 等三人维护这个项目是 unpaid 个人选择。当 Log4Shell 出现时，他们当然会修复——但他们没有义务在 24/7 待命，没有义务向企业承担 SLA。

讽刺的是，他们实际上做了那种 24/7 紧急响应。三人志愿者团队在 Log4Shell 之后两周里基本没睡觉。他们发布了 2.15.0、2.16.0、2.17.0——三个相继的紧急 release，因为每个 release 都被发现仍然有边缘案例需要修补。

Log4Shell 之后，Apache 软件基金会公开呼吁企业回馈。一些公司响应了——Comcast、Amazon、Microsoft 等捐了款。OpenSSF Alpha-Omega 在 2022 年成立时直接以 Log4Shell 为契机，把 Log4j 列入第一批资助项目。但效果有限。三年后的 2024 年，Log4j 仍然由很少几个志愿者维护——只是其中一些人现在有部分 Tidelift 或 Alpha-Omega 的资助。

Goers 自己 2022 年后接受过一些采访，他表达的态度是相对平和的。他不抱怨——他维护 Log4j 是因为他相信这件事重要。他也不要求大公司必须捐钱——他相信开源的根本是自愿。但他确实承认：单人或小团队维护关键基础设施是不可持续的。最让他担心的不是被攻击，是 burnout——某天他自己累到不想再做了，下一代维护者没有自然接手13。

六

把这四个人放在一起看，会注意到一些共同的事，也会注意到一些不同的事。

共同点：

  • 都是中年男性（Stenberg 50+，Collin 40+，Freund 40+，Goers 50+）
  • 都是欧美中产职业背景（Sweden、Finland、Germany 后裔美国、美国）
  • 都不是被传统媒体描述为“明星工程师”——他们的名字在 mainstream IT 报道中很少出现
  • 都被现有 OSS 资助机制少量覆盖（Stenberg 通过 wolfSSL + STF；Collin 此前少量捐款；Freund 通过 Microsoft 工资；Goers 仅部分 Tidelift）
  • 都长期暴露在“被全球数百万到数十亿设备依赖”和“个人没匹配支持”的张力中

不同点：

  • Stenberg：被骚扰但商业关联较强（wolfSSL + STF）。撤退策略：关闭 bug bounty
  • Collin：被国家级 social engineering 利用。撤退策略：减少日常事务，让社区接管
  • Freund：被卷入英雄叙事但拒绝接受。撤退策略：明确“我是性能工程师不是安全研究员”
  • Goers：被结构性挤压（三人维护数亿设备）。撤退策略：坚持自愿模式，呼吁但不强求企业责任

四种处境，四种不同的“应对方式”。但都不是扩张——都是某种形式的撤退或维持现状。

这跟主流叙事里“开源运动一直在扩张、在胜利”很不一样。从总体看（投入金额、Star 数量、企业采用），开源确实在扩张。但从个体维护者层面看，多数人在撤退——关闭功能、减少工作量、转向自动化、寻求其他工作。

为什么？因为扩张和撤退是不同的视角。企业资助和大公司贡献者数量在增长，但同时小项目维护者的工作复杂度在剧烈上升——AI slop、合规压力、安全期望、用户增长。两条曲线都在升，但单个志愿者承受不住第二条曲线。

七

D. Richard Hipp 代表了一种异类策略。

Hipp 是 SQLite 的创建者和长期维护者。SQLite 是世界上部署最广的数据库引擎——估计在 1 万亿个实例。每台 iPhone、每台 Android、每台 Mac、每个浏览器、每个机顶盒、每个航空电子系统都有 SQLite。它的部署密度可能是地球上任何软件之首。

但 SQLite 不是由 SQLite Foundation 维护，也不是由 Apache Foundation 维护。它由 Hipp 自己的公司 Hwaci（Hipp, Wyrick & Company, Inc.）维护。Hwaci 是一家小公司——大概 5-7 个员工——所有员工都全职维护 SQLite 和提供商业支持。

Hipp 拒绝传统开源基金会模式。他不接受外部捐款（接受了也不知道怎么算），不发 GitHub Sponsors，不申请 Sovereign Tech Fund。Hwaci 的收入来源是商业 SQLite 支持合同——大公司付钱给 Hwaci，获得专业支持、合规帮助、定制开发。这个收入模式让 Hwaci 持续维护 SQLite 而不需要任何捐赠14。

2018 年 10 月，Hipp 做了一件让开源世界震惊的事。当外部压力（主要来自一些企业客户）要求 SQLite 采用一份正式的 Code of Conduct 时，Hipp 选了一份非常特殊的文档作为 SQLite 的 “Code of Ethics”：圣本笃修道院规则中“善行的工具”那一章——一份 6 世纪基督教修道院传统的伦理准则15。

文档要求开发者“不要杀、不要奸淫、不要诅咒、不要骄傲、要爱上帝”。

这件事在开源社区引起强烈反应。多数 maintainer 觉得这违反了开源的多元包容。Hipp 自己解释：他不要求用户信仰基督教，但他相信现代 Code of Conduct 文档（Contributor Covenant 等）的措辞太“vapid”（空洞）；圣本笃规则有一种“直接性”是他需要的16。

8 天后，SQLite 项目下了 “Code of Ethics”，改为采用 Mozilla 社区参与指南。但 Hipp 保留了原文档作为可选阅读。

这件事的意义不只是宗教信仰争议。它代表了一种 Hipp 与众不同的姿态：他不愿被现代企业开源文化吸收。他自己开公司、自己定规则、自己决定 SQLite 的方向。当外部期望（基金会化、专业化、合规化）跟他的偏好冲突时，他选择自己的方向。

这种姿态有代价——SQLite 不获得 Linux Foundation 那种企业网络效应；它不被列入 OpenSSF 的“关键项目”清单（虽然按部署规模它显然是最关键的之一）。但 Hwaci 模式保证了 Hipp 个人和 SQLite 项目的独立性。他不被任何公司或基金会的政治影响。

Hwaci 是当代开源世界一个独特的存在——一个小公司，做最关键的项目之一，自给自足，避开所有大型机构政治。这种模式不可能 scale——不可能每个 maintainer 都开一家公司——但它存在本身证明了：还有其他可能性17。

八

到 2024 年，Tidelift 做了一份相对系统的 maintainer 调查。覆盖 400+ 活跃 maintainer。一些关键发现：

  • 25% 的 maintainer 从 GitHub Sponsors 等捐赠程序获得收入（2021 年 16%，2023 年 24%，2024 年 25%）
  • 19% 从 Tidelift 获得收入
  • 全职靠开源维护工作生活的 maintainer 比例不到 10%
  • 多数 maintainer 在维护一个或多个被广泛部署的项目，同时全职在另一份工作
  • 大多数 maintainer 没有清晰的 succession plan——他们不知道如果自己停止维护，谁会接手18

这些数字看起来不算特别糟糕——25% + 19% 有部分资助听起来还可以。但要看分布：得到资助的多数是少数最知名项目（curl、PostgreSQL、Drupal、Linux 内核子系统等）。长尾的小项目——那些“内布拉斯加的某个人”项目——基本没有覆盖。

Tidelift 的研究还有一个让人想停下来的发现：maintainer 平均年龄在缓慢上升。Open Source maintainer cohort 在 2010 年代多数是 30-40 岁的工程师；2024 年这批人仍然在维护——意味着他们现在是 40-50 岁。新一代 25-35 岁的工程师没有以同等比例进入维护角色19。

为什么？多种因素：

  • 新一代工程师更早进入大公司，没时间做志愿贡献
  • 现代 SaaS 工作模式让“业余维护开源”更困难
  • AI slop 等新现象让维护变得不愉快
  • 现代开源项目的协作门槛比 2010 年代高很多（CI、test、code review、issue 流程都更繁复）

如果这个趋势继续，10-15 年后，主流开源项目的 maintainer cohort 会出现自然衰减。Linux 内核现在有约 3000 个活跃 maintainer——其中相当一部分是 50+ 岁。Apache 各项目的 PMC 成员也类似。

这是开源运动面对的一个非常长期但非常重要的问题：它的物质基础是一代特定的工程师。这代人有特定的成长背景（90s 末-00s 初的互联网开源浪潮）。当他们退休或转行，没有自动机制保证下一代填补空缺。

九

现在把所有这些放在 xz 后门和 GitHub 2019 制裁的背景下看。

xz 攻击者选了 Lasse Collin 作为 target，不是因为 Collin 是“弱”——是因为 xz Utils 在“被全球依赖”和“个人维护”之间不平衡。这种不平衡不是 Collin 的错——它是开源生态的结构性特征。

GitHub 2019 锁伊朗账号也类似。被锁的伊朗开发者不是错的——他们用 GitHub 是自然选择。但他们暴露在“全球协作平台 + 美国制裁法律”的张力中。这种暴露不是个人选择——它是制度结构强加的。

把这两个东西放在一起，是这本书想说的核心：开源运动用 40 年时间建立了一个全球协作生态。这个生态依赖的是一群具体的人——维护者。但这群人现在同时面对几种压力——AI slop、国家级攻击、合规、骚扰——而支撑他们的基础设施远远不够。

如果维护者撤退，开源会怎样？

它不会一夜消失。Linux 仍然会被维护，Apache 仍然会运作，curl 仍然会工作。但长尾会消失——那些不知名的小项目、被广泛依赖的小库、被遗忘的关键组件——会一个个失去维护。当 xkcd 2347 的“内布拉斯加的某个人”决定不再维护时，被依赖的更大系统会缓慢侵蚀。

这个过程已经开始了。2024 年的 curl bug bounty 关闭只是一个早期信号。更多类似撤退会在 2026-2030 年发生。每次撤退本身不大——只是一个项目关一个功能、缩小一部分范围。但累计起来，会重塑开源的实际可用性20。

十

读到这里有人可能会问：那么开源运动应该怎么应对？

简单的回答还是：没有简单答案。

事实层面有几个方向被尝试中：

1. 政府资助。德国 Sovereign Tech Fund 是最明确的范例。它不是“补贴”——它是政府承认开源关键基础设施是公共物品，需要公共资助。这个模式 2022 年起在德国、荷兰、法国都在推。规模仍然小——总加起来每年几千万欧元——但方向是对的21。

2. 企业责任规范化。一些大公司（Microsoft、Google、AWS）通过 Alpha-Omega 等机制承担“关键基础设施贡献”责任。问题是这种贡献不是合同义务——是企业 PR 决定。如果哪天财务紧张，预算就会被砍。

3. 商业模式。Hwaci（SQLite）、wolfSSL（curl 部分）、Tidelift（中介）等代表不同的“开源 + 商业”组合。每个都解决一部分问题，但都不可 scale 到覆盖所有 maintainer。

4. 协作工具改进。Sigstore、SLSA、Reproducible Builds 让供应链更可验证——这能减轻 maintainer 的安全审计负担。GitHub Copilot、Cursor 等 AI 工具能让 review 速度提升。但同样的 AI 工具也是 AI slop 的来源——双刃剑。

5. 接受新现实。最现实的方向是：开源运动接受自己不再是“全球公地”，而是几个不同主权领地下的多个协作生态。Linux Foundation 在美国法律下运作，OpenAtom 在中国法律下运作，俄罗斯有自己的本土 forge，欧盟有 STF 的资助。每个生态有自己的规则，跨生态协作更困难。

这是这本书在第二卷想呈现的图景——具体的人，具体的处境，没有简单的英雄或反派。Stenberg 在他家里继续维护 curl。Collin 在芬兰继续做减少了的工作。Freund 在 Microsoft 继续做 PostgreSQL benchmark。Goers 在他全职公司继续工作，业余时间维护 Log4j。

他们都不在 Microsoft 总部签战略会议。他们不在国会作证。他们不在白宫的 OSS 圆桌讨论。但他们仍然是这个生态实际运转的人。

下一章我们要看的是这些维护者面对的另一个力量——不是 social engineering，不是 AI slop——是 国家制裁穿透代码。这是 GitHub 2019 和 Linux 2024 的故事。

References

  1. curl 项目 stats 与部署规模估计。curl 官方页面声明 “the curl project… is used in billions of installations”。

  2. Daniel Stenberg 的 Emails 归档页：https://daniel.haxx.se/email/toc.html

  3. Daniel Stenberg blog 2021-02-19: “I will slaughter you”. Link →

  4. Open Source Security Podcast 2025-05: “Curl vs AI with Daniel Stenberg”. Link →

  5. 同上。Stenberg 在播客中描述 2025 年 7 月提交量 8 倍、约 20% 是 AI slop 的数字。

  6. Daniel Stenberg blog 2026-01-21: curl bug bounty 终止公告。包括“We need to make moves to ensure our survival and intact mental health” 引述。

  7. Lasse Collin 2022-06-29 邮件原文。从 xz-devel mailing list 归档；Russ Cox 的 timeline 完整引述。Link →

  8. Russ Cox: “Timeline of the xz open source attack”. 关于 Collin 不是疏忽的明确表态。

  9. Microsoft Engineering blog: Andres Freund 个人简介（PostgreSQL upstream core developer）。

  10. Andres Freund 在 Mastodon 与 oss-security 的 2024-04 复盘。强调“I am not a security researcher”和“luck”的细节。

  11. Wikipedia: Log4Shell. 包括 Ralph Goers 全职工作在另一家公司的描述。Link →

  12. Ralph Goers 2021-12 公开声明，多家媒体引述。Bloomberg、TechCrunch 都有报道。

  13. The Register 2024-09-18: “Open source maintainers underpaid and going gray”. 包括 Goers 等人对 burnout 的关注。Link →

  14. SQLite About 页面与 Hwaci 公司介绍。Hwaci = Hipp, Wyrick & Company, Inc. SQLite 是 public domain，但商业支持服务付费。

  15. The Register 2018-10-22: “SQLite creator crucified after code of conduct warns devs to love God”. Link →

  16. Christianity Today 2018-10: “Eat, Pray, Code: Rule of St. Benedict Becomes Tech Developer’s Community Guidelines”. 包括 Hipp 关于“vapid”的评价。

  17. Packt Pub: “SQLite adopts the rule of St. Benedict… drops it to adopt Mozilla’s community participation guidelines, in a week”. 关于 SQLite Code of Ethics 的退让过程。

  18. Tidelift 2024 maintainer survey. 详细数据：25% 从 GitHub Sponsors 等程序获得收入；19% 从 Tidelift 获得收入。Link →

  19. The Register 2024-09-18: 同 ref-13。包括“open source maintainers going gray”的人口学观察。

  20. 2025-2026 多个开源项目缩减或关闭功能的案例：curl bug bounty 关闭、Drupal 限制非赞助贡献者 access、多个 npm 包公开“放弃维护”声明。

  21. Sovereign Tech Agency 官方页面。包括 2022-2024 资助项目清单（curl、Drupal、Gnome、openSSH、systemd 等）。Link →

  22. Tidelift 2018 早期资助承诺：$1 million 给 open source maintainers。

  23. Vice: “The Internet Was Built on the Free Labor of Open Source Developers. Is That Sustainable?” 早期记录开源 maintainer 经济问题的深度报道。Link →

  24. Rust Foundation 2021-11 moderation team resignation. 包括开源 governance 危机的另一面。Link →

  25. InfoWorld: “How do we fund open source?” 综合分析多种资助模式。Link →