It's been nearly five months since the SolarWinds hack came to light, causing lots of chin-scratching about vulnerabilities in the software supply chain.
Well, here's a vulnerability for you: what if the open-source project that powers your business software falls foul of a show-stopping functionality bug or security flaw? What if the project goes belly up altogether because the maintainer leaves?
Companies paying a commercial vendor for their software can typically pressure them for a bug fix, and it's unlikely that the commercial entity will vanish overnight. That's less true for open-source software (OSS) projects, which are often maintained single-handedly by a random person somewhere as a hobby.
Everything's held together with sticky tape
Commercial reliance on open-source software (OSS) is huge. Software integrity company Synopsys, which publishes a regular report on open-source security and risk, found that the number of open-source components per commercial application jumped from 84 in 2016 to 528 last year. Yet the money that open-source maintainers get for working on this software, often in their free time, hasn't grown much if at all.
- Give 'em SSPL, says Elastic. No thanks, say critics: 'Doubling down on open' not open at all
- Cross-platform Windows Presentation Framework, anyone? The short answer: yes. Unpacking Avalonia
- Open Source Vulnerabilities database: Nice idea but too many Google-shaped hoops to jump through at present
Funding for OSS projects is typically dire. In 2019, developer André Staltz collected data from Open Collective and GitHub to assess project revenues. Over 50 per cent of projects couldn't sustain their maintainers above the poverty line, while 31 per cent generated enough for a salary considered unacceptable in the industry.
The sample size was small (58), but that made these results even more illuminating. It comprised relatively large projects, most with at least one full-time contributor. For each of these, there are thousands of other projects that are smaller, but still critical for at least one company somewhere.
Projects foundational to the health of the internet are often alarmingly undersupported. In her 2016 report on open-source sustainability for the Ford Foundation, Nadia Eghbal documented the plight of the OpenSSL project, on which thousands of companies and applications rely.
It was earning no more than $2,000 in donations each year before its Heartbleed security vulnerability surfaced in 2014, with most of the other funding coming from consulting and contract work. It also had just one full-time developer.
"Immediately after Heartbleed and for some years afterwards virtually all of our funding came from sponsorships/donations," says Matt Caswell, who sits on the OpenSSL Management Committee.
Donations to the project are still small today. The OpenSSL Software Foundation has just two supporters under its corporate sponsorship program, each committing around $5,000 each. It also picks up some donations via GitHub Sponsors.
Although Caswell won't reveal numbers, he says that virtually all of its funding comes from support contracts.
The organisation is in better health than it was in 2014 from a personnel perspective, now sporting four full-time developers. That's better, but still worrying when you remember how much of the internet depends on this software.
Project malfunction: Maintainer not responding
A lack of funding can exhaust the open-source maintainers responsible for keeping projects going, warns Geoff Huntley, senior development success engineer at online development tools company Gitpod and a long-time maintainer of open-source code.
"We start doing software because we like writing software, and then a community evolves. And all of a sudden, people start burning out," he says. "One of the things that causes the burnout is they're doing tasks and activities they don't like. The root cause of that is essentially that open source is built on free labour."
Increasing workloads
This can have profound effects on maintainers, who suddenly find themselves fixing bugs they don't care about, handling community politics, running QA on sloppy contributions, and dealing with toxic comments from people using their software for free. Things are so bad that Linux Conf AU, held in Huntley's native Australia, has taken to making a psychologist available for OSS devs on site.
In April, Gitpod carved out $30,000 for an Open Source Sustainability Fund to help developers. The company, which has also made Gitpod free for open-source communities, aims to give the money to open-source projects on which it relies.
Huntley is advising other companies to follow its example: generate a bill of materials for your commercial software to find out what components you use and then identify your unpaid vendors. Then mitigate your supply chain risks. The fund has a simple decision tree that he uses to determine whether his company can either fund the project, contribute in kind with code, or take a more active role as a maintainer.
While folks like Huntley step up, plenty of companies just use OSS without giving anything back. The problem stems from a misalignment in mindset, says Aaron Stannard. He's the CEO and founder of Petabridge, a company that ported Java concurrent application toolkit Akka to .NET as an open-source project.
"The consumers are incentivised to go ahead and just take and take and take and get free value, solve their problems, and move on," he says. "They're making money off of open source. Whereas the producers originally open-source the software for reasons that are typically not commercial."
Show me the money
How can open-source developers buck the trend and start getting paid for their time? People might turn to individual donations through platforms like Patreon or GitHub Sponsors, but some are sceptical. OSS developer Drew DeVault is the third most prolific contributor to wlroots, a set of modules for building compositors for the Wayland display server communications protocol. That project accepted donations, he says, but didn't deliver much.
"It was never even close to enough for even a single developer to make a living from," he says. "If you were doing that strategy, and you were hoping that you can make a living from it, you have to understand that that's extremely difficult." However, it did get him some fruitful consulting gigs, including with Valve, on building Linux-based support for virtual reality.
Business sense?
Like Huntley and Stannard, DeVault has turned his own open-source project into a business. He operates SourceHut, which combines various OSS development tools into a software development platform that can be self-hosted, or which SourceHut will host for you. The project is currently making around $10,000 per month, even though it is not yet forcing people to pay for accounts.
The mindset for building an open-source business is far different than the one you need for maintaining code. "You can make money in open source, but not by accident," says DeVault. You need a monetization plan, a sales and marketing strategy. That entrepreneurial approach won't come easily to all developers.
"Your monetisation strategy will also change based on your OSS product," says Stannard. Some companies charge for a licence to use their source code, based on a variety of open-source licences from MIT's permissive licensing through to stricter ones like the GPL, depending on their business model.
Licensing the open-source software wasn't the right path for Petabridge. Its software is designed to be a foundation to build other things on. Licensing it to embed it in their own software raises adoption risk for clients, Stannard says. Instead, he makes the software free.
"The organisation can start buying in and building stuff and the more stuff they build on top of your free and permissive open source, the deeper the roots sink into it," he explains. Petabridge makes a lot of its money from training and consulting fees, but also sells proprietary add-ons for customers.
Another option for OSS developers to make money is a support licence that guarantees you'll fix a company's bugs, which is something Stannard's company also does. That doesn't mean he won't fix bugs submitted by a non-paying user if they make sense for the broader health of the project.
"You're not really buying our ability to go and fix bugs," he says. "What you're buying is our guarantee that we will fix the bugs when you need them fixed."
You might argue that it would make more sense for companies to just fix the bugs themselves and then commit them back to the project like good corporate citizens. Alas, there's a problem with that, explains Huntley. Often a company's employment contract will insist that it has complete ownership over all intellectual property that an employee creates, which doesn't sit well with open-source licences.
"Enabling a company to be friendly with open source involves going through and revising employment contracts to enable contribution to open source," he warns.
Make open source work for you
At the very least, some arrangements like these can help developers to support projects that have become valuable for the community without corporate customers strip-mining them. But some developers might not want to become business people. Other options include crowdfunding an open-source project, or taking corporate sponsorship. If you're going to take the sponsorship route, just be wary not to end up depending on one sponsor for the lion's share of your income, and steer away from sponsors that try to influence your development direction.
Several intermediary sites have emerged to help collect and disburse crowdsourced or corporate sponsorship funds, including the Linux Foundation's LFX Crowdfunding site and the Open Collective. The latter is an online platform that brings open-source projects and sponsors together via its legal entity, the Open Source Collective nonprofit. OSS projects aren't hierarchical or legal structures, explains Open Collective co-founder Pia Mancini. The collective isn't about supporting individuals so much as the community that builds up around an open-source project, she explains.
"We believe a community is most effective when it can survive its founders," she adds.
While providing open-source communities with a front-end interface to collect and distribute funds, the Open Collective also has tools for sponsors. Its Back Your Stack tool enables companies to analyse their open-source software dependencies, checking project manifests to produce the OSS bill of materials that Huntley described.
What about if you're a developer who'd just like to earn some money while working on open-source projects? Tools like Bountysource offer companies the chance to create bounties for specific features or bug fixes pertaining to open-source projects. Then individual developers can go in and fix them. DeVault also has a neat idea: run a short script to evaluate the domains who have committed to a project's repository in the last 100,000 commits. Then contact them to see if they'd be interested in a conversation. Just make sure you have a decent commit history already. Let a hundred million flowers bloom.
The very thing that makes open source so successful also contributes to its sustainability problem. It thrives on a low barrier to entry and attracts new developers eager to get involved, either for career advancement, self-education, community support, or simply to scratch their own itch. That has led to a massive proliferation of projects. GitHub had about 33,000 repositories in 2008. Ten years later, it celebrated as it passed 100 million.
Not all of those are code repos. Many of them are abandoned. But still, the numbers belie a chaotic segment in which many developers working alone could be working together, if only they could organise. That lack of cohesion makes open source as vibrant, interesting, and frustrating to manage as the internet itself. ®
- Relevant xkcd