Credit: Dreamstime
Another day, another article about open source sustainability. After years of reading such posts (including some of my own), I know the formula: Everyone uses open source, some open source is written by solo maintainers who struggle to pay the rent, which puts us all at risk, so that must change.
But too often that “must change” devolves into “solutions” that rely on a “tip jar” gig economy that Cloud Native Computing Foundation CTO Chris Aniszczyk rightly questions. Open source contributors need to get paid for their work. Code-and-pray-for-pay schemes are a poor substitute for a steady paycheck.
It’s also a poor substitute for reality. The reality of open source—at least, most of the mainstream, popular projects you and I use every day—is that developers get paid to write code. Not always and there are well-publicised exceptions, but rewind to the GNOME project back in 2008 and most of those developers were paid to contribute. Fast forward to today and most developers contributing to Kubernetes, Redis, Linux, etc., are also getting paid.
The companies behind them, however, may not be. This is a problem because the more companies get paid, the more developers get paid. You want sustainability? Pay the companies that sponsor developers to contribute. Let’s use the popular Flux project as an up-and-coming example.
Back to the future
Flux is a popular set of continuous and progressive delivery solutions for Kubernetes (as well as Terraform and more), originally created by the company Weaveworks. Although Weaveworks remains the primary contributor to Flux, the project is now a graduated CNCF project, inviting more external contributions. Pushing Flux to the CNCF is arguably good for community, but is it good for Weaveworks?
“Who cares?” you might ask, and the answer is easy: You should.
Weaveworks was one of the first companies to roll out Kubernetes in production to power backend services for large software as a service (SaaS) applications, developing Flux to enable this work. It’s impressive code that gives users autonomous operations as part of their deployment.
If Weaveworks doesn’t do that work (or pay developers to do that work), no one does. Without Weaveworks, Flux doesn’t exist. “But who cares!?” you counter. “We have it now and The Community will carry on!” I have bad news for people who believe money and open source grow on trees. The sustainability of open source is not just a matter of individuals. It’s really a company problem because companies tend to employ developers to write open source software, and companies are most comfortable paying other companies for software.
When Flux 2.1 was released a few weeks back, it immediately saw over 500,000 downloads. This represents a lot of people (and their employers) dependent on Flux to be more productive with Kubernetes, Terraform, etc. It’s so popular that Microsoft Azure builds it into their Kubernetes products, as does GitLab, AWS (EKS Anywhere), Alibaba, and more. You’d think all these companies would be lining up to pay Weaveworks, the CNCF, or someone to ensure Flux development and maintenance continues but, in my experience, it’s not likely.
This is precisely why HashiCorp and other companies (including MongoDB, my employer) have looked for ways to keep their products open while blocking a small but powerful class of users that can have a massive negative impact on the primary project developer’s ability to sustain development.
Keeping open source open
If you look at the projects inside the CNCF, they’re either driven by a community of corporate contributors (like Kubernetes) or by a single vendor (this is also true of the Apache Software Foundation, though the ASF actively tries to discourage single-vendor control and mostly succeeds).
Flux, Apache Kafka, Linkerd, and others fall into this latter camp. This can actually be a great thing for big clouds and others: It’s much easier to work with a company than with individual developers when you have feature requests or need support.
But what happens when those same cloud (or other) vendors move on to a shiny new thing like artificial intelligence? It leaves a company like Weaveworks (or Buoyant in the case of Linkerd) to do the differentiated heavy lifting of development so that the software can be trusted at enterprise scale.
However cool that new thing may be, customers are going to be running the boring old thing for decades, which means someone has to pay the developers to maintain and evolve that software.
Why isn’t that someone you?
For the major cloud providers whose customers depend on Flux and other open source projects, it should be a fireable offense to not have a financial relationship with the project sponsors. It’s a massive supply chain risk.
A rising number of open source companies (like HashiCorp) may change their license, blocking the cloud providers and others from selling services around their code. In the case of Flux, Weaveworks has lost the ability to relicense but what happens if Weaveworks can’t financially sustain development anymore? Will Microsoft, AWS, Google, or others step in to fund it all? They haven’t yet. Why would we expect they’ll magically start?
By not partnering and contributing, these vendors risk increasing the costs of serving their customers. Just ask AWS, which discovered that forking Elasticsearch is costlier than simply enabling Elastic’s success on the AWS platform. (The OpenSearch fork is seeing success, but it has required AWS to hire a sizable engineering team, among other expenses such as branding, community development, etc.)
I think the key to paying more open source developers is to pay more companies. Nor is it just about writing code. A successful open source project, especially one with corporate uptake and staying power, requires heavy investments of testing, bug reporting support, triage documentation, the website, the community, and more.
All this is easier within a company, but companies have to get paid. Envoy creator Matt Klein told me years ago that had he known just how hard it would be to build and run an open source project, he likely never would have started.
Even more worrisome are all those developers and companies that decide they can’t afford to continue. So I’ll repeat: It should be a fireable offense to build businesses on open source projects like Flux without ensuring their long-term sustainability. Sure, it’s a good thing to do for the open source maintainers, but it’s the right, even the essential thing to do for your customers.
