Open Source Business Model

Posted by Alex D'Andrea on 25 November 2023

Open Source software can be found in so many devices and systems that you can easily claim it forms the foundation of our modern, connected life. It is even present in objects where you’d not expect it to be, for example cars.

One of the most prominent examples of open source is undoubedly the Linux kernel. I don’t know how many people can pay their bills by being kernel contributor, but its founder, Linus Torvalds, certainly does. This article explains what people and companies contribute to Linux, and apart from lots of volunteers, some companies do pay engineers to add support for their hardware to Linux, so those engineers arguably earn their money from Linux, too.

And that’s fine.

However, there are so many open source projects next to the Linux kernel - anything from a one-liner to a full-blown operating system. From a single developer to a huge community behind it. These people usually run the development of that software in their free time, with no pay. At the time a project starts, maybe it is just a hobby. But once it grows and it is being used by someone, the source code needs to be maintained: Reading through issues, do bugfixes, fix security issues, team communication, organization and so on (and then - new features?). The early time can maybe be handled in ones free time, in later stages it becomes difficult.

Would you pay for open source?

Thus, for a real open source project you need funding to support the developers to continue to put their work in. Back in 2018 TypeORM, a database access software, had a lengthy discussion about the way to go:

Open source is free, but if you want a really high-quality open source with a good support, code reviews, new features, performance and bug fixes - our core developers should spend much more time on it. And we all know that time is money. TypeORM is a huge and very complex library. Ideally it requires a few full-time paid developers. Nobody is working full-time for free, you should understand that people have families, kids and they have to live on something. They simply can’t be unemployment and work on TypeORM full-time.

In the end the developers never found a way to be paid, and thus stopped putting so much time into it. Their remaining will to drive the project forward was eaten up by negative comments from the community whenever there was a new feature that required code change. Today TyprORM remains an important building block for many Typescript applications, but apart from smaller changes it does not receive any bigger new features.

Companies and open source

HashiCorp announced that they will switch terraform from Mozilla Public License to their own Business Source License. This announcement sparked a lot of negative feedback from the open source community. tldrlegal.com summarizes it as following:

A source available (not open source) license that prohibits production use unless otherwise specified by the licensor. The BSL does automatically convert into a GPL-compatible open source license no more than four years after the software version release date.

The move was made to ensure companies that use terraform can be billed.

Lastly, Serverless framework announced they would be charging companies that use their framework starting with a new major version in 2024. They specifically try to only infer the fee to companies > $2mio and completely exclude open source projects from it - which is a fair move, I think. Businesses use this software to build and deploy their business software and make money from it. If it wasn’t available they’d have to spend more money on development.

How can open source be monetized?

Both examples here are ones with some form of an enterprise behind a software - and both software are special in that regard that they both directly interact with the developers. By that, they do have the impact and direct touchpoint to their users - and can start pulling out some money.

However, large portions of the software ecosystem do not operate in that particular spot. A library that is a dependency’s dependency. A compiler that is used somewhere down there, where you actually forgot it was there and doing its job.

The question is, how can those projects get their share of the cake?

I have no answer.