TL;DR: F/OSS projects have many paths to sustainability. We (OpenCore Ventures) are partial to open core. This post catalogs the sustainability problem and the various solutions we’ve seen working for F/OSS projects.
As usual, “there’s an XKCD for that”:
The software industry has a problem – we’re building on projects that aren’t sustainable – they can’t support the “weight” of support, feature, security and other requests. F/OSS not only supports the wider software ecosystem but also has a large positive effect on the lives of creators and maintainers.
F/OSS is incredibly valuable, especially to its creators. Working on F/OSS fulfills the most difficult parts of Maslow’s hierarchy of needs first. If you’ve forgotten what the hierarchy is, here’s a refresher:
F/OSS projects offer the kind of self-actualization and esteem that Maslow theorized almost effortlessly. However, this often means that maintainers have to work two jobs – open source work that satisfies the top of the pyramid and paid work that satisfies the bottom.
Making F/OSS a sustainable endeavor for maintainers means a special kind of alchemy – turning code into currency.
As projects become more popular, a cycle of growth emerges:
For successful projects, the software lifecycle represents an increasing level of time and effort. Almost all successful projects will feel this pain. How they react is the difference between happy maintainers and burnout, and the line between sustainable and unsustainable software.
The industry has had a front-row seat to the effects of unsustainable F/OSS recently.
Log4J (one of the leading logging libraries for use in the Java ecosystem) is one of the best known recent blowups – the Log4J RCE CVE had an extensive reach and was reported on widely. Before the RCE the Log4J team struggled to keep up with the requests for fixes and support.
In 2021 Faker.js suffered from a slightly different fate – the main developer behind Faker was burned out due to the issues and support requests, causing the developer to vandalize their own project.
And way back in 2012 the Heartbleed vulnerability affected users of OpenSSL. Heartbleed’s CVE goes into detail on the vulnerability but the response of the F/OSS community and the ripples it sent through various projects was profound. The discussion around Heartbleed was one of the first times “sustainability” was mentioned in relation to free and open source software.
OK, let’s get on to what we can actually do about the problem of sustainability – to perform the alchemy of converting code into currency, software needs monetization models that work.
Donations are one great way to support F/OSS and the maintainers that power it. Blender is one example success story, delivering lots of value thanks to a large group of supporters.
Blender serves as an excellent case study of donations going right – it generates more than $173,000 in monthly contributions from 2900+ individuals and 30+ companies. On top of that, developers and designers normally gush about Blender, which helps its mainstream adoption.
The ability to show your support for open source projects and maintainers directly is a mark of pride for many, and that expression is a status symbol for many, creating virtuous cycles for F/OSS.
Many projects end up encouraging or explicitly creating a cottage industry of consultants (ex. Postgres). Who wouldn’t want to hire the people who built a certain piece of software to provide advanced support for said software?
Postgres, arguably the best F/OSS database in the world, uses this model and is wildly successful. There’s sometimes consolidation in spaces with this model, but all in all the ecosystem is healthy and there are new Postgres-based consultancies and startups popping up year after year.
Another great example of this is Evan You, Vue’s creator. Early on in Vue’s development, Evan took on support and consulting contracts to support his work.
Some of the largest success stories of F/OSS have achieved sustainability, high impact, and engaged communities without building a single centralized business, for example the Linux Kernel and Postgres.
Whether delivering advanced versions of the original project like CitusData does for Postgres, or providing a laptop with Linux pre-installed like System76 does, many vendors gather around successful open source projects and help to keep the ecosystem vibrant.
Another way maintainers can fund their open source projects (and lifestyles) is by using a paid development model: customers pay for certain features to be developed.
This is a direct way to fund open source, but there are a few problems:
Paid development can work, but it can be difficult to scale, often requiring increasing amounts of focus and effort from maintainers already stretched thin.
There are lots of ways to license software, but there are at least two ways to make money via licensing:
Allowing source code to be perused, but restricting its use does not qualify as “Free software”, but it still qualifies as “Open Source”. The Server Side Public License (SSPL) is an example of a license that is “Open Source” but does not qualify as “Free” because it restricts your ability to use the software (for commercial purposes).
Restrictive and dual licensing schemes can also hurt enterprise adoption as many companies have a blanket policy to reject all software that is not MIT/Apache2 licensed.
Some companies have been proactive in restricting use of their software, moving to licenses like the Elastic License, Server Side Public License (SSPL), and Business Source License to prevent use by hyperscalers.
Hosted SaaS offerings are an especially good option for self-hostable F/OSS software. Similar to the consulting and paid support options, consumers quite naturally want to purchase hosted versions of software from those that build it.
If maintainers can build (or hire) the operational expertise to run their own software, they are able to generate income and support further development of their software.
A hosted offering can create increased maintenance burden – security, enterprise-facing, and hard/soft multi-tenancy features can take time to implement and scale. On the other hand, improvements in these features often benefit the project as a whole.
Last but not least is “open core” – open core projects are free to develop features for both their open source offering and enterprise offerings in tandem, engaging the open source community and building features that partners care about.
Open core encourages a clear delineation between free and paid features. The certainty afforded to developers and partners helps keep expectations clear and engenders trust.
Open core offers many benefits:
Much of the open source world is underpinned by open core products – Confluent’s Kafka is the industry leading solution for replicated logging and other streaming workloads, Redis is the go-to for caching data these days, with Redis Labs providing modules on top of the ubiquitous open source offering.
At OCV we think open core will be the most common way to make open source projects sustainable and we start companies around open source projects.
Solutions to the F/OSS sustainability in the real world often take many combinations of the strategies above.
Open core, in the case of GitLab and Confluent, also includes hosted SaaS and paid support. Redis Labs offers both a hosted SaaS and enterprise software licenses. Canonical offers the full gamut of services for the Ubuntu linux distribution, and companies like DataStax offer top tier open source databases like Cassandra with a SaaS offering and enterprise software offerings.