Who should be responsible for maintaining and troubleshooting open-source projects?
hen you buy a product like Philips Hue’s smart lights or an iPhone, you probably assume the people who wrote their code are being paid. While that’s true for those who directly author a product’s software, virtually every tech company also relies on thousands of bits of free code, made available through “open-source” projects on sites like GitHub and GitLab.
Often these developers are happy to work for free. Writing open-source software allows them to sharpen their skills, gain perspectives from the community, or simply help the industry by making innovations available at no cost. According to Google, which maintains hundreds of open-source projects, open source “enables and encourages collaboration and the development of technology, solving real-world problems.”
But when software used by millions of people is maintained by a community of people, or a single person, all on a volunteer basis, sometimes things can go horribly wrong. The catastrophic Heartbleed bug of 2014, which compromised the security of hundreds of millions of sites, was caused by a problem in an open-source library called OpenSSL, which relied on a single full-time developer not making a mistake as they updated and changed that code, used by millions. Other times, developers grow bored and abandon their projects, which can be breached while they aren’t paying attention.
It’s hard to demand that programmers who are working for free troubleshoot problems or continue to maintain software that they’ve lost interest in for whatever reason — though some companies certainly try. Not adequately maintaining these projects, on the other hand, makes the entire tech ecosystem weaker. So some open-source programmers are asking companies to pay, not for their code, but for their support services.
Daniel Stenberg is one of those programmers. He created cURL, one of the world’s most popular open-source projects.
Developers use cURL to transfer information between two systems, generally in an “API” where a service needs to ask for or send data from another system. According to Stenberg, cURL is included in billions of smartphones, “several hundred million” TVs, and at least 100 million smart cars, every iPhone ever produced, and almost every other modern connected device and service you touch every day. The scale of its use is staggering considering that Stenberg does the lion’s share of the work maintaining it, with assistance from a community of volunteers. Yet few of the companies that rely on his code even realize it’s his code.
Stenberg, who lives near Stockholm, Sweden, invented cURL in 1998 and still maintains the project for free, though he did recently take a job at a company called wolfSSL, which now pays him to work on it “as full-time as possible.” Companies that rely on a specific piece of open-source software occasionally hire those projects’ creators to build upon the projects — in this case, wolfSSL has tasked Stenberg with not only maintaining cURL but building service contracts for providing personal support of cURL.
Stenberg never expected cURL to gain so much popularity. In fact, it took many years to learn that it was even being widely used. Because the code is available to use for free, without any commercial licensing, there’s no reason that companies need to tell him that they’re using it. He only realized the software he’d invented was becoming popular because people started telling him that they saw his name in the “about” window of software, or buried in documentation. “The temperature raised so slowly we never saw it coming,” he said.
“I think I get annoyed when it feels like people try to take advantage of us instead of contributing their share to the project when they are getting so much out of it.”
During the first 20 years of cURL’s existence, Stenberg says he worked on it in his spare time and earned his keep at his “real job” doing other software development. Maintaining the project took a lot of work: he’s spent thousands of hours improving cURL, fixing bugs, and improving his code. Of the 25,000 “commits,” or updates, made to the GitHub repository for cURL, Stenberg created 14,000 of them. No other developer contributing to the software has made more than 1,200 commits.
Survival of cURL is thanks to a set of sponsors who fund the project’s hosting and other costs — though Stenberg says no major company pitches in — and contributors like Stenberg that give their time away for free. Stenberg says he believes that it’s important that open source exists and that he has never regretted making cURL open source. What frustrates him is when companies demand his help when things go wrong.
Last year, a company overseas contacted him in a panic after they paused a firmware upgrade rollout to several million devices due to a cURL problem. “I had to explain that I couldn’t travel to them in another country on short notice to help them fix this […] because I work on cURL in my spare time and I have a full-time job,” Stenberg says.
Because he cares about the project, he scrambled to find a friend to help. His friend flew out and helped solve the problem.
To compensate open-source programmers for this kind of service, Stenberg believes that large companies should pay for support contracts from the developers of a library, which would compensate them for their time and help ensure a project is actually maintained for the long haul. With his work at wolfSSL, he hopes to convince companies like Apple to pay up in exchange for dedicated support, but the effort is still in an early stage.
Support contracts don’t come cheap, often ranging in the thousands of dollars in exchange for dedicated help for using projects and support when something goes wrong. However, the type of companies that need such a service are typically well-funded, or have broad reach, especially in the case of cURL.
It’s still not clear that companies would be interested in such a contract. When Stenberg asked the company that needed him to fly to a different country to troubleshoot their problem to pay for one, they refused.
This frustrates him. “I think I get annoyed when it feels like people try to take advantage of us instead of contributing their share to the project when they are getting so much out of it,” he says. But he still sees support contracts as a long-term solution to maintaining open source: “Money needs to trickle down to the authors and not just get sucked up by the curators or the huge open-source projects/companies that tend to get most open-source money today.”
Many in the open-source community are opposed to the idea that they should be paid in any way, which remains a controversial topic. Some in the open-source community believe that monetization defeats the purpose of “free” — but the reality is that the people working for free need to eat and feed families, just like everyone else.
Today, when a developer or company emails Stenberg for help as fast as possible, he says that “my attitude has shifted more toward ‘well maybe, just maybe, this could be a case where you could consider paying for a support contract.’”
When I ask Stenberg whether he’ll continue to maintain cURL forever — it’s already been 20 years — he says he has no plans to abandon the project that has become a major part of his life.
“Of course, assuming I also manage to get paid,” he adds.