Open source sustainability: It's complicated

Commentary: Those proposing easy answers for how to pay for more open source code to be written clearly aren't talking to the founders of these projects.

moneylaptop.jpg

Image: SIphotography, Getty Images/iStockphoto

Over the last few weeks I've interviewed a range of open source project maintainers, most of which don't directly get paid for supporting their projects. Some, like Gerald Combs of Wireshark, eventually get approached by companies (in his case, Riverbed) that have a financial interest in ensuring a project sees active development. But most, whether through choice or simply (bad) luck never get dedicated commercial backing.

Is this a bad thing?

It's not completely clear. Linux Foundation executive Chris Aniszczyk has been an outspoken opponent of open source "tip jars" that seek to sustain projects with donations. "These [open source developers] should be encouraged to start businesses or your business should hire them directly," he argues. But many such developers don't want a 9-to-5 corporate job, preferring the independence of contract work. Open source sustainability, in other words, is messy.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Open source sustainability: No one right answer

Most open source project maintainers with whom I've spoken got started because it was a "fun" way to spend their free time. They had a variety of personal "itches" they needed to scratch. Exactly none started coding because they were hoping to get paid for that work.

In fact, in some cases, it was specifically to create space from their employer that they started the project. For Datasette founder Simon Willison, for example, he "wanted a creative outlet." That is, a project that he got to have complete control over. In some ways, he said, it was perhaps "a way of blowing off steam," but really it was a place where he could express his creativity without a corporate overlord steering that creativity.

See the problem?

Or, rather, see where Aniszczyk's suggestion bumps up against the reality of why some (many?) developers create open source projects in the first place? Aniszczyk reasonably suggests that the most sustainable source of funding is a paycheck, but that's precisely what many of these developers don't want. Or, at least, they don't want a paycheck that comes with restrictions on their ability to code freely.

How to contribute to open source projects

So what should companies do? Many want to support open source projects but how to do so isn't always clear. For example, there's no strong agreement on which types of contributions are best (musl libc's Rich Felker argues for users of open source software, while fio's Jens Axboe argues for code contributors). Because Felker values his independence, he prefers freelance work, but also has Patreon and GitHub Sponsors accounts that help him cover financial needs (though he'd appreciate more support through these channels). 

There's not even universal agreement on a desire for contributions at all, whatever the kind. RackN, for example, decided to nix contributions for the core of the Digital Rebar project and instead promotes an ecosystem of plug-ins/extensions. Code contributions can also create a fair amount of work for project maintainers, causing some popular projects to seek no outside contributions at all. 

Then there are the projects like PowerDNS that seem to have done a great job of welding together commercial interests with code. It helps that in PowerDNS founder Bert Hubert's case, commercializing the code was always part of the bargain (though it started out as an "abysmal failure"). And other projects, like Wireshark, fit nicely into a commercial company's interests without those interests monopolizing the project. 

All of which is a long way to say that open source sustainability will never have one, meta answer for all of open source. It's always a project-by-project analysis and, really, a founder-by-founder (or community-by-community) decision. 

Disclosure: I work for AWS, but nothing herein relates to my work there.

Also see