← 研究笔记English
技术研究 · 2026-07-27 · 11 分钟阅读 · 考据

开源项目和公益项目真正的死因:名字、域名、发布权、所有权

关于「怎么让一个项目长期活着」的通行答案是找钱、防倦怠、建社区。按证据看,这三条都不是主因。真正会把项目杀死的,是你把不可 fork 的四样东西攥在了一个会换工作、会疲惫、会消失的人手里——而 2026 年出现的新变量,只是把负载曲线改陡了,没有改变这个结构。

研究声明

本文审查「开源项目和公益项目如何长期活着」里结构层的那一半:权限、继承、信任与收场。全部数字尽量抓一手来源:论文原文 PDF、法规与官方 changelog 全文、npm 官方 API、维护者本人的博客与公告。每条结论标了三档:【稳】= 一手来源逐字核过,未被实质动摇;【已收窄】= 方向成立,但流传的表述过宽或数字有误,写的是修正版;【判断】= 机制上讲得通、暂无直接实证,是推论。钱(赞助、公共资金、募捐合规)与法律形式是另一半,另文处理。

一、结构层:不可 fork 的四样东西

「创始人一走就死」这句话在开源语境里几乎总是被误读。MIT 和 Apache-2.0 已经保证任何人都能拿走代码继续做——死的从来不是代码。真正不可 fork 的是四样:

  1. 包名 / 命名空间(npm、PyPI、crates 上你占着的那个字符串)
  2. 域名与 DNS
  3. 发布权(能把修好的版本推到已装机用户手里的能力)
  4. 组织所有权(GitHub org 的 owner 席位)

公益侧同构,只是换成:法人主体、公募资格(或挂靠关系)、捐赠人名单、账本的连续性

下游对一个包名或域名的信任是继承的。没有人会在维护者换人时重新做尽调,registry 和浏览器也不会提示这件事发生过。所以「转手」= 把一份已经建立好、覆盖数万下游的信任凭证,整体转让给一个新主体。

这解释了为什么域名千万别「让它过期」【稳】:过期等于进 drop-catch 市场,攻击者不花钱就能拿到,比卖掉更糟。polyfill.io 是买卖型案例——2024 年 2 月域名被卖给几乎无业界记录的 Funnull,6 月起注入恶意代码把用户重定向到博彩站。顺带纠正一个流传很广的错误:原作者 Andrew Betts 从未拥有过该域名(服务由 Financial Times 运营),他事后的表态只是「现代浏览器已不需要它,别再用」。

二、bus factor 的真实位置

【已收窄】流行项目里 bus factor ≤2 是常态,约 46–65%。 Avelino 等对 133 个 GitHub 热门系统的 truck factor 测算:TF=1 占 34%、TF=2 占 31%,合计 65%;Metabase 用 truckfactor 库对 star 前 1000 仓复算(约 95% 可算)得「将近一半 ≤2,只有 10% ≥6」。常被引用的「74%」是错的。

同一份 Metabase 复算还有一个反直觉发现:star 数与 bus factor 无相关——出名不等于安全。

【判断】但这些百分比测的全是「谁写了超过半数文件」,没有任何公开数据集测过发布权的集中度。 GOVERNANCE.md 上写着 5 个 maintainer、实际只有 1 人持 npm publish 权限的项目,可发布口径的 bus factor 仍然是 1。这是本文最核心的重构,但必须标成推论——它成立的理由是机制而非数据。

另外要给指标降温:Avelino 论文自己的效度检验对高置信不利——被问「失去 TF 作者你的项目会不会有麻烦」时,39% 同意、43% 不同意。维护者本人多数不认这个指标的致命性。

三、2025–26 平台层剧变:「守好你的密钥」已经是过期建议

关于继承,流传最广的建议是「发布签名密钥永不移交」。这条在 2026 年基本失效了【稳】:

控制点因此从「谁拿着密钥」转移到了「谁能合并到发布分支 / 谁能批准那个 workflow」。

直接推论:.github/workflows/** 必须单独设 CODEOWNERS 并要求 review。给了 merge 权而没锁 workflow,等于已经静默地把发布权一起给了——任何能改一行 release workflow 的人都能让你的可信发布身份签一个你没审过的产物。

也要知道它解决什么【已收窄】:trusted publishing 防的是长期 token 被偷(这才是基率最高的那类事故——2025-09-08 chalk/debug 等 18 个包被投毒,入口是伪造 2FA 重置邮件骗走用户名、密码和一个活的 TOTP;2025-09-14 Shai-Hulud 蠕虫下架 500+ 包),它不防恶意继承者。所以真正的第一优先级其实是把 registry 与 GitHub 账号的 2FA 从 TOTP 换成 passkey/硬件密钥——WebAuthn 绑 origin,同一封钓鱼邮件无效。次序不能颠倒:GitHub 账号可钓的情况下上 trusted publishing,等于把攻击者从「偷一个 token」升级成「拿到一条常驻发布流水线」。

四、xz 的真实时间线:为什么时间闸拦不住

「设一道 6 个月观察期 + 5 个非 trivial PR 的门槛」是最常见的继承风控建议。按 xz(CVE-2024-3094)的实际时间线,这道闸会按时放行攻击者【稳】:

通行说法实际(Russ Cox 逐条时间线)
先做 12 个月贡献攒信誉,再动手首个 patch(2021-10-29)之后 5.8 个月马甲就开始施压,贡献与施压是并行的
拿到 commit 权后再等半年才拿发布权2.6 个月(2022-12-30 → 2023-03-18 打出 v5.4.2)
后门藏在 tarball 里,git 是干净的载荷 blob 就在 git 里(伪装成损坏的测试数据,2024-02-23),tarball 独有的只是把它接进构建的 build-to-host.m4 胶水
——首个 patch → 带后门的发布 ≈ 28 个月;拿到发布权后还干净发布了约 11 个月

所以数字闸门唯一的真实用途,是给你一句「这是项目政策,不是针对你」的拒绝话术。要如实这么说,别把它包装成安全控制。

真正有效的只有两条:发布产物必须由 CI 从 git tag 可复现地构建(消灭 git 与 tarball 的差值,把注入面逼回公开可审计的地方),以及任何个人单独无法放行一次发布

一条应当删掉的流行建议

有一类建议主张「把任何催你找 co-maintainer 的人当作攻击信号」。这条应当删掉:基率约 1%,而代价是系统性压制继任规划,与「bus factor=1 是长期存活头号杀手」直接冲突。正确的表述是一个时间轴不变量——无论谁施压、无论理由多正当,权限升级的时钟不加速;对压力的回应是流程,不是对人的判断。

五、2026 年的新变量:这一节最该改变判断

curl 的完整弧线(通行叙事只讲了前半段)

时间发生了什么
2025-07约 20% 的提交是纯 AI slop;有效率从历年 >15% 跌到 <5%;7 人安全团队,每份报告牵动 3–4 人、每人 30 分钟到 1–3 小时
2026-01-31关停赏金(累计付出 >$100,000、确认 87 个真漏洞;钱一直是 Internet Bug Bounty 出的),同时把平台从 HackerOne 换到 GitHub 私有漏洞报告
2026-02-25「洪水明显退潮」——但作者本人明说无法区分是砍钱的效果还是搬家的效果;同日宣布搬回 HackerOne(GitHub 缺约 15 项必需功能),自评这次搬家是「a mistake」
2026-03 起零赏金 + 已搬回原平台,进入「high-quality chaos」:平均每天 >1 份报告,是 2024 年的 4–5 倍、2025 年的 2 倍,质量却是史上最高
2026-068.21.0 单版本发布 18 个 CVE(项目纪录);维护者公开写道可能很快得减少工作时间
2026-07整月关闭漏洞接收通道,发版推迟两周
砍钱只杀死「假报告套利」,不解决「真报告洪水」。 第二波不由钱驱动——署名、CVE credit、简历、安全工具厂商的能力展示就够了。更难受的是:倦怠风险在撤钱之后反而更高,因为现在每一份都是真的,你没有正当理由拒收。

一个可以兜底的反直觉好消息:curl 近年新发现的漏洞几乎都被评为 LOW 或 MEDIUM,最近一个 HIGH 级 CVE 是 2023 年 10 月。AI 大规模找到的是长尾小问题,不是灾难级洞——CVE 数量暴涨不等于产品在变危险,别被数字吓到而过度反应。

比 slop 更致命的:用户不再进社区

【稳】用量创新高和漏斗归零可以同时发生,而且你盯的所有指标都是绿的。

落地推论:把收入入口和 PV 解耦(变现放在使用时刻——CLI 登录、运行时 license、托管服务、支持合同——不要放在「来官网看文档的人里有 x% 会买」);把招募入口也解耦(贡献入口写进错误信息、CLI 输出、release notes,别指望有人逛到 CONTRIBUTING.md);并把「文档站独立访客 / 新提问数 / 首次贡献者数」做成月度看板并设下滑告警——Tailwind 的教训正是这条曲线足够平缓,不设阈值就发现不了。

闸门要建在身份层,不是「是不是 AI 写的」层

【稳】你无法可靠检测 AI 生成内容,但可以可靠地限制「陌生账号能消耗你多少注意力」。三个 2026 年已上线的免费开关:仓库级 PR 访问设置(2026-02-13,可完全关闭 PR 或限定只有 collaborator 能创建)、并发 PR 上限(2026-06,对无写权限用户封顶;Copilot 与其他 AI agent 开的 PR 计入配额,draft 不计,老贡献者可进 bypass list)、仅 collaborator 可创建 issue(2026-06-29)。

但前置条件必须写清楚【判断】:这套只在入站陌生 PR/issue 量已经超过你的 review 容量时净收益为正。样本全是 Homebrew、llama.cpp 这个量级的项目。低流量项目的真实约束是「没人来」,提前关闸等于直接砍掉贡献者漏斗顶部,与「防止创始人一走就死」的目标直接冲突。另外「仅 collaborator 可开 issue」的封锁面比字面更宽,会把真实用户的 bug 报告一起挡掉。

六、信任:公益特有,开源同构

【稳】把项目资金和个人财务混同,机制上等于「你只能用私生活回答质疑」。 钱进个人钱包后,「你有几套房」「你家里是不是换了新手机」变成了合法追问,而你没有任何制度性答案——因为流水里有你的私生活,你只能拒绝对账,而拒绝就是坐实

罗尔案(2016-11)是这个机制最干净的样本:最终腾讯将相关赞赏共计 2,525,808.99 元(另一口径 2,626,919.78 元)于 12 月 3 日 24:00 前原路退回。他没有被行政处罚、也没有被认定诈骗——但当年民政部门、人大法工委、平台、舆论对这件事的定性各说各的。真正的教训不只是「合法 ≠ 可辩护」,而是更狠的一句:钱进了你个人的钱包,定性权就不在你手里了。

【已收窄】信任崩塌的燃料通常是「被问到具体一笔时答不上来」,但要加一句:逐笔账本只能证明「没被偷」,证不了「该花的花了」。

所以逐笔账本必须配一条「未拨付资金的到期日 + 拨付条件 + 逾期怎么办」。而账本本身必须是「钱所在之处的副产品」【判断】——绝不要手搓一个需要你记得更新的页面,停更 11 个月的账本比没有账本更伤,它证明你有过纪律并失去了。

【稳】别把有限的钱先花在正式审计上。 ACFE《Occupational Fraud 2024》(1,921 起舞弊、损失约 31 亿美元):43% 由举报发现,外部审计只发现 3%——而 84% 的受害组织本来就有外部审计。审计是给监管和大额捐赠人看的合规资格证,不是探测器;探测器是「有人能开口说话」。一人项目的等效替代:给一个项目外可信第三方只读权限并公开写明「谁有只读权限」(这个声明本身就是威慑)+ 匿名质疑邮箱 + 每季度突击对账。

【判断】不要公开「管理费率」,要公开「一年要多少钱才能活」和「我给自己发多少钱」。 比率可以被重新计算,所以永远可争议;预算和薪水是事实陈述,不可争议。Babel 把维护者月薪直接写在公开博客上(Henry Zhu 全职基准 $11,000/月),争议一次性发生完,之后再没人拿它做文章。不写自己的薪水才是最大的雷——别人迟早用「收入 − 已知支出」倒推,届时任何数字都像贪污,因为你隐藏过它。

但也别把「公开亏空」当融资手段:Babel 那篇公开 $333,000 缺口的文章,同期动作是把三位维护者降到 $6,000/月;2026 年 7 月实测其 Open Collective 年收入约 $285k——五年涨了约 70%,仍然低于当年自述的那条线。公开亏空是诚实,不是渠道。

七、收场:归档不会赶走任何人

【稳,实测数字】2026-07-18~24 的 npm 官方下载 API:request 14,985,210 次/周——它 2020 年就把全部 126 个版本打了 deprecated 标记,六年后依然如此;moment 36,228,334;core-js 65,873,924。

你的退出必须假设用户永远不会读你的任何公告。因为根本没有人类在决策回路里——这个量级的下载绝大部分是 CI 重装和从别的无人维护包拉过来的传递依赖。所以退出动作必须是机器可读的,消费者是机器。

三个动作、三种用途,别当等价物:

【稳】退出声明抄两个模板。 Atom 给日期:2022-06-08 宣布 → 承诺 2022-12-15 归档,公告逐条列出会坏的(包管理停止工作、无安全更新、协作服务停)与仍可用的(releases 页预编译二进制仍可下载)。⚠️ 但要知道它实际归档于 2023-03-03,晚了约 2.5 个月——日期是下限,滑期要公开补一条说明,别让缓冲期本身变成新的不确定性。Moment 给可证伪的承诺边界:一句定性(「not dead, but it is indeed done」)+ 会做 2 条(严重安全问题、跟随时区数据更新)+ 不会做 6 条(不加新功能、不改 API、不解决包体积、不做 v3、不修长期已知 bug、不接受无充分证据的修正)+ 点名 5 个替代品。

还有一条来自 Atom 的普适教训:2023-01-30 该项目的代码签名证书因未授权访问被预防性撤销,已归档项目的 1.63.0/1.63.1 于 2023-02-02 直接停止运行归档不终结任何能以你的名义发布、或仍在向用户注入运行时内容的资产——退场时必须逐项判「续费」或「主动打死」:域名、registry token 与 2FA 恢复、GitHub 账号、开发者账号、OTA 更新端点、签名与推送证书。

最后,公告里必须预先写死一句:「包名与发布权不转让,欢迎以新名字 fork。」 大项目归档完没人来要,独立开发者一发公告必被问;而把发布权交给主动请缨的陌生人,正是 event-stream(2018)与 xz(2024)的开局。

主要来源(均抓一手):Avelino 等《A Novel Approach for Estimating Truck Factors》(arXiv:1604.06766)与 Metabase 2022-11-14 的复算;Russ Cox 的 xz 时间线 research.swtch.com/xz-timeline;npm trusted publishing / staged publishing 官方文档与 GitHub 2025-09 的 npm 供应链硬化计划;Daniel Stenberg 2025-07 至 2026-06 的六篇一手博客与 curl.se 现行漏洞政策页;GitHub 2026-02/06 的三条仓库设置 changelog;Tailwind Labs 创始人的公开说明与 Stack Overflow 官方站点数据;ACFE《Occupational Fraud 2024》;ProPublica/NPR 的红十字会海地调查;Atom 与 Moment 的官方退场公告;npm 官方 downloads API 实测(2026-07-18~24)。全部载重结论经独立复核,本文写的是修正版;分档与时效风险已逐条标注。

Amos · research.xishe.ai · 转载注明出处