Someone has to Pay for the domino

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 original alt-text of this famous XKCD we’ve modified refers to ImageMagick, but that project is just one of many dominoes holding up the software ecosystem.

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 maintainers thrive on self actualization, but how are other needs met?

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.

Difficulties of the software adoption lifecycle

As projects become more popular, a cycle of growth emerges:

• F/OSS creators/maintainers make something awesome
• Early adopters arrive and contribute, work with minimal documentation, and help the project out
• Late(r) adopters come on the scene but are less likely to contribute, expect better docs, are more likely to ask questions
• Mainstream adopters show up and expect backward compatibility, consistent performance, security, and requested features to be present

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 results of unsustainable F/OSS

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.

Solutions: How F/OSS projects can support themselves

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 (ex. Blender)

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.

Github Sponsors / Patreon

Isn’t this just donation under a different name? Yes and no – GitHub Sponsors and Patreon have done at least a few things to move the needle:

• Reducing friction for maintainers and patrons
• Introducing the social environment to encourage donations
• Facilitated recurring donations

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.

Consulting

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.

Software and Hardware Vendors

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.

Paid Development (early GitLab)

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:

• The “bystander effect” - companies can be hesitant to be the first to pay for feature development that benefits others
• Disparate purchasing timelines for requesting companies
• Companies requiring the use of in-house developers, or preferred vendors
• Management of expectations and timelines for requesting companies

Paid development can work, but it can be difficult to scale, often requiring increasing amounts of focus and effort from maintainers already stretched thin.

Restrictive and Dual Licensing (ex. Highcharts, Qt)

There are lots of ways to license software, but there are at least two ways to make money via licensing:

• Restrictive licenses
• Dual Licensing

Restrictive licenses, also known as “copyleft” licenses, require derivative works to carry the same license as the original code. Because they are more restrictive they can inhibut commercial use.

Despite limiting the use of the software, companies like Qt has built a tremendous business, and projects like Highcharts find consistent, recurring revenue from both of these models.

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.

Paid Support (ex. NestJS)

NestJS is a relative newcomer to the framework space, but it steps in to fill the Rails/Django-shaped void in the Javascript ecosystem. Nest’s enterprise support page shows just how much can be packed into an offering that can support Kamil and keep what is now over 10,000 commits flowing into nestjs/nest.

Another model here is paid speaking, which has been suggested by Simon Willison (the creator of Datasette).

Hosted SaaS offering (ex. Supabase, TimescaleDB)

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.

Open Core (ex. GitLab)

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:

• Being able to build robust software at high speed with dedicated contributors
• Increasing visibility into enterprise customer needs which often precede prosumer needs
• Allowing staged rollout of polished features

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.

A combination of the above

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.