What 28 Years of curl Metrics Actually Tell You About Open-Source Software

Daniel Stenberg posted something unusual this week: one hundred graphs documenting the history of curl across nearly every dimension he could measure. Release cadence, lines of code, contributor counts, test suite size, CVE history, platform support, protocol additions, bug closures. One hundred separate views into a project that has been running since 1996. For most software, you could not produce a hundred meaningful graphs. The history is too short, the records too sparse, the project too inconsistent to generate signal over noise. The fact that curl can fill a hundred charts with coherent data is itself a statement about the project.

The Rarity of Enough History

Most software does not survive long enough to accumulate the kind of longitudinal data that makes graphs meaningful. Projects get abandoned, forked, rewritten, or subsumed. The ones that do survive often go through discontinuities, maintainer changes, architectural pivots, license changes, that make early and late data incomparable. curl is unusual in that it has had essentially continuous, disciplined development under the same primary maintainer since its predecessor httpget appeared in 1996. Daniel Stenberg has been the driving force for nearly 28 years.

The first release named curl shipped on March 20, 1998. On March 20, 2023, the project released curl 8.0.0, marking the 25th anniversary with a version bump that had been deliberately held back for the occasion. That kind of intentional milestone-tracking is not incidental; it reflects a project culture that pays attention to its own history. You cannot produce a hundred meaningful graphs if you have not been keeping records, and you do not keep records unless you think the history matters.

Release Cadence as a Health Signal

One of the most telling metrics in Stenberg’s collection is the release cadence. curl releases approximately every eight weeks, and has done so with striking consistency for years. That regularity is not the default state for open-source projects. Most drift: releases cluster when a critical bug forces one, then go quiet for months, then accelerate again around a conference or a contributor sprint. The variance in release timing is itself information about project health.

An eight-week cycle maintained over years implies several things simultaneously. It means the project has a backlog of work that is always approximately eight weeks deep. It means the maintainers have enough confidence in their test infrastructure to ship on a schedule rather than waiting until they feel ready. It means contributors know when to aim for, which improves the quality of contributions because patches are not sitting in review for an indefinite period. A consistent release cadence is downstream of consistent process, and consistent process is downstream of consistent maintainership.

Compare this to OpenSSL, which is the most natural point of comparison for a long-lived C project in the network security space. OpenSSL has had significant discontinuities: the Heartbleed crisis in 2014 forced emergency releases and organizational restructuring, and the project’s history shows the irregular cadence typical of infrastructure software that gets attention primarily when something goes wrong. curl has had its security incidents too, but the release graph does not show the same lurching pattern.

What the LOC Trajectory Tells You

curl started as a small utility. The original httpget was a few hundred lines; the project has grown to well over 150,000 lines of C across the main codebase, from a starting point somewhere around 30,000 lines. That is a five-fold increase over the project’s lifetime, and how you interpret that trajectory depends on what you think the lines are doing.

Some of the growth is protocol support. curl now handles over 28 protocols: HTTP/1, HTTP/2, HTTP/3, FTP, SFTP, SCP, LDAP, DICT, IMAP, POP3, SMTP, and more. Each protocol brings its own state machine, its own error cases, its own authentication variants. Adding QUIC support for HTTP/3 alone was a substantial undertaking. Some of the growth is platform support; curl runs correctly on dozens of operating systems and CPU architectures, and portability code is not free. Some of the growth is the test infrastructure itself, which increasingly lives alongside the main code.

But some of that LOC growth is maintenance burden. Twenty-eight years of backwards compatibility means carrying code paths for TLS libraries that are no longer the default, for authentication schemes that are rarely used, for protocol variants that predate the current standards. This is the normal cost of longevity in a library that cannot easily break its API. The graphs do not distinguish between these categories, but the trajectory is consistent with a project that has chosen breadth of support over a lean codebase.

Contributor Patterns in Long-Lived Projects

curl has accumulated over 1,000 contributors in its git history. That number is worth examining carefully. In any project with a long history and a single sustained primary maintainer, contributor counts are misleading if taken at face value. The distribution is almost certainly extreme: a small number of contributors account for the majority of commits and the majority of consequential changes, while the long tail consists of one-time contributors who fixed a single bug or updated a build file.

This is not a criticism. It is the normal pattern for infrastructure software. The one-time contributors still matter; a bug fix from someone who encountered a specific edge case on an obscure platform is valuable precisely because the core team would not have found it otherwise. But the health of the project is not primarily in the contributor count; it is in the depth of the core contributors and the quality of the review process that turns external contributions into maintainable code.

Stenberg’s graphs presumably show the contributor count growing over time, which is accurate and positive. What they likely also show, if you look carefully, is that the commit frequency attributable to the core team has remained the structural backbone of the project regardless of external contribution volume. That asymmetry is something any developer building a long-lived open-source project should plan for rather than be surprised by.

Test Suite Growth as Confidence Infrastructure

curl’s test suite now contains over 1,500 tests. The growth of that suite over time is one of the more important signals in the entire collection of graphs, because it tracks something that is harder to fake than any other metric: the project’s capacity to make changes without regressing existing behavior.

A test suite that grows alongside a codebase means that each new feature came with regression coverage, and that each bug fix came with a test that would have caught the original bug. This is not universal even in well-maintained projects. It requires sustained discipline over years, because the incentive to ship a fix without writing the test is always present and always locally rational. The accumulation of 1,500 tests over 28 years represents a kind of deferred investment; each individual test cost time to write, and the return is a codebase where changes can be made with some confidence.

curl runs this test suite across an extensive CI matrix covering many platforms and compiler configurations. For a library used in billions of devices, including Android, iOS, and a large number of embedded systems, that coverage matters. The cost of a regression in curl is not a bug in a single application; it is a bug in every application that uses the library, on every platform that runs it.

Security Transparency vs. Security Silence

The CVE history graphs are where curl looks most distinctive when compared to similar projects. curl publishes its security history openly at curl.se/docs/security.html, with detailed descriptions of each vulnerability, its severity, the affected versions, and the fix. The graph of CVEs over time does not show a flatline; there have been genuine security bugs over the years, some of them significant.

The project’s approach to these vulnerabilities is the interesting part. Rather than treating each CVE as a reputational event to be minimized, curl has consistently published thorough writeups, coordinated with downstream distributors, and maintained a public record. The result is that the CVE history is a feature rather than an embarrassment. A project with no published CVEs over 28 years of development is not a project with no vulnerabilities; it is a project that handles vulnerabilities quietly. Security researchers and downstream consumers know the difference.

This transparency creates an interesting dynamic with the release cadence. Security fixes in curl often ship in a coordinated release, with advance notice to major distributors, followed by public disclosure on the release date. The process is documented and repeatable. That kind of operational discipline around security disclosure does not happen by accident; it requires having thought through the process before a vulnerability is found, not while responding to one.

What the Data Discipline Teaches

The deepest thing Stenberg’s hundred graphs reveal is not any specific metric. It is that someone has been tracking these things, consistently and carefully, for nearly three decades. You cannot produce this kind of longitudinal data without having cared about it from early on, and that carefulness about measurement reflects a broader attitude toward the project.

Developers building software intended to last should take the tracking question seriously from the beginning. What metrics would you want to look back on in ten years? Release cadence, yes. Test coverage, yes. Contributor patterns, yes. But also: how are you handling security disclosures? How is your backwards compatibility holding up? What is the ratio of new features to maintenance work, and is it where you want it to be?

curl at 28 years is exceptional not primarily because of its technical decisions, though those have been sound, but because of the consistency of its maintenance culture. The graphs are evidence of that consistency. A hundred graphs of coherent, meaningful data about a software project is a thing almost no project produces, and the reason curl can is not luck.