OSS EU and Rethinking Open Source Licenses
Matt Butcher
open
source
license
This year’s Open Source Summit EU took place in Bilbao, Spain the week of Sept 18th. The two main threads that seemed to dominate discussions were the continued AI enthusiasm and the announcement that the Linux Foundation would be adopting the Terraform fork called OpenTofu (previously OpenTF).
Of course, it has only been a few weeks since Fermyon launched Serverless AI, and we’ve already started migrating to sustainable GPUs powered by Deep Green and Civo Cloud. Thus, it was unsurprising that we had many conversations about AI and LLMs at OSS EU.
But what surprised me a little more were the frequent questions sparked by HashiCorp’s move from open source licenses to the BSL.
I take a more circumspect view of licensing than most, and at the end of the day I will defend anybody’s right to decide what they want to do with their own intellectual property, even if I don’t agree that they have done something prudent or even in their own best interest. But we at Fermyon intend to avoid the same result, and we have a plan to do so.
Up front, I want to address the elephant in the room: We will keep Spin open source perennially. In fact, we feel so strongly about keeping open source intact that we have a pledge stating as much on our site.
Now let’s talk about paying the bills.
A Simple Truism
There is a simple truism that sparks a surprising debate in the open source world: Businesses need to make money. And they need to do it in order to pay the people that work for them.
Die-hard free software enthusiasts take aim at this, claiming it’s rooted in noxious capitalism. But the calculus is simple and certainly not toxic: We as software developers need to have paying jobs. And when you love programming, the best job is a software development job. So we, as software developers, are best served by working for successful software-centric businesses.
Sure, there are many companies that sell “other things” but still participate in software development. Insurance, academia, big box stores, and the automobile industry are examples of industries that sell a product that is not software, but also create and contribute to open source software.
I, for one, feel strongly that open source-oriented startups are an excellent vehicle for creating innovative new technologies that solve problems more effectively. By focusing all effort on creating software, such companies can rapidly experiment and release, making them far more nimble than the average enterprise.
Startups disproportionately create value in the open source world.
The question is: How do we accomplish this ideal of running a profitable startup that creates and maintains open source?
The Switch Has Flipped
I have been part of the free and open source movement for the entirety of my 25+ year career in software. In the late 90s, I was one of the first people to advocate in my org for switching from proprietary tools like the Intel C compiler to open source alternatives like gcc. I brought Perl into our org, as well, and pushed adapting other tools. The response of upper management was dour: How, asked my boss’s boss, can we trust software written by “just anybody” instead of trusting the engineering minds at Intel to produce the best C compiler possible?
This sort of reasoning is foreign to the way we do things now. In my experience, it’s been more common to hear a manager question why they’d need to purchase a license for a tool when an open source alternative was available—especially in the realm of software development where few companies sell compilers, libraries, and low-level tooling. The switch has flipped.
But behind this quaint anecdote is a problem: It was clear back in the 90s how an organization would make money on their software. They’d sell it. The game is a little different now. One common startup playbook is to build an open source tool, help it gain traction, build a community, and then try to figure out how to turn that into a business. The funny thing is that in the past decade or two, if the startup succeeds in growing a community, more often than not it also succeeds as a company (either by being acquired or by becoming a successful standalone enterprise).
Yet starting in late 2023, the macroeconomy put pressure on this playbook. Enterprises throttled spending. Venture funding became just a little harder to get. IPOs slowed to a trickle. And all of these things made it harder for software companies—even open source ones—to endure.
While this has thrown more fuel on the fires of debate about best open source business models, I don’t care to weigh in on that debate. Rather, what I want to do is be open and transparent about how we plan to resist the situation that would lead us to even having to consider taking HashiCorp’s route.
We Don’t Open Source Everything!
I am aware that the subtitle of this section is enough to raise the hackles of some members of the open source community. There’s still a McLuhan-esque “software wants to be free” mentality that has a foothold among a dwindling few of the free software purists. But it certainly feels like more of us recognize that the economic reality resists being boiled down to a platitude.
In the last section I claimed that open source-oriented startups contribute a disproportionately high value to the software world. But they do need to make money to endure.
HashiCorp (like MongoDB and ElasticSearch years before) encountered trouble when it became evident that a competitor could simply take the open source software they produced, and productionize it in a way that presented an immediate and unavoidably competitor to HashiCorp’s own offerings. The better HashiCorp played the role of the open source good citizen, the easier it was for their competitors to create nearly identical offerings. Yet, the competitors did not have to foot the bill for software development. In fact, a competitor could be a “poor citizen,” rarely if ever contributing to the code itself, and thus pass along the entire bill to HashiCorp. And thus, the competitors could undercut the original creators because their own cost was lower.
Fermyon’s work-around is to not open source everything. Specifically, we choose not to open source the things that would benefit our competitors and only our competitors.
What is the core of Fermyon’s technical vision? Make it easy for developers to create and deploy serverless WebAssembly applications. In a word, that’s Spin. And we are resolutely set on making Spin an extraordinary tool that solves real problems for individuals and organizations alike.
Spin is open source (Apache 2), and Spin is subject to our open source pledge. We are “giving away” our most important piece of software.
But we need to make money—because I dearly, dearly want to continue hiring the best folks on the planet to build the most awesome WebAssembly toolchain imaginable. And I want to pay them what they are worth. And I want them to love their jobs.
Early on, Fermyon alighted on a plan to serve our two seemingly contrasting goals: We will be able to both develop an awesome tool and employ awesome people if we can build a cloud service that is compelling enough that developers choose to pay for it rather than building their own.
We focused on cost effectiveness of operating our own cloud, and we built a WebAssembly runtime that could run a massive amount of serverless functions with only sparse compute resources. What we needed was, as we initially described it, “BIG Spin.”
So we built it. It’s called LHC (yes, it’s a physics joke along with Fermyon and Spin). It starts with the Spin WebAssembly execution context, and wraps it in a massively scalable secure multi-tenant environment. We can run well over 1,500 serverless apps in a single LHC process. And we think there’s even more room to improve on that front.
LHC is not open source.
Why not? Because when we first began building it, we asked ourselves a simple question: Who would benefit from using LHC instead of Spin?
- Individual users would find LHC harder to use than Spin.
- Small and medium businesses don’t need LHCs features.
- Large enterprises might want some of the LHC characteristics. But with a little bit of open source Kubernetes work, we could deliver what enterprises need.
- Cloud service providers alone would benefit from LHC. In other words, only the people intent on competing directly with us would be consumers of LHC.
If we released LHC as open source, we were essentially introducing Fermyon to the problem that caused HashiCorp (years further along) to change their license.
It seemed like there was one way to continue to release the coolest stuff as open source, while protecting ourselves from the sort of situation that would necessitate a license change. And that was to decide not to release LHC.
Oops, We Did It Again
A few times a year we re-evaluate our decision. We did so after KubeCon Detroit last year, and then again in February and August of 2023. And each time we re-evaluate, we land in the same place: The only ones who benefit from LHC are those who would create rival services out of our software (without needing to foot the bill for developing the service).
But a new scenario arose in August this year. We were building our AI Inferencing service now called Fermyon Serverless AI. When running locally, Serverless AI in Spin simply uses your local resources (CPU or GPU) to run inferencing. It liberally uses compute resources to complete an inference as fast as possible.
Our cloud version, designed to be resource efficient, operates under more severe constraints: It needs to share GPU resources as aggressively as possible. We want to eliminate startup time, reduce on-GPU time to the fewest possible milliseconds, and free resources for reuse as fast as possible. To do this, we need an optimized scheduling mechanism. And so we built Muon, which is a GPU scheduler.
Once more, we asked ourselves who would benefit from releasing Muon as open source. And once again, the answer was clear: Only organizations who wanted to compete with Fermyon.
So last month we made the decision to release all of the inferencing code into Spin, but not to release our specialized cloud GPU scheduler.
Where We Hope to Go from Here
At Fermyon, we have been devoted to the proposition that open source pushes innovation. And each time we take steps to realize our vision for a serverless WebAssembly platform, we release the cool stuff as open source inside of Spin (or elsewhere).
By not releasing the few tools that make it possible for us to run a hyper efficient cloud platform, we believe we have carved out a technical advantage that would take any potential competitor a substantial amount of work to match—but we’ve done so without reducing any of the potential for individuals and enterprises.
While Fermyon is still early enough that we are not profitable, we are optimistic that this judicious move will lead us to a sustainable business model that will keep us away from ever having to make decisions as difficult as HashiCorp, MongoDB, and ElasticSearch.
Only time will tell whether we made the right gambit, but I hope that by explaining it here I am at least laying our cards on the table. Because this entire plan, and this entire company, are born out of our love for open source software, as well as our desire to employ amazing engineers.