The Current State of Open Source Licenses and What’s Next
Comparison of open source companies, business models, licenses, recent changes and a brief look into the future.
Open source software has been around for quite some time, powering a lot of innovation and still powering key parts of our internet and technology infrastructure. However, we live in a capitalistic world, which means people need to be paid for their work, and users of products or services usually have to pay, directly or indirectly. Consequently, open-source businesses have always struggled with monetization and have gone through various changes.
Instead of diving into the entire history of open source (starting with the Linux kernel, compilers, Git, etc.), I will focus on the last decade, comparing different companies, their strategies, licenses, changes they went through, and the lessons learned from those companies. I’m old enough to know that the future is unpredictable, so 80% of this post is dedicated to summarizing the recent past and 20% is reserved for my predictions and suggestions about what open-source business might look like in the future—because predicting is all the fun!
Comparison
I created a list of 9 companies (there are many more open source companies that changed licenses but I tried to focus on >100M in revenue companies and kept it short for the sake of brevity).
Let’s take a look at a few key trends:
Permissive (Apache 2.0, MIT, BSD, MPL) to Restrictive License (SSPL, AGPL, BSL) change - Six out of nine companies that started as open source shifted towards more restrictive licenses, beginning with MongoDB in 2018. Without delving too deeply into what SSPL, AGPL, or BSL are, the bottom line is that these licenses aim to prevent cloud providers and competitors from offering managed solutions without contributing back or paying to the open-source project (links to all license changes are in the footnotes).
Closed source features - Even with the move to restrictive licenses, companies still maintain closed-source commercial features to ensure there is a journey from free to paid, preventing major customers from remaining on a free plan indefinitely.
Now, let’s look at a few companies that didn’t change their licenses, as each represents an interesting case study:
GitLab: Open Core from the start. GitLab's initial version was open source, but the company was incorporated shortly after with the intent to monetize. They were relatively diligent in deciding which new features would be free and which would be paid to ensure the free version didn’t give away too much.
Confluent: Kafka was spun out of LinkedIn to the Apache Foundation, meaning the initial risk and R&D weren’t on the company’s budget. The company focused on building a commercial, closed-source platform on top of a mature and popular open open source project (that said, Confluent is still a major contributor to Kafka).
Vercel: Next.js was developed by Vercel, it didn’t undergo license changes and stayed with permissive open source MIT license. This is due to a few reasons I can think of. Vercel is a “frontend cloud,” as they call it, or in simpler terms, a hosting company for frontend frameworks. Vercel's product is commercial closed source software, and it would be successful even without Next.js, perhaps even more so. It supports hosting websites written in almost all current frameworks, both client-side and server-side (https://vercel.com/docs/frameworks). The reason for Next.js being open source with a permissive license is actually technical, as there is no other way or license that would work for a library where developers need to import code.
Looking at these nine companies and the recent changes some of them underwent to ensure their businesses are sustainable, let’s recap the current options/models:
Restrictive (RSAL, AGPL, BSL) source available license + closed source features.
Open core with a small set of features being free with a permissive license and others being commercial and/or closed-source.
Closed source or commercial platform on top of an established open source product.
Closed source or commercial platform with a separate and standalone piece/ library/framework being open source.
What’s Next
I think the future is still unclear, and companies are mostly in a reactive state. We will likely see different approaches emerge, as companies can succeed despite not having a perfect business model or license.
That said, out of the four options mentioned in the previous sections, I’m most excited about options 3 and 4 (an already existing mature OSS project incorporated into a commercial platform, or a completely separate standalone OSS project that is supported or incorporated into a commercial platform). The reason for this is that it removes any confusion and constant discussion about what should or shouldn’t be in the open-source version. It also avoids the license sprawl and gymnastics (AGPL, BSL, SSPL) that everyone is trying to navigate to remain both open source while simultaneously avoiding being fully open source to combat cloud providers and competitors.
Another trend I think we’ll see more of is closed source but self-hosted. In the last few years, we’ve seen open-source projects that were started as open source primarily for marketing purposes rather than solving a real pain point by being open source. A common theme is that many open-source projects can be easily self-hosted, which is a real need, especially in the enterprise. By also offering a free tier, enterprises have the option to test a product for an extended period in their own environment, which provides real value—but this doesn’t necessarily mean the product has to be open source.
OSS licenses is a hot topic, so I’m curious to hear your comments and new ideas 👇