![]() |
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Twenty years ago, declaring your project “open source” was a statement of principle, philosophy, and community. Today, it’s more likely to be a business decision, a marketing strategy, or a talent acquisition tool. This shift is not a failure of open source; it’s a sign of its success.
The numbers don’t lie: GitHub’s 2024 Octoverse report found that developers made nearly 1 billion contributions to open source and public repositories this year, more devs than ever are consuming open source packages, and the number of first-time contributors continues to grow.
According to many surveys and reports, including contributions from the OSI, we are reasonably sure that more than 90% of companies worldwide are using open source and even have at least one open source component in their codebases. And those numbers are growing.
Open source won.
The open source movement began as a pragmatic response to free software ideology. While the Free Software Foundation emphasized ethical imperatives (“promote computer user freedom”), open source focused on practical benefits: unlimited collaboration, permissionless innovation, and broader adoption. This strategic shift worked remarkably well. Open source became the default choice for infrastructure software, developer tools, and critical business applications.
But success brought its challenges.
When open source was first conceptualized, software typically ran on-premise. The rise of cloud computing fundamentally changed this landscape. Suddenly, the ability to modify and redistribute code became less important than the ability to run and operate it at scale.
A prime example of this metamorphosis is the journey of Elastic. By 2019, Amazon’s Elasticsearch service was generating more revenue than Elastic itself, even though Elastic was the primary maintainer of the Elasticsearch codebase. This led to a well-known conflict: Amazon forked Elasticsearch after Elastic changed its license, creating OpenSearch. This case exemplified the fight between cloud providers and single-vendor open source projects, leading to fundamental questions about the sustainability of open source business models in the cloud era.
This wasn’t the first time open source companies sought to protect their interests from cloud providers. Before that, new licensing approaches were emerging. MariaDB created the Business Source License (BSL) in 2016, pioneering a time-delayed open source conversion model in which code becomes fully open source (typically under the GPL v2.0 or compatible) after a certain period. This middle ground between proprietary and open source models has been called source available, to distinguish it from open source.
Similar concerns led MongoDB to create the Server Side Public License (SSPL) in 2018, followed by Redis’s licensing changes. These companies sought to address their challenges with cloud providers. While not approved by OSI, the SSPL represented another attempt to balance commercial viability with open-source principles.
To everyone’s surprise, Elastic returned to open source a few months ago, adopting the AGPL as an optional license for Elasticsearch. This proves that a SaaS business is possible with open source.
The enterprise open source landscape has evolved dramatically. What began as cautious participation has evolved into strategic investment and leadership. Consider these facts:
And the governance of open source is fundamentally foundation-based. The Linux Foundation hosts over 800 projects with millions in annual funding, the Eclipse Foundation hosts more than 400 projects, currently 296 projects and other initiatives are managed by the Apache Software Foundation, not to mention dozens of projects hosted or supported by the Python Software Foundation, the OpenInfra Foundation, the OpenJS Foundation, and others, and the Cloud Native Computing Foundation also manages millions in funding and organizes the biggest conferences in the open source space. Again, major companies like Google, Microsoft, and Amazon collectively contribute hundreds of millions to open source foundations.
This corporate involvement has brought unprecedented resources and stability to many projects, but it’s also changing the power dynamics in the ecosystem. Decisions are often made in corporate boardrooms rather than in community forums. While this has professionalized project management and improved security practices, it has also raised concerns about the independence of open source development.
Corporate involvement has also led to significant challenges. Oracle’s acquisition of Sun Microsystems led to concerns about the future of Java and MySQL’s future, ultimately leading its creator Michael “Monty” Widenius, to launch MariaDB as a community fork. Docker’s struggles with monetization led to the sale of its enterprise business and dramatic changes to Docker Hub’s pricing model. More recently, HashiCorp’s switch from Terraform to BSL led to the creation of OpenTofu, highlighting how corporate decisions can fragment communities.
Despite these challenges, corporate involvement remains essential to open source sustainability. The key is to establish governance models that balance corporate resources with community interests, as demonstrated by the positive examples that we listed.
The sustainability crisis in open source has sparked various funding experiments. Traditional models like corporate sponsorship and donations have proven insufficient for many projects, leading to new approaches:
However, these models aren’t perfect. Many critical projects still struggle to secure stable funding. The Log4j incident highlighted how even widely used projects can be severely underfunded and maintained by volunteers despite being essential to global infrastructure.
This funding gap has led some projects to explore hybrid models, combining:
Finding funding mechanisms that preserve project independence while ensuring sustainable development is challenging. The industry needs new models to support high-profile projects and the long tail of more minor but crucial dependencies.
The rise of artificial intelligence has introduced a new topic to the open source conversation. Unlike traditional software, AI systems include both code and models, data, and training methods, creating complexities that existing open source licenses were not designed to address. Recognizing this gap, the OSI launched the Open Source AI Definition (OSAID) in 2024, marking a pivotal moment in the evolution of open source principles. OSAID v1.0 defines the essential freedoms for AI systems: the rights to use, study, modify, and share AI technologies without restriction. This framework aims to ensure that AI systems labeled as “open source” align with the core values of transparency and collaboration underpinning the movement.
However, the journey has not been without challenges. The OSI’s definition has sparked debates, particularly around the legal ambiguities of model weights and data licensing. For instance, while OSAID emphasizes transparency in data sources and methodologies, it does not resolve whether model weights derived from unlicensed data can be freely shared or used commercially. This has left businesses and developers navigating a gray area, where the practical adoption of open source AI models requires careful legal scrutiny.
Despite these challenges, this effort underscores the adaptability of open source principles. It proves that they can evolve to meet the demands of emerging technologies while preserving their core values, as they have in the past.
So, what comes next?
The transformation of open source is already visible through several clear trends:
We are moving toward a new model that transcends the traditional definition of open source. The stories we’ve seen suggest that the future lies in more explicit value exchanges between stakeholders. We will likely see more tiered licensing systems and hybrid models that balance commercial interests with community benefits.
I also see the need for a new funding mechanism beyond donations and corporate sponsorship. First, corporate funding means corporate involvement, directly or indirectly, which doesn’t guarantee the freedom or independence of open source maintainers. Second, it does not guarantee the financial stability needed to succeed or maintain a project in the long term. We have recently witnessed the potential disaster of unmaintained OSS.
This doesn’t mean we are about to witness the death of open source, but rather its evolution. Just as open source emerged from free software as a more pragmatic approach, new models are emerging to address today’s challenges. The principles of collaboration, transparency, and shared innovation remain valuable. Still, their implementation adapts to a changed technology landscape, and the definition itself could even live outside the Open Source Initiative.
I could even say the next phase might not be called “open source”! The question isn’t whether this model will survive but how it will transform to meet the needs of a changed industry.
The real challenge for the community is ensuring that this evolution preserves open source’s core benefits while adapting to new realities. We need to be active participants in shaping this future, not just observers of the change. The next chapter of open source will be written by those who can successfully navigate these challenges while staying true to the fundamental values that made it revolutionary in the first place.