如果你在 2026 年依赖 curl，真正值得问的问题已经并非这个项目老不老，而是这份年岁有没有沉成一种可预期的秩序。放在这个标准下，curl 依然站得住。它给出的维护者信号，并非基金会章程，也并非一支庞大的全职团队，而是另一种更紧的组合：治理形状写得明白，8 周一轮的发布机器持续按表运转，安全处置流程用天数和小时数写进文档，而并非留给善意自行发挥。[1][2][5]
最容易读懂的入口还是发布日历。curl 官方 release table 写得很直白：8.18.0 发布于 2026 年 1 月 7 日，8.19.0 发布于 2026 年 3 月 11 日，下一次计划发布时间是 2026 年 4 月 29 日。[1] 这就给运维方留下了一条很清楚的节奏线：大约每 56-63 天，项目会把变化整理成一个带标签的正式版本。对平台团队来说，这件事比抽象热度更重要，因为升级由此进入日历，而并非以意外的形式闯进排期。
治理模型很旧，却不含糊
curl 并不把自己包装成别的样子。官方 governance 页面直接说，这个项目符合一种标准的 BDFL 形态，Daniel Stenberg 仍然是主要驱动力。[2] 同一页也说得很清楚：项目没有独立 legal entity，没有 umbrella organization，也并非一切事项都要靠投票决定的民主结构。[2] 如果话只停在这里，读上去会显得脆。它没有停在这里。
后面的几条同样关键：
- maintainer 的定义是拥有 push 权限的人
- 体量较大或性质较重的改动，预期要先走 pull request，让别人有机会评论
- core team 目前与 security team 是同一组人
- 这两组人刻意维持在一个小而活跃的范围里，而并非做成礼仪性的庞大名单[2]
这才是更重要的信号。curl 没有出售制度表演，它把真正的运转方式和裁量边界摊开放在页面上。对采用方来说，讲清楚的 old-school governance，通常比讲不清楚的现代词汇更可靠。
历史性的集中度确实存在，当前发布吞吐却并非一人独撑
作者统计同时指向两件事。第一，历史性的集中度是真实存在的。curl 的 GitStats authors 页面显示，截至 2026 年 3 月 23 日，Daniel Stenberg 的提交数是 20,172，占项目记录提交历史的 52.79%。[3] 这并非象征性的 founder 角色，而是很深的作者集中。
第二，最近的发布列车并非靠一个人的键盘在拖动。GitStats tags 页面显示，curl-8_19_0 包含 95 次提交、来自 12 位作者，curl-8_18_0 包含 85 次提交、来自 15 位作者。[4] 在 8.19.0 这个版本里，Viktor Szakats 提交了 44 次，Daniel Stenberg 34 次，Stefan Eissing 7 次。[4] 这些数字没有抹去集中风险，却说明了另一层更关键的性质：版本交付已经宽于创始人个人产能。
平台团队真正该盯住的，就是这道区别。创始人痕迹很重，本身是一种风险；创始人痕迹很重，但当前交付已经呈现多作者结构，则是另一种通常更可管理的风险形状。现在的 curl 更接近后者。[3][4]
最强的维护者信号，其实是那张安全时间表
很多开源项目都会说自己重视安全，curl 则把一只钟摆放在桌面上。它的 vulnerability disclosure policy 规定，安全报告可以走 private security address 或 HackerOne；在正式发布前最多提前 7 天通知 distros@openwall；私有修复分支会在对外发布前不超过 48 小时合入主分支。[5] 这些内容并非姿态，而是操作约束。
这套流程也经过了外部审视。2022 年 Trail of Bits 的代码审计给出了 2 个 high、5 个 low、6 个 informational 和 2 个 undetermined finding。[7] 2024 年针对 HTTP/3 组件的审计给出的结果是 0 个 high、medium、low，另有 2 个 informational finding，同时明确指出 OSS-Fuzz 覆盖下降和 fuzzing 效力不足仍是重要缺口。[8] 这正是成熟基础设施项目应当公开的那类信号。页面上没有写“我们已经安全”，页面上留下的是“外部审计仍然在这里看见了哪些摩擦”。[7][8]
对一个面向互联网的依赖层来说，写清楚的披露节奏，加上公开的第三方审计历史，比宽泛的成熟叙事更像证据。
资金与劳动仍有集中边界，好处在于它是可见的
curl 的 governance 页面写到，项目捐助通过 Open Collective 处理；sponsors 页面则把更实际的话摆在前面：最好的赞助方式，是让一位或两位付费工程师把工作时间用在 curl 上。[2][6] 同一页也点出几条具体支撑路径：wolfSSL 雇佣 Daniel Stenberg，并允许他把带薪时间投入 curl；Fastly、GitHub 与 TeamViewer 则在交付与 CI 基础设施上提供支持。[6]
这并没有把集中风险洗掉，却让劳动结构变得清楚。curl 并没有假装关键维护会凭空出现。带薪工时、赞助支撑的基础设施，以及一支小而活跃的 maintainer/security core，本来就是这台机器的一部分。[2][6]
这为什么会影响采用判断
如果你的团队只是把 curl 当作埋在依赖树底部的一段通用 plumbing，它看上去很容易被误读成普通组件。如果你的团队在交付 appliance、SDK、桌面应用、CI runner 或 edge agent，而 libcurl 的行为会直接落到生产环境，治理信号的权重就会抬高很多。
在这一层里，你真正想要的并非人格魅力，而是四种朴素性质：
- 一张可以排进计划的发布表[1]
- 一套明确写出谁在决定、如何决定的治理结构[2]
- 当前版本交付已经宽于单一维护者[4]
- 一条有明确 embargo 与发布时间约束、并带着外部审计记录的安全流程[5][7][8]
curl 现在仍然同时具备这四点。
可证伪条件
如果 curl 停止把流程做成一台可观察的机器，本文的核心判断就会变弱。更具体地说，若后续版本开始明显脱离公开排期而没有清楚解释，最近的 tag authorship 再次收窄到一人主导，或者赞助支撑的维护工时开始变薄，以致页面上写明的安全与发布纪律难以维持，这篇判断就要改写。[1][4][6]
结语
curl 之所以仍然是开源世界里较强的一类维护者信号，并不在于它已经消除了集中性，而在于它用公开流程把这种集中性包裹起来。把 2026 年的证据放在一起看，方向相当一致：一个带着 BDFL 形状的项目，只要时间表、作者结构、资金表面与安全时钟都处在可见状态里，依然可以被企业和平台团队读成可管理的工程对象。[1][2][3][4][5][6]
来源
- curl，《Release Table》：当前发布节奏、最近版本日期、下一次计划发布时间，以及累计发布统计。
- curl，《Governance》：BDFL 形态、maintainer/core/security team 定义、决策方式与捐助结构。
- curl GitStats，《Authors》：按作者统计的历史提交分布与活跃天数。
- curl GitStats，《Tags》：总 tag 数，以及最近版本的提交数与作者分布。
- curl，《Vulnerability Disclosure Policy》：私密报告入口、embargo 时间与 merge-to-release 的安全流程。
- curl，《Project Sponsors》：赞助支撑的劳动模式与基础设施支持说明。
- Trail of Bits，《cURL Security Assessment: Code Review & Testing Analysis》（2022）：独立审计的 finding 数量与显著问题类型。
- Trail of Bits，《cURL Security Assessment: HTTP/3 Components》（2024）：对 HTTP/3 组件的独立审计与 fuzzing 覆盖缺口。