A well-considered open-source software model, paired with a dedicated and responsible community, can create the products that shape our world. Open-source software has been hailed as a force that brings people together in innovation and democratizes access to powerful tools.
However, recent trends show companies shifting from full open licenses to more restrictive, enterprise-focused models. The questions we should ask are:
What has driven changes in previously beloved open-source companies like Cockroach Labs and HashiCorp?
What does this mean for the future of open-source software?
What should tech startups learn from this?
This article explores the licensing changes in prominent OSS projects, focusing on CockroachDB’s recent shift. We’ll discuss the motivations behind these decisions, identify common patterns, and provide insights into what constitutes a robust and sustainable OSS model.
Case Study
CockroachDB: From Open to Proprietary
CockroachDB was successful under the Apache 2.0 License, which meant widespread adoption and a lively ecosystem. However, the openness of that license also allowed cloud providers to exploit CockroachDB, commercializing the software without contributing back.
Cockroach Labs decided in 2019 to switch to the Business Source License, which allowed the labs to keep open access because the license had a mechanism of control to balance out commercial viability. More recently, Cockroach Labs has taken another step with its proprietary model through the CockroachDB Software License.
This strategic move was contentious because it was a critical departure from the project’s initially open-source spirit, questioning the community's trust and future direction.
Elasticsearch: The Battle for Control
Elasticsearch—a powerful search and analytics engine—faced similar challenges in generating revenue and protecting its trademark. The parent company, Elastic, even filed a lawsuit to protect the software from being abused by cloud providers. To make matters worse, Amazon falsely claimed a collaboration between the two companies, according to Elastic’s founder. Ultimately, Elastic changed the license, adopting a dual license based on Apache 2.0 and SSPL, which compromised some open-source values.
Looking at the Patterns
When examining both companies, a common theme emerges: insufficient attention was given to the license type at launch time. This oversight leads to surprises and unexpected challenges, forcing companies to make quick, decisive actions that inevitably upset part of the open-source community.
Main Reasons Behind Ditching Open Source
Protection from Cloud Providers: Major cloud providers often exploit open-source software without contributing back, driving companies to become proprietary or lose openness.
Sustainability and Revenue Generation: Open-source projects often lack sustainable business models. For instance, MongoDB generates more revenue than MySQL due to its strategic approach, highlighting why some companies opt for enterprise licenses.
Maintaining Competitive Advantage: Open-source licenses can erode competitive edges, as competitors might use and modify the code. Restrictive licenses help companies control software use and stay competitive.
Community and Ecosystem Management: Restrictive licenses help manage the software ecosystem, ensuring usage aligns with the company's long-term goals.
A Good OSS Model
Your licensing model should align with your business strategy, whether that’s adoption, revenue generation, or software control. For example, Red Hat uses a dual-licensing approach: GPL for the community and a commercial license for enterprises, balancing engagement and revenue.
MongoDB switched to the Server Side Public License (SSPL) to keep cloud providers from using their software without contributing. Choose a license that matches your goals, like Apache 2.0 for widespread adoption or SSPL to protect commercial interests.
Adapt to Market Dynamics and Trends
The software industry evolves, so your licensing model should too. Adapt your strategy as new challenges and opportunities arise.
For instance, Redis Labs initially used the permissive BSD license for rapid adoption. However, when cloud providers threatened to compete, they switched to the Redis Source Available License (RSAL) to protect their business while fostering community use.
Remember, participating in hackathons and dev programs and publishing content on the latest trends not only keeps your project relevant but also attracts sponsors and funding—which you really need as a startup. For instance, Docker frequently updates its licensing and monetization strategies in response to market needs, ensuring it remains a key player in containerization.
Ensure Long-term Sustainability
Any licensing strategy should aim to ensure the project's long-term sustainability. This includes financial viability, continued innovation, and market relevance.
Take the example of MySQL, which was acquired by Sun Microsystems and later Oracle. The dual-licensing model allowed MySQL to be freely available while generating revenue from enterprises needing commercial support. However, Oracle’s focus shifted more toward enterprise licensing, leading to forks like MariaDB by the original MySQL developers.
This situation underscores the importance of a licensing strategy that adapts to changes in ownership and market conditions to maintain project vitality. As the famous Linus Torvalds likes to say:
In real open source, you have the right to control your destiny. You don’t want to discover that companies are abusing your product and making a fortune while you, as a startup, struggle to generate a penny.
Promote Community Engagement
Maintaining a vibrant and engaged community is crucial, even with more restrictive licenses. Open-source projects thrive on community contributions, which drive innovation and improve the software. Start with a creative, skilled team of maintainers and contributors who understand quality code—building a vibrant community.
Offer Clarity and Fairness
The license terms should be clear, fair, and easy to understand. Ambiguity can lead to mistrust or misuse, harming the project in the long run. Finding people exploiting loopholes that no one on your team even noticed would be a nightmare. Here are some Open Source Licenses to Avoid, which you don’t want for your startup.
Final Thoughts
Ultimately, it’s easy to be drawn toward the security of proprietary software, but let’s not forget the unparalleled power of open-source. When an entire community rallies behind a project, incredible things happen—think Linux, Firefox, Blender, or Python. These aren’t just tools; they’re the backbone of innovation, built on the collective effort of people who believe in something bigger than themselves. Linus Torvalds highlights this:
I think, fundamentally, open-source software tends to be more stable. It’s the right way to do things.
The key takeaway? A well-considered open-source software model and a dedicated and responsible community can create the products that shape our world. If you’re building your next startup, remember that open-source isn’t just a license—it’s a philosophy that, when done right, can take your project to heights you never imagined.
