Author’s note: At the time of writing, GitHub had not yet announced GitHub Sponsors, a tool which will make it possible to directly financially support open-source projects and the people behind them. While open source still has a long way to go toward better supporting the often invisible people building our digital infrastructure, this is an important first step toward building a healthier community.
Every month, more than 18 billion pieces of code are installed from the npm package registry by people around the world. Among the most popular packages are a library for performing HTTP requests and Facebook’s sprawling React frontend library, depended upon by millions of developers.
Most of these bits of code are maintained for free or based on donations, despite the massive number of users who rely on them for their code to work. These chunks of code are the digital infrastructure we rely on to build the web, but they’re almost entirely invisible, as are the people behind them.
The rise of open-source code has been stunning, enabled by the propagation of package registries such as JavaScript’s npm, PHP’s Composer, and RubyGems, which have lowered the barriers to entry for developers building complex products on the web. Virtually all development teams rely on these free pieces of code—from Fortune 500 companies to governments, major software companies to startups—but few consider where they came from.
There are many advantages to using open-source software. Instead of writing complex time-conversion functionality, for instance, developers can drop in Moment with a single npm install without ever seeing the code under the hood. This abstraction allows them to focus on building the app they set out to make instead of on standard functionalities that don’t need to be custom-built for every project.
It also highlights a serious problem: The developers building these complex libraries and uploading them to the web for anyone to use are largely doing so without compensation. Because it’s so easy to install these magic pieces of code from the internet, it’s easy to forget that there are real humans behind them—humans who need to support themselves and may, eventually, grow bored or tired of doing critical work for free.
A problem in hiding
Over the years, we’ve seen how our collective reliance on free software maintained by semi-anonymous developers can lead to trouble. In 2018, the event-stream library, which is downloaded roughly two million times per week and is included in thousands of products, was found to contain malicious code designed to steal user credentials from cryptocurrency apps that relied on it.
The story goes that the original developer, Dominic Tarr, who had become too busy to manage the library, decided to hand it off to a new contributor who asked for access, rather than let it go unmaintained. The new developer improved the library a few times to avoid suspicion then quietly updated it to include malicious code, causing downstream developers to unknowingly update to a spiked version.
The malicious package was discovered within the month, but, after the community sounded the alarm, Tarr waded into the code’s GitHub issues to say, “I don’t get any thing [sic] from maintaining this module, and I don’t even use it anymore, and havn’t [sic] for years.” The npm response team and the wider community took swift action, pulling the infected version and notifying developers. But the incident served as a reminder of how fragile this house of cards really is. Because of a single malicious actor, thousands of developers around the world needed to rip out code that relied on the library and find something new to replace it.
This wasn’t the first time an open-source project had been compromised, and it’s becoming an ever more common occurrence. The OpenSSL project, for instance, is relied on by millions of devices, from smart fridges to satellites. When engineers found that it had a critical security flaw, many were surprised to learn that it was maintained by a skeleton crew of developers. This is all too often the case.
Today’s tooling makes it easy to install pieces of problem-solving code and then build entire businesses on top of them on the assumption that the code will be around (and functioning) forever. The business model of many startups is predicated on being able to cobble together complicated but freely available bits of code from across the open-source web, rather than building everything in-house. As a result, startups don’t need to reinvent the basic building blocks that every web app uses—they’re all right there, free and online, ready to be used, and maintained by an invisible developer. It’s easier than ever to build the next Instagram or Reddit from your garage when there’s a package for everything.
Before the dot-com bubble, companies needed physical servers and expensive software licenses to get off the ground. Today, thanks to free tools like MySQL and OpenSSL, no one need ever touch a server or pay for a license. And there is little to motivate the companies that rely on this “free” code to pay the creator of that code for their time. After all, innumerable tiny libraries are available just a few keystrokes away to solve any imaginable problem.
There has to be a better way. To protect this new digital infrastructure against malicious actors and to ensure its long-term utility, open source needs a more sustainable business model. Developers building open-source libraries often devote thousands of hours of their time to the project for free: writing code, offering users support, and reviewing random change requests from the community. Most of them don’t ask for money, or don’t know how to, and only work on these projects in their spare time—meaning they’re more likely to disappear, let the project stagnate, or, in the worst cases, be taken hostage by a rogue developer.
GitHub is great for putting open-source projects online, and npm makes it easy to get them into the hands of thousands—a shift that has democratized software development for the better. But neither of these free, widely accessible tools teaches developers to value their own work, nor do they address the broader economics of software development. Similarly, when companies build on open-source code, the tools they use prompt no consideration of money.
Nadia Eghbal’s landmark 2016 report, “Roads and Bridges: The Unseen Labor behind Our Digital Infrastructure,” surveyed developers involved in some of the most used libraries, and came to a decisive conclusion:
Much like startups or technology itself, what worked for the first 30 years of open source’s history won’t work moving forward. In order to maintain our pace of progress, we need to invest back into the tools that help us build bigger and better things.
It’s easy to open-source a library, provided you have the privilege of money and time. But what happens when your personal project becomes an essential part of the internet’s infrastructure?
Something has to change
The biggest obstacle to better supporting the developers who invisibly weave the fabric of the web is the widespread belief that open-source software should be free as in free beer. Indeed, Eghbal’s report found that the open-source community has an ingrained aversion to asking for money in exchange for “freely” available code, even when that code’s availability comes at the expense of the welfare of the very people maintaining it.
The most obvious first step is to teach developers of open-source tools that they can charge money for them—and that setting a price need not run counter to their aims as open-source developers. The current economic reality of open source keeps the gates closed to all but a privileged subset, ensuring that only those developers with time and money to donate can actively participate. A 2017 survey from GitHub found that the people building open-source projects generally had well-paying jobs and were able to work on side projects as they wished. The same survey found that 95 percent of respondents were male, and only 16 percent identified as “members of ethnic or national minorities in the country where they currently live.” Less than 7 percent identified as LGBTQ. Members of structurally disadvantaged groups—including women, people of color, disabled people, and LGBTQ people—are less likely to have the privilege of time or money to spend on uncompensated open-source projects. However, if open source were consistently funded, anyone could make it their full- or part-time job, thus making it meaningfully more accessible.
Today’s tooling should also help set the expectation that software is not inherently free. The largest code-hosting platforms, GitHub and GitLab, don’t provide integrated ways for developers to monetize their projects directly. (The author’s note at the top of this article addresses the May 23 announcement of GitHub Sponsors. —Ed.) Instead, both choose to focus on the code itself. If these tools provided built-in monetization features, such as support contracts, subscription models, licenses, or even simple donations, it would normalize asking for money in open source. Now, it often feels unreasonable or onerous.
Some developers have used Gitter or Patreon to solicit financial support from the companies and developers that rely on their libraries most. Evan You, creator and maintainer of the frontend library Vue.js, receives more than $17,000 in monthly donations through his Patreon and is able to support himself full time. This method of fundraising helps sustain the project and support the individual behind it, but it doesn’t encourage the companies relying on Vue to adjust how they think about using similar projects. While hundreds of thousands install the tool for free on a weekly basis, many might be willing to pay if there were a more formal channel for doing so. Companies generally need invoicing or support contracts to justify their spending to higher-ups.
Moving from donations to a support contract or commercial-use license forces companies to take the idea of paying for so-called free software more seriously. Offering a pot to drop money into is far less effective than sending a bill. Many see donations as charity, not business.
Some startups are already at work implementing these ideas: DevFlight, for example, helps open-source maintainers monetize by engaging on their behalf with companies that use their work. Another, Tidelift, offers similar services designed to remove the pressure on the developer to find support or ask for money directly.
Several established businesses have also found success operating in this mode. Phacility, an open-source platform for software development, makes its tools available for free. However, you can pay the company to take care of it for you, making sure it runs perfectly and ensuring it’s always available when you need it. Ghost CMS, a popular platform for making blogs that grew out of a successful Kickstarter campaign, is free to download—and run anywhere you like—forever. But, if you need a reliable blog without the hassle of tinkering with hosting or downtime, you can pay the company a monthly fee to soak up the stress.
These projects’ teams, buoyed by regular funding streams, are better able to help the developers and companies relying on their tools and to run their platforms efficiently. They’re also able to sustain development by offering the professional management of their tools as a service, while essentially offering users a free trial until they realize that the tool is useful and that replicating it would be a distraction from their own core competencies. Most importantly, these companies are able to invoice the businesses who use their products, soliciting payment in a form and a language all finance departments understand.
This is a paradigm shift. Asking companies to pay for products they’re used to getting for free might have been a difficult sell for Phacility and Ghost CMS. But businesses that rely on open-source tools ultimately need them to just work. If charged, they are willing to pay for them. A donation or pledge, on the other hand, is a harder sell. Even when you’re a Fortune 500 company, it’s easier to not pay at all.
However, it’s in companies’ best interest to push for change. That may seem counterintuitive: It’s easier to continue to use free products than it is to change an entire industry or to build something new yourself. But if we don’t fix things, the human and technical debt will eventually catch up with us. In fact, the value of software is perhaps best understood by those who use it, rather than by those who create it. Without the support of businesses, OSS developers may never accept that change is possible.
Change is complex, but not impossible
Free software might not come with a price tag, but the hidden costs add up. If we can’t change the culture around open source, something’s going to break. The combination of open source and package managers we use today is still relatively new, but this system simply can’t continue to rely on the generosity of a few privileged folks. We readily discuss the ethics of unpaid internships, so why don’t we talk about those pouring hundreds of hours of unpaid labor into the code we rely on?
For now, the problem lies just under the surface, bubbling up in increasingly alarming breaches and the human toll of developer burnout. Instead of building wild new things and making them freely available for others to use, developers may eventually decide that the payoff isn’t worth it.
The software industry may undergo a renaissance if open source is transformed into something more sustainable and attractive for everyone. But change needs to take place at all levels, from the developer to the companies that use their products to the platforms that enable today’s open-source ecosystem to those of us using open-source code in our projects. All have a part to play in changing expectations: normalizing both the act of asking for money in return for work and the responsibility of paying. If we’re profiting from the hard work of others by using a project like the PHP framework Laravel, there’s no reason we shouldn’t also be encouraging the developer to accept our money to help keep it sustainable.
With millions of people downloading free pieces of code from the npms and GitHubs of the world, open source is the new default. It’s paved the way for countless new ideas—built on foundations laid by the hard work of others—to be realized with incredible efficiency. Let’s ensure it stays this way by pushing for a better model: a future where open source isn’t fraught with burnout, privilege, and gatekeeping, where, instead, it’s a way of life. We are equally obliged to support the software we rely on and those who maintain it. Open source, after all, should be open to everyone interested in building the weird, essential, complicated, and wonderful parts of the technology we use every day.