curl in 2026: the maintainer signal behind an 8-week release machine

Daniel Stenberg at Open Source Summit Europe 2025. For curl, named maintainers still matter, but the stronger signal is how much of the project has been converted into public process.[8]

If you depend on curl in 2026, the useful question is no longer whether the project is old. The useful question is whether old has become predictable. On that test, curl still grades well. The maintainership signal is not a foundation charter or a giant salaried team. It is a tighter combination: an explicitly published governance shape, an 8-week release machine that keeps shipping on schedule, and a security process written down in days and hours rather than left to goodwill.[1][2][5]

The release calendar is the cleanest starting point. curl's own release table shows 8.18.0 on January 7, 2026, 8.19.0 on March 11, 2026, and the next planned release on April 29, 2026.[1] That gives operators a plain rhythm: roughly every 56-63 days, the project turns change into a tagged release. For platform teams, that matters more than abstract popularity because upgrades become calendar work instead of surprise work.

The governance model is old-school, but it is not opaque

curl does not pretend to be something it is not. The official governance page says the project matches a standard BDFL model, with Daniel Stenberg as the driving force.[2] The same page also says there is no legal entity, no umbrella organization, and no democratic vote for every project decision.[2] That could sound fragile if it stopped there. It does not.

The rest of the governance text matters just as much:

maintainers are explicitly defined as the people with push access
non-trivial changes are expected to go through pull requests for comment before merge
the core team currently matches the security team
both teams are intentionally kept small and active rather than ceremonially large[2]

That is the signal. curl is not selling institutional theater. It is publishing the actual operating model and the boundaries of discretion. For adopters, explicit old-school governance is usually better than modern ambiguity.

Historical concentration is real, but current release throughput is shared

The author statistics make two different points at once. First, there is genuine historical concentration. curl's GitStats page shows Daniel Stenberg at 20,172 commits, or 52.79% of the project's recorded commit history as of March 23, 2026.[3] That is not a cosmetic founder role. It is deep authorship concentration.

Second, the recent release train is not functioning as a one-person push queue. The GitStats tags page shows 95 commits from 12 authors in curl-8_19_0, and 85 commits from 15 authors in curl-8_18_0.[4] In the 8.19.0 release, Viktor Szakats authored 44 commits, Daniel Stenberg 34, and Stefan Eissing 7.[4] That does not erase concentration risk, but it does show a healthier property: release execution is broader than the founder's keyboard.

This is the distinction platform teams should care about. Founder-heavy history is a risk. Founder-heavy history plus multi-author current delivery is a different, usually better, risk shape. curl looks like the second case right now.[3][4]

The strongest maintainer signal is the security timeline

Many OSS projects claim to take security seriously. curl publishes a clock. Its vulnerability disclosure policy routes reports through a private security address or HackerOne, informs distros@openwall up to 7 days before release, and merges the private fix branch no more than 48 hours before the coordinated public release.[5] Those are not slogans. They are operating constraints.

That process has also been tested by outside reviewers. The 2022 Trail of Bits code review found 2 high-severity issues, 5 low, 6 informational, and 2 undetermined findings.[7] The 2024 Trail of Bits HTTP/3 assessment found 0 high, medium, or low findings and 2 informational findings, but it still called out dropped OSS-Fuzz coverage and ineffective fuzzing as meaningful gaps.[8] This is exactly the kind of independent signal mature infrastructure projects should expose: not "we are secure," but "here is where outside auditors still found friction."[7][8]

For an internet-facing dependency, written disclosure timing plus public third-party audit history is stronger evidence than broad claims about maturity.

Funding is still concentrated, but it is legible

curl's governance page says donations run through Open Collective, while the sponsors page says the best sponsorship model is to let a paid engineer spend work hours on curl.[2][6] The same page names concrete support channels: wolfSSL employs Daniel Stenberg and lets him spend paid time on curl, while Fastly, GitHub, and TeamViewer support delivery and CI infrastructure.[6]

That does not remove concentration risk. It does, however, make the labor model visible. curl is not pretending that critical maintenance appears from nowhere. Paid time, sponsor-backed infrastructure, and a small active maintainer/security core are part of the actual machine.[2][6]

Why this matters for adopters

If your team treats curl as a buried transitive dependency, the project can look like generic plumbing. If your team ships appliances, SDKs, desktop apps, CI runners, or edge agents that actually expose libcurl behavior to production, the governance signal matters much more.

What you want from that layer is not charisma. You want four boring properties:

a release schedule you can plan around[1]
a governance model that names who decides and how[2]
current delivery that is broader than a single maintainer[4]
a security process with explicit embargo and release timing, plus public external review[5][7][8]

curl still offers all four.

Falsifier

This thesis weakens if curl stops turning its process into an observable machine. In practical terms, that would mean release slippage without clear public rationale, recent tag authorship collapsing back toward one-person execution, or sponsor-backed maintenance time thinning out enough that the published security and release discipline no longer holds.[1][4][6]

Bottom line

curl remains one of the stronger maintainer signals in open source not because it has eliminated concentration, but because it has wrapped concentration in public process. The 2026 evidence points in the same direction: a BDFL-shaped project can still be enterprise-readable when the schedule, author mix, funding surface, and security clock are all visible.[1][2][3][4][5][6]

cronfeed.work