他独自维护100亿台设备依赖的工具，分文未得！如今AI用他的代码“霸凌”他……
dbaplus社群约 6 分钟一位瑞典开发者让 curl 在全球每部手机、汽车和游戏主机上运行。47 个汽车品牌都在使用它，但他却分文未得。如今，他的邮箱里充斥着大量人工智能机器人发送的邮件。
一、一百亿次安装，只有一个维护者
curl是一个通过互联网传输数据的小型命令行工具。当你的手机下载更新、浏览器加载页面、汽车与服务器通信时，都需要有程序来处理这些网络请求。在大多数设备上，这个程序就是 curl。它无处不在，但几乎没人知道它的存在。
这是关于维持它运行的一个人的故事，以及他现在正在经历的困境 。
1996年，丹尼尔·斯坦伯格接手维护一个小型HTTP下载工具。该工具最初名为httpget，由Rafael Sagula创建。1998年，丹尼尔对其功能进行了大幅扩展，并更名为curl。此后，他从未停止过对该工具的维护。
如今，curl 已部署在 Windows、macOS、Linux、Android 和 iOS 系统中。它运行在每一台 PlayStation、Xbox 和Nintendo游戏机上。Netflix 和Spotify都通过它进行流媒体播放。你的智能电视可能也依赖于它。而这一切的幕后功臣，是一位瑞典开发者。
2025年，丹尼尔被瑞典评为年度开发者。同年，他开始撰写关于职业倦怠的博客文章，并记录一个新的威胁：人工智能生成的虚假错误报告充斥着他的问题跟踪系统，每周浪费他数小时的时间。
荣誉奖项和那些抱怨项目崩溃的帖子同时出现，这已经把开源维护者的生存现状说得明明白白了。
这不仅仅是 curl 的问题。
二、47个汽车品牌，零贡献者
采用curl这个技术的车辆数量惊人。根据丹尼尔自己的文档记录，有47个汽车品牌在其车辆中配备了curl功能。不是47款车型，而是47家不同的汽车制造商。
资料来源：作者，《curl 的企业采用情况与贡献者实际情况》
苹果、微软、谷歌和亚马逊都提供curl服务，但他们都没有雇佣 Daniel Stenberg。他在 wolfSSL 工作，这家公司赞助他维护curl的时间。但wolfSSL毕竟只是一家小公司，却承担着万亿美元级别企业服务的基础设施的重任。
贡献者的现状同样严峻，大约只有10个人定期贡献代码。该项目在发展历程中收到了数百位开发者的补丁，丹尼尔几乎审核了每一份提交、处理安全报告、管理版本发布、回复错误报告和编写文档，并把控项目的发展方向。
我花了二十多年时间构建依赖于像curl这样的库的系统。从电信到数字医疗，我设计过的每个平台，其依赖关系树中都少不了 curl。我们都在使用这些成果，但几乎没有人为此付费。
三、“针对维护者的DDoS攻击”
从2024年底开始并持续到2025年，丹尼尔开始记录一种新现象：人工智能生成的错误报告开始涌入 curl 项目的issue tracker中。
这些报告毫无帮助。它们是伪造的安全漏洞，部分人使用 ChatGPT、Claude 或类似工具编写，生成听起来很有说服力但完全虚构的漏洞报告。丹尼尔一针见血地指出，这实际上是“对维护者的 DDoS 攻击”。
这种模式如出一辙。有人会指示人工智能“查找 curl 中的安全漏洞”，人工智能会凭空捏造出一个听起来合情合理的缓冲区溢出或内存损坏问题，然后这个人会将其作为漏洞报告提交（有时甚至会申请 CVE ），而丹尼尔则不得不花时间进行调查，验证其虚假性，最后关闭该报告。
来源：作者，AI slop 漏洞报告攻击流程
每份虚假报告都会耗费大量时间，因为不能在未经验证的情况下就直接忽略它们。curl中真正的安全漏洞可能会影响数十亿台设备。因此，丹尼尔必须认真对待每一份报告，确认其是否为捏造。《The Register》报道称，curl 项目已开始要求贡献者确认报告并非由人工智能生成，并开始封禁屡犯者。
这些提交行为背后的动机是什么？漏洞赏金。人们想要在不做实际安全研究的情况下，凭借发现漏洞而获得荣誉。人工智能可以轻松生成看似很专业的东西，而最终为此付出代价的是接收漏洞报告的人。
四、年度最佳开发者，记录职业倦怠
瑞典在2025年将丹尼尔评为年度开发者，他实至名归。curl是历史上最成功的开源项目之一，cURL库（libcurl）为全球约100亿台设备提供HTTP传输功能。
但如果你读读丹尼尔同期写的博客，就会发现截然不同的故事。他坦率地写道，单打独斗难以为继，团队规模与十年前几乎相同，却要应对不断增长的项目，这令人精疲力竭。他还指出，企业采纳方案永远无法转化为企业支持。
图片来源：作者，curl项目时间线展示了认可度与可持续性之间的差距
这种认可度和可持续性之间的差距并非curl独有，而是开源软件企业消费模式的核心缺陷。企业从中获利数十亿美元，而维护者却只得到一个奖项和堆积如山的邮件。
五、真正的“巴士系数”问题
LWN.net记录了更深层次的结构性问题。curl 的“巴士系数”为 1。如果丹尼尔·斯坦伯格明天停止维护 curl（无论是因为倦怠、健康、退休问题，还是仅仅因为他觉得已经付出足够多了），目前还没有任何继任计划能够弥补他28年来积累的经验。
HTTP 协议非常复杂。curl 支持数十种协议、数百种选项，以及近三十年来积累的数千种特殊情况。找到一个理解所有这些内容的人不是一个招聘问题那么简单了，而是一个需要多年积累的知识难题。
这并非纸上谈兵。2014 年的 OpenSSL Heartbleed 漏洞就暴露了同样的模式：一个资金匮乏、规模极小的团队维护着一项至关重要的互联网基础设施。业界一片恐慌，成立了核心基础设施倡议组织（现为开源安全基金会），然后又逐渐回到了只消费而不贡献的老路。
图片来源：作者，与类似关键依赖项相比，curl供应链风险
六、亟需改变的三件事
丹尼尔并非在博取同情，而是在呼吁结构性变革。根据他的文章，有三件事必须做到。
首先，企业必须为其依赖的基础设施提供资金。这并非通过一次性捐赠，而是通过持续的雇佣或维护合同来实现。若47个汽车企业采用curl工具，那么至少应有一部分企业正式雇佣curl维护人员。Linux基金会的内核维护模式已证明这种做法行之有效。Linux内核维护者，由那些发布Linux产品的公司正式雇佣，curl理应获得同等待遇。
其次，人工智能生成的漏洞报告问题亟需平台层面的解决方案。GitHub和其他托管问题跟踪系统的平台需要自动检测人工智能生成的漏洞报告，过滤机器生成噪音的负担不应落在维护者身上。丹尼尔要求报告者确认其提交的内容为人工撰写，但这只是权宜之计，并非根本解决方案。
第三，必须将巴士系数意识纳入供应链安全要求。如果公司进行软件供应链审计，需将维护者的可持续性作为一项风险指标。即使代码本身安全，由一人维护的关键依赖项也构成供应链漏洞。
七、开始像对待基础设施一样对待开源维护者
curl并非一个业余项目，而是基础设施。它在互联网传输数据，所覆盖的设备数量远超任何其他库。28年来，它一直可靠地运行。而这一切，都归功于有一个人始终用心坚持维护。
丹尼尔·斯坦伯格创造了一项非凡的成果。但整个业界的回应却是：消费他的项目、授予他奖项，然后任由AI机器人在他的问题跟踪系统里泛滥成灾。
如果你的公司正在使用curl（几乎所有公司都在用），请自查你们是否有所回馈。如果没有，现在就开始行动：为项目提供资金支持，指派工程师向上游社区贡献代码，把它当作真正的基础设施来对待。
作者丨Can Artuc 编译丨dbaplus社群