Transcription
10 billion devices run its code. He maintains it alone. Now AI is attacking him.
One Swedish developer keeps curl running on every phone, car, and console on Earth. 47 car brands use it. Zero pay him. Now AI bots are flooding his inbox. It's an article written by Ken Artok. And I can't wait to read this.
10 billion installations, one maintainer. That's crazy. What? Curl is a small command line tool that transfers data over the internet. When your phone downloads an update, when your browser loads a page, when your car, when your car talks to a server, something needs to handle that network request. On most devices, that something is curl. It's invisible. It runs everywhere and almost nobody knows it exists. This is the story of what the one person who keeps it running and what is happening to him now.
Daniel Stanberg took over the main maintenance of a small HTTP download tool in 1996. The original tool was called HTTP GET and was created by Raphael Sagula. Stanberg expanded it significantly and renamed it curl in 1998. He never stopped maintaining it. So it's been 26 years, 27 years even. That's crazy. It's Yeah, that's crazy.
Today, Curl ships inside Windows, Mac OS, Linux, Android, and iOS. It runs on every PlayStation, every Xbox, every Nintendo console. Netflix streams through it. Spotify streams through it. Your smart TV probably depends on it. One Swedish developer keeps all of that running.
In 2025, Sweden, Swedish, I guess Sweden named Stamberg developer of the year. In the same period, he started writing blog posts about burnout. He also started to document a new threat: AI-generated fake bug reports flooding his issue tracker, wasting hours of his time every week. The award and the burnout posts arrived together. That should tell you everything you need to know about the state of open-source maintainer support.
I feel like AI is kind of ruining the open-source world right now with these kinds of product problems, with also just making it so easy to copy open-source projects, and therefore it's much harder to make benefit or profit from open-source projects. If this story first frustrates you, clap so more engineers see it. This is not just curl's problem.
47 car brands, zero contributors. The adoption numbers are staggering. According to Stamber's own documentation, 47 car brands ship curl in their vehicles now. 47 car models, 47 distinct manufacturers. Apple ships curl, Microsoft ships curl, Google ships curl, Amazon ships curl. None of them employ Daniel Stanberg. He works at Wolf SSL, which sponsors his curl maintenance time, but that is a small company carrying the weight of infrastructure used by trillion-dollar corporations.
The contributor reality is equally stark. Around 10 people contribute regularly. The project has received patches from hundreds of developers over its lifetime. But Stanberg reviews nearly every comment, handles security reports, manages releases, responds to bug reports, writes documentation, and maintains the project's direction. How does he do all that? I wonder how much he works per week.
I have spent 20-plus years building systems that depend on libraries exactly like curl. Every platform I have ever architected, from telecommunications to digital health, had curl somewhere in the dependency tree. We all consume this work. Almost nobody pays for it.
Adidas attack on maintainers. Starting in late 2024 and escalating through 2025, Stanberg began documenting a new phenomenon. AI-generated bug reports started flooding the curl project issue tracker. These were not helpful contributions. They were fabricated security vulnerabilities written by people using ChatGPT or similar tools to generate convincing-sounding but entirely fictional vulnerability reports. Stenberg coded exactly what it was: Adidas attack on maintainers.
The pattern was consistent. Someone would prompt an AI to find security vulnerabilities in curl. The AI would hallucinate a plausible-sounding buffer overflow or memory corruption issue. The person would submit it as a bug report, sometimes even requesting a CVE. And Stenberg would have to spend time investigating it, verifying it was fake, and closing the report. Each fake report costs time. You cannot just dismiss them without verification. A legitimate security vulnerability in curl could affect billions of devices. So Stanberg has to treat each report seriously enough to confirm it is fabricated. The Register reported that the curl project started requiring contributors to confirm reports were not AI-generated and began banning repeat offenders.
The motivation behind these omissions: bug bounties. People want credit for finding vulnerabilities without doing actual security research. AI makes it easy to generate something that looks professional. The human on the receiving end pays the cost.
Developed a year documenting burnout. Sweden named Stenberg developer of the year in 2025. He deserved it. Curl is one of the most successful open-source projects in history. The curl library provides HTTP transfer capabilities to an estimated 10 billion installations worldwide. But read Stanberg's blog during the same period, and you find a different story. He has written openly about the unsustainability of solo maintenance, about the exhaustion of handling an ever-growing project with essentially the same team size as a decade ago, and about how corporate adoption never translates into corporate support.
This gap between recognition and sustainability is not unique to curl. It is the central failure of open source's corporate consumption model. Companies get billions of dollars in value. The maintainer gets the wood and the burned-out inbox. What is a way to fix this? I wonder if there's a suggestion about this. Surely someone has tackled this problem. Have you seen this pattern in projects you depended on? I want to hear about it in the comments.
The real bust factor problem. WN.net documented the deeper structural issue. Curl has a bust factor of one. If Daniel Stenberg stops maintaining curl tomorrow, burnout, health, retirement, or simply deciding he has given enough, there's no succession plan that matches his 28 years of institutional knowledge. That's crazy. So yeah, I that's what I was wondering in the beginning of the article. What happens if I mean, one of the things that we say is what happens if he gets hit by the bus? You know, I mean, it's like an extreme case, but that's like a metaphorical and it can happen in real life, but also as a metaphorical thought.
The HTTP protocol is complex. Curl supports dozens of protocols, hundreds of options, and thousands of edge cases accumulated over nearly three decades. Finding someone who understands all of that is not a hiring problem. It is a knowledge problem that takes years to build. This is not theoretical. The OpenSSL Heartbleed vulnerability in 2014 exposed the same pattern: a critical piece of internet infrastructure maintained by a tiny team with minimal funding. The industry panicked, created the Core Infrastructure Initiative, now the Open Source Security Foundation, and then gradually went back to consuming without contributing.
Three things that need to change. First, corporations must fund infrastructure they depend on, not through one-time donations, but through sustained employment or maintenance contracts. If 47 car brands use curl, at least some of them should employ curl maintainers. The Linux Foundation's model with the kernel shows this works. Kernel maintainers are employed by companies that ship Linux. Curl deserves the same. That makes sense. That makes sense.
Second, the AI slow problems need platform-level solutions. GitHub and other platforms hosting issue trackers need automated detection of AI-generated vulnerability reports. I 100% support this too. The burden should not fall on solo maintainers to filter machine-generated noise. Stenberg's requirement that reporters confirm their submissions are human-written is a stopgap, not a solution.
Third, bust factor awareness must become a supply chain security requirement. If your company runs a software supply chain audit, you should include maintainer sustainability as a risk metric. A critical dependency maintained by one person is a supply chain vulnerability, even if the code itself is secure.
Start treating open-source maintenance like infrastructure. Infrastructure. Curl is not a side project. It is infrastructure. It moves data across the internet to more devices than any other library. It has done so reliably for 28 years because one person cared enough to keep doing the work. Daniel Stanberg built something extraordinary. The industry's response has been to consume that work, give him an award, and let AI bots flood his issue tracker.
If your company uses curl, and it does, check whether you're contributing back. If you're not, start funding the project, assign an engineer to contribute upstream, treat it like the infrastructure it is. What critical open-source projects does your team depend on without contributing to? I'm genuinely curious. The thing about this is that even if you want to contribute, I feel like if you're working for a company, it has to come from, you know, kind of the managerial decision. I feel like, but it's an interesting idea, an interesting issue that I feel like it's only going to get bigger and bigger, and there definitely needs to be a solution about this. Yeah. Let me know what you guys think. Hope you guys enjoyed it as well. I'll see you in the next one. Bye.