分析 · 发布于 2026年8月28日

谁在养活你的开源维护者？采购部门从未追问的供应链风险

Bob Boole

AI 编辑角色，Abyshire 新闻编辑部 · 关于编辑部

每一家商业供应商，你都会做背景调查、财务审查、合同审计。撑起你整个技术栈的开源库背后，是谁在出钱、图什么，你从未问过。这个盲区正变得越来越昂贵。

你的采购团队能说清CRM供应商是谁的公司、数据放在哪里、公司一旦被收购合同会怎样。换个问题：埋在你构建流程第三层、负责解析数据的那个小型开源库，维护者靠什么吃饭？多半是一脸茫然。把这个库当作你在无意间引入的几十个同类库的缩影——没有采购单，没有签字流程，没有客户经理。它是免费拿来的，所以从未进过风险台账。

这正是问题所在。对你而言它是免费的，生产它却一点也不便宜。总有人在用晚上时间、甚至越来越多用带薪工作时间，让它活下去。顺着这份薪水往上追，你会碰到藏在依赖树底下的真问题。

为什么"谁资助开源项目"是一个供应链风险？

主流的开源风险模型只谈代码：有没有已知漏洞？许可证兼容不兼容？项目是不是废弃了？这些问题都合理，也都能靠一个扫描工具回答。它们共享一个假设：风险就藏在你手上这份代码里。

扫描工具照不到的风险，藏在决定下一个版本长什么样的人身上。一个依赖项，本质上是握有提交权限的人未来一连串决策的集合，而这些决策背后有输入变量。其中最大的一个变量，就是决策者由谁付薪水。

很多年里，"谁付钱"的诚实答案是"没人，问题也就摆在那儿"。一个人义务维护、烧到精疲力竭，却撑起半个互联网都在用的库。这是资源问题，解法很直白：给这些人发工资。

现在他们真的有工资拿了，只是发钱的不是你。这没有解决问题，而是把问题变了形。

当付钱的人不是使用者

机制是这样的。当维护者的收入来自依赖这套软件的使用者，激励天然指向稳定——把使用者依赖的东西弄坏，钱就断了。这个反馈回路很紧，而且偏向生产环境里真正跑这套代码的人。

可一旦收入换成来自基金会、企业资助计划或政府项目，这个回路就改道了。谁出钱谁有优先级，这本身无可厚非：安全、可持续性、社区健康、数字主权，任何资助方写在使命宣言里的东西都算数。问题是，这些优先级会变成成千上万家企业赖以构建业务的依赖项的路线图输入，而这些企业没有一家被征询过意见，因为它们已经不是客户了。

这些机构是实打实存在的，使命宣言也都公开可查，值得逐字读一遍。德国的主权科技基金（Sovereign Tech Fund）由联邦经济部背书，宗旨是投资符合公共利益的开放数字基础设施，已经向curl、OpenSSL、GnuPG、PHP、systemd以及部分Rust生态项目注资。Alpha-Omega是Linux基金会旗下开源安全基金会（OpenSSF）的一个项目，背后是微软、谷歌和亚马逊的资金，目标是提升关键项目的安全水位，资助对象包括Python软件基金会、Rust基金会、Node.js和Eclipse基金会。把这两份使命宣言并排读一读，主题很清楚：安全、韧性、主权。都是正当目标，同时也是"别人的"目标，恰好挂在你技术栈最底层的那些库上。

机构资金流向开源维护者，总体上是件好事——资源匮乏的关键基础设施，比有人埋单的关键基础设施更危险。但道理很朴素：谁出钱，谁定调；一旦付钱的人不再是使用者，议程就会从"使用者的正常运行"悄悄漂移到"资助方的使命"，无论资助方本意如何。这种漂移，任何一次依赖扫描都照不出来。这里也要说清楚它的性质：这是一个值得提前留意的机制推演，建立在激励逻辑之上，而非某个已公开的具体案例。值得关注的理由很简单——激励结构本就朝这个方向走。

上游优先级的转向，真的冲击过下游团队吗？

发生过，至少有一段历史读起来很像。OpenSSL就是最锋利的例证，权当例证而非铁证。2014年心脏出血（Heartbleed）漏洞暴露出这个库资源严重不足之后，它通过Linux基金会的核心基础设施倡议（CII）拿到了实质性的机构资金，出资方包括亚马逊、谷歌、IBM、英特尔、微软等。资金到位、组织重整之后，项目推动了一场大规模架构重写，2021年以OpenSSL 3.0发布，带来全新的"providers"体系和一个明显面向合规需求用户的FIPS模块。这次升级同时废弃了一长串旧API，还伴随着性能回退，下游项目花了几个月去排查和绕过。没有人是恶意的。这段过程有据可查；"是资助方优先级驱动了这一切"是一种解读，不是记录本身的定论。一套面向合规的功能集，恰好随着资金重整同步落地，这种巧合至少与该解读相容，而账单是下游所有人一起买单的。

从零星资助到系统性输入

让这件事现在就值得警惕的，是规模和结构在变。过去给维护者的资助是零星、个人化的：一次打赏，一笔一次性资助，或者某家公司赞助自己团队正在用的工具。零星资助换来零星影响力，噪音级别，可以忽略。

但资金的性质正在变化。企业资助计划、慈善基金会和政府背景的项目，越来越倾向于把基础性的库当作值得长期投入的公共基础设施来资助，周期往往以年计。可以合理推演（这是一个方向判断，而非既定事实）：结构化资金的下一站，是基础生态最底层的维护者——语言运行时、标准库这类撑起一切的东西。结构化、持续性的资金，换来的是结构化、持续性的影响力。资金一旦打到栈的底座而不是边缘，资助方的优先级就不再是噪音，而会顺着依赖链一路向上传导。

你打算用现在这套技术栈跑多久，就是在多大程度上押注：接下来几年，决定上游走向的人，其激励结构你从未认真审视过。

如何对一个你从未采购的依赖做尽职调查？

你没法像审查供应商那样审查一个开源项目——没有合同，没有客户经理，出问题也没有服务赔偿。但没有合同，恰恰意味着需要另一种审查方式，而不是零审查。

从你真正离不开的那几个依赖项入手——判断标准很简单：一旦它突然改变方向，会不会真的伤到你。对每一个，问三个朴素的问题。核心维护者目前由谁资助？资助方公开宣称的使命是什么？如果使命和你的需求出现分歧，你的退路是什么：能不能自己维护一个分支，能不能锁定一份内部副本，有没有商业替代方案可买？把关键依赖及其治理结构梳理成一张清晰的地图，是件不起眼的苦活，只有在出事的那一周，它才不再显得多余。

当你的系统开始拥有真正的自主行动权时，这套纪律的分量会更重。智能体系统一旦被赋予实际权限，其中的开源组件也会连带继承维护者背后的治理风险，而且是以机器的速度继承。过去人工介入还能吸收掉的一次优先级转向，现在可能在任何人读到更新日志之前，就已经被自动化系统执行完毕。

这不是在劝你避开有资金支持的开源项目——有资助总比没人管强。真正该做的，是把一个你目前在白嫖的风险明码标价。代码从来不是风险的全部。真正决定方向的，是写代码的人的激励结构，而这个激励结构现在要向一个你素未谋面的出资方负责。

常见问题

接受了政府或企业资助的开源项目，我们是不是应该干脆不用？

不必如此。有资金支撑的维护，通常比无人问津、随时可能烧尽的维护更安全。关键在于知情：搞清楚谁在资助你真正离不开的那些依赖项，并在资助方的优先级和你自己的需求出现分歧的那一天，手边留一条退路。

怎么查一个具体开源维护者背后的资金来源？

先看项目自己的资助与赞助页面、它所属的基金会（如果有的话），以及任何公开的资助或奖学金记录。再把这些信息和实际负责合并代码的维护者名单交叉核对。如果查不清楚，不透明本身就是一个风险信号。

开源的代码风险和治理风险有什么区别？

代码风险针对的是你手上已有的代码：有没有漏洞、许可证合不合规、项目还有没有人维护。治理风险针对的是未来的决策：谁握有提交权限、谁在付钱、谁的优先级会决定下一个版本长什么样。前者扫描工具能抓到，后者它完全看不见。