From FOSS To COSS

From FOSS To COSS

From FOSS To COSS

Table of contents:-

The Philosophical Foundations: FOSS Emerges

The Pragmatic Pivot: Open Source Takes Shape

The Commercial Challenge: Monetising the Commons

Enter COSS: The Open Core Solution

The Cloud Complication: Licensing Under Pressure

Alternative Approaches: Beyond Open Core

The Sustainability Question: Community Versus Commerce

The User Perspective: Navigating the Modern Landscape

Looking Forward: The Continuing Evolution

Conclusion

The landscape of software development has witnessed one of the most remarkable transformations in modern technological history—a journey from purely ideological free software principles to pragmatic commercial open source ventures. This evolution represents not merely a change in business models, but a fundamental rethinking of how software innovation, community collaboration, and economic sustainability can coexist. For users of BSD, Linux, Unix, and independent distributions, understanding this transition offers valuable insights into the forces shaping the software ecosystem we all depend upon today.

The Philosophical Foundations: FOSS Emerges

The story begins in 1983 when Richard Stallman, a programmer at MIT, launched the GNU Project with an audacious vision: creating a completely free Unix-compatible operating system. This wasn't simply about cost—it was about liberty. Stallman's conception of "free software" centered on user freedoms rather than price tags, embodying principles he believed were essential for a just digital society. By 1985, he had established the Free Software Foundation to provide organisational structure and legal infrastructure for this burgeoning movement.

Stallman articulated four fundamental freedoms that defined free software: the freedom to run programmes for any purpose, to study and modify their source code, to redistribute copies, and to share modifications with others. To protect these freedoms, he pioneered the concept of copyleft through the GNU General Public Licence, first released in 1989. This ingenious legal mechanism ensured that software remained free by requiring any derivative works to maintain the same freedoms—a self-propagating system of software liberty.

The free software movement positioned itself as an ethical crusade. Stallman viewed proprietary software not as a business choice but as a moral wrong that denied users their fundamental rights. This philosophical stance, whilst inspiring devoted followers, also created challenges when engaging with the business community, which often perceived such rhetoric as confrontational or ideological rather than pragmatic.

Parallel to Stallman's efforts, the Berkeley Software Distribution (BSD) community developed their own approach. Emerging from the University of California, Berkeley's work on Unix variants, BSD employed a permissive licence that allowed virtually unrestricted use, including incorporation into proprietary products. This created an alternative model of openness—one focused on maximum freedom for developers rather than mandatory preservation of user freedoms.

The Pragmatic Pivot: Open Source Takes Shape

By 1998, the computing landscape had changed dramatically. The internet was transforming from an academic curiosity into a commercial force, and businesses were beginning to recognise the technical merits of collaborative software development. However, the term "free software" remained problematic for corporate adoption—the ambiguity between "free as in freedom" and "free as in price" created confusion, whilst the movement's ethical framing sometimes alienated potential commercial partners.

The catalyst arrived when Netscape Communications announced it would release the source code for its Navigator browser. This momentous decision prompted a strategy session in Palo Alto, California, on 3 February 1998, where Christine Peterson proposed the term "open source" as a more business-friendly alternative. The new terminology aimed to emphasise practical advantages—superior quality through peer review, accelerated innovation, and enhanced reliability—rather than ideological imperatives.

Eric Raymond and Bruce Perens swiftly founded the Open Source Initiative in late February 1998 to steward this rebranding effort. Raymond, whose influential essay "The Cathedral and the Bazaar" had articulated the superiority of decentralised development models, served as the OSI's first president. The organisation created the Open Source Definition, adapted from Debian's Free Software Guidelines, which established objective criteria for identifying open source licences without the ethical language that characterised free software advocacy.

This pragmatic approach proved remarkably effective. Figures including Linus Torvalds endorsed the new terminology, and an April 1998 summit brought together leaders from major projects including Sendmail, Perl, Python, and Apache. The open source movement positioned collaborative development as an engineering methodology that produced better software, rather than a moral imperative—a framing that resonated with business decision-makers.

Yet this shift created lasting philosophical tensions. Stallman rejected open source as insufficiently principled, arguing it diluted the ethical foundation necessary to protect user freedoms. He characterised it as "a non-movement" that addressed technical efficiency whilst abandoning the fight for digital liberty. This divergence persists today, with the Free Software Foundation maintaining that the choice of terminology reflects fundamentally different values, not merely marketing preferences.

The Commercial Challenge: Monetising the Commons

As open source gained mainstream acceptance, a crucial question emerged: how could companies build sustainable businesses around software they gave away freely? The first major answer came from Red Hat, founded in 1993 by Bob Young and Marc Ewing. Initially a small catalogue business selling Linux distributions on CD-ROMs, Red Hat stumbled towards a model that would prove transformative.

In 2001, facing the reality that freely available software couldn't sustain box sales, Red Hat launched Red Hat Enterprise Linux on a subscription basis. The breakthrough insight was elegant: customers weren't paying for the software itself but for the reliability, support, and professional services that transformed community-developed code into enterprise-grade products. Red Hat offered curated stable releases, security updates, technical support, training, and integration services—value that enterprises desperately needed but the community alone couldn't provide systematically.

This support and services model carried Red Hat to unprecedented success. The company went public in 1999, achieving the eighth-largest first-day gain in Wall Street history at the time. It grew steadily, ultimately reaching a revenue run rate exceeding three billion pounds before IBM acquired it for thirty-four billion dollars in 2019. Red Hat had apparently discovered the blueprint for commercial open source success.

Yet a curious pattern emerged: despite Red Hat's obvious triumph, virtually no other company successfully replicated its model. The fundamental problem lay in the economics. Red Hat generated enormous value for users and the broader community, but captured only a small fraction of that value as revenue. The company had to compete against free alternatives—anyone could take Red Hat Enterprise Linux's source code and create compatible distributions, as CentOS famously demonstrated. Red Hat's "rake"—the percentage of created value it captured—remained stubbornly low.

Other companies attempting similar approaches struggled. MySQL, whilst building significant user bases, found pure support models insufficient for growth. SugarCRM, Jaspersoft, and Alfresco all experimented with variants of the support model without achieving Red Hat's scale. The market was delivering a clear message: selling support for entirely open source products worked for Red Hat's unique circumstances but wasn't a repeatable path to building substantial software businesses.

Enter COSS: The Open Core Solution

The industry's response to this monetisation challenge gave birth to Commercial Open Source Software as a distinct category. Unlike community-driven projects where control is distributed amongst stakeholders, COSS companies maintain centralised ownership and control, conduct most development through in-house staff, and directly generate revenue from their products. The term itself, whilst popularised around 2004, encompasses various approaches that all share a fundamental characteristic: finding ways to commercialise open source beyond pure support models.

The dominant approach that emerged is the open core model, where the majority of the codebase remains open source whilst a smaller portion—typically features aimed at enterprise customers—becomes proprietary. This allows companies to stay true to open source principles and support developer communities with free, capable software, whilst capturing sufficient value to fund ongoing development and achieve commercial viability.

MongoDB exemplifies this evolution dramatically. Until 2011, the company offered only support and services for its open source database. In 2013, it pivoted to an open core approach and rebranded from 10gen to MongoDB. The transformation proved swift and substantial—the company went public just four years later, demonstrating the model's commercial potential. Similarly, Elastic (creators of Elasticsearch) and Odoo (offering ERP and CRM software) found sustainable paths forward by adopting open core strategies after years of struggling with pure support models.

The open core model attempts to balance multiple considerations. The open source core must be sufficiently robust and feature-complete to attract developers and build community momentum. Simultaneously, the proprietary features must deliver enough incremental value to justify enterprise investment without alienating the community by holding back essential functionality. Finding this equilibrium—the right "core to crust" ratio—becomes the central challenge for open core companies.

The Cloud Complication: Licensing Under Pressure

The rise of cloud computing, particularly the emergence of dominant infrastructure providers like Amazon Web Services, introduced profound new tensions into the COSS ecosystem. Cloud providers discovered they could take open source software, offer it as a fully managed service, and capture substantial revenue without contributing back to the projects or companies that developed the software. This created what many COSS companies perceived as an existential threat.

MongoDB confronted this challenge directly in 2018 by changing its licence from the GNU Affero General Public Licence to the Server Side Public Licence. The SSPL, crafted by MongoDB itself, maintains most AGPL provisions but significantly strengthens requirements for those offering the software as a service. Under SSPL, any company providing MongoDB functionality to third parties as a service must release their entire technology stack—including all management layers and supporting infrastructure—under SSPL. This effectively prevents cloud providers from offering competitive services without either contributing back or purchasing commercial licences.

Elastic followed a similar path in 2021, moving from Apache 2.0 to dual licensing under SSPL and its own Elastic Licence. The company explicitly cited years of what it characterised as Amazon misleading the community and free-riding on Elastic's investment. Redis likewise shifted from the permissive BSD licence to dual licensing under SSPL and its Redis Source Available Licence in 2024. Each change prompted significant controversy, with AWS and other cloud providers responding by creating forks: OpenSearch for Elasticsearch and Valkey for Redis.

The Open Source Initiative steadfastly refuses to recognise SSPL as truly open source, arguing it discriminates against specific use cases (offering software as a service) and therefore violates the Open Source Definition's requirement for use neutrality. Major Linux distributions including Debian and Red Hat Enterprise Linux removed SSPL-licensed software from their repositories. Critics contend these licences represent "fauxpen source"—software that appears open whilst actually restricting freedoms.

Interestingly, both Elastic and Redis later added the AGPLv3 as an additional licensing option in 2024 and 2025 respectively, recognising the value of OSI-approved licences for community trust whilst maintaining SSPL as protection against competitive cloud services. MongoDB, however, maintains only SSPL, reflecting its assessment that the trade-offs favour maximum protection over OSI approval.

Alternative Approaches: Beyond Open Core

Whilst open core dominates contemporary COSS, other models have emerged to address the monetisation challenge. The freemium model, exemplified by companies like Slack and Grammarly, offers capable free versions to individuals and small teams whilst reserving advanced features, enhanced usage limits, or enterprise capabilities for paying customers. This differs from open core in that the free tier is typically a hosted service rather than downloadable open source software, though the boundary between these approaches increasingly blurs.

Software-as-a-Service (SaaS) represents another path where companies don't charge for the software itself but rather for the infrastructure, tooling, and platform to consume it. This model sidesteps many licensing complications by controlling hosting and deployment whilst still potentially open-sourcing the underlying codebase. Companies can build substantial businesses on top of open source platforms by providing the convenience, integration, and enterprise features that customers value.

Dual licensing arrangements allow projects to release software under both open source licences (typically copyleft like GPL) and commercial licences for those who prefer proprietary integration or wish to avoid copyleft obligations. This enables companies to serve both open source communities and commercial clients with different needs, though it requires careful legal structuring and copyright assignment practices.

Some projects explore "delayed open sourcing" through mechanisms like the Business Source Licence, introduced by MariaDB. Under BSL, software is initially source-available under restrictions preventing competitive commercial use, then automatically converts to a true open source licence (typically GPL) after a specified period, often three years. This provides companies with time-limited commercial exclusivity whilst guaranteeing eventual freedom for users and preventing permanent lock-in.

The Sustainability Question: Community Versus Commerce

The evolution from FOSS to COSS reflects deeper questions about software sustainability and the relationship between community and commerce. Pure community open source, governed by stakeholder consensus and developed primarily through volunteer contributions, has produced extraordinary achievements—Linux, Apache, Python, and countless other projects that form the infrastructure of modern computing. These community efforts thrive on intrinsic motivation: the pleasure of creation, reputation building, solving personal problems, and contributing to public goods.

Yet community development faces inherent scaling limitations. Most contributors participate part-time around other commitments. Coordination across distributed global teams requires substantial overhead. Unglamorous but essential work—security maintenance, documentation, bug fixing, supporting users—often goes undone or falls to small numbers of overworked maintainers. Burnout plagues critical projects where the labour involved far exceeds volunteer capacity.

COSS companies address these challenges by providing full-time staff dedicated to software development, quality assurance, security monitoring, and user support. They can make the substantial investments required for enterprise features, performance optimisation, and comprehensive testing that community projects often struggle to sustain. Commercial incentives align with long-term maintenance and support, reducing abandonment risks that plague purely volunteer efforts.

However, this commercial involvement creates tensions. When companies maintain control over project direction, community contributors may feel their input is devalued or that the project serves commercial rather than community interests. Licence changes, particularly those moving away from OSI-approved open source, can fragment communities and provoke forks. The question of what features belong in the open core versus the proprietary layer generates ongoing debate, with communities often pressuring for more generous open contributions whilst commercial pressures push towards more restricted cores.

Professor Dirk Riehle, a leading researcher on open source economics, has distinguished between "community open source" (controlled by stakeholder communities) and "single-vendor commercial open source" (controlled by one commercial entity). By his assessment, community open source represents "proper open source," open in both licence and process, whilst single-vendor arrangements, despite using open source licences, operate more like proprietary software companies with transparent codebases.

The User Perspective: Navigating the Modern Landscape

For users of BSD, Linux, Unix, and independent distributions, the FOSS to COSS evolution presents both opportunities and considerations. The proliferation of high-quality open core and commercial open source products has dramatically expanded the ecosystem, providing robust options for everything from databases and search engines to content management systems and development tools. Many of these would likely not exist, or would exist in far less polished forms, without the sustainable funding models that COSS enables.

When evaluating software choices, understanding the business model becomes increasingly relevant. Pure community projects offer maximum freedom and immunity from commercial licensing changes but may provide less consistent maintenance, support, and enterprise features. Open core products typically provide excellent free tiers suitable for developers and smaller deployments whilst requiring payment as usage scales or enterprise features become necessary. Products under source-available licences like SSPL provide code transparency and modification rights for many use cases but restrict certain commercial applications.

The fork risk—that licence changes or commercial decisions could prompt community splits into competing versions—represents a real consideration. The Elasticsearch/OpenSearch and Redis/Valkey divisions demonstrate that even mature projects aren't immune to such disruptions. However, forks also provide an important safety valve, ensuring that even commercially-controlled projects can't entirely abandon community interests without consequences.

From a philosophical standpoint, users must navigate the tension between the original FOSS ideals and contemporary commercial realities. For those committed to the Free Software Foundation's principles, software that restricts usage scenarios or imposes commercial terms on service providers may be unacceptable regardless of practical benefits. For others focused on the technical advantages and practical availability of source code, the distinctions between FSF-approved free software, OSI-approved open source, and source-available licences may seem less consequential than the actual capabilities and economics of the software.

Looking Forward: The Continuing Evolution

The journey from FOSS to COSS isn't finished—it continues evolving in response to new technological and economic forces. The emergence of artificial intelligence and machine learning creates fresh challenges around model training, data rights, and computational resources that don't map neatly onto traditional open source concepts. The Open Source Initiative's recent work on the Open Source AI Definition reflects these emerging complexities.

Platform economics and network effects increasingly dominate software markets, creating winner-take-most dynamics where a few dominant players capture disproportionate value. This concentration presents challenges for COSS companies trying to compete against tech giants that can absorb losses in open source-adjacent businesses whilst profiting from complementary services. Whether current COSS models can sustain meaningful competition in such environments remains an open question.

The developer experience and tooling ecosystem increasingly favours integrated, managed services over self-hosted open source installations. Younger generations of developers, who've grown up with cloud-native architectures and SaaS expectations, may view traditional open source distribution methods as archaic. This generational shift could further accelerate movement towards hybrid models where open source code serves as infrastructure for primarily delivered-as-service offerings.

Geopolitical considerations are also emerging as significant factors. Governments increasingly recognise open source software as strategic infrastructure requiring protection and investment. Licensing decisions become entangled with questions of digital sovereignty, supply chain security, and economic competitiveness. We may see more government intervention, funding mechanisms, or regulatory frameworks attempting to ensure open source sustainability beyond market mechanisms alone.

Conclusion

The transformation from FOSS to COSS represents neither betrayal nor triumph but rather adaptation—the technology community learning through trial, error, and iteration how to sustain software innovation that serves both idealistic and pragmatic goals. The free software movement's ethical foundations remain vital, reminding us that technology choices carry moral dimensions and that user freedom deserves consideration beyond simple utility. Simultaneously, the open source movement's pragmatic approach and the commercial models pioneered by COSS companies have enabled an explosion of accessible, high-quality software that underpins modern digital infrastructure.

For users across the diverse landscape of BSD, Linux, Unix, and independent distributions, this evolution offers unprecedented choice and capability. Understanding the various models—their trade-offs, incentive structures, and philosophical commitments—empowers more informed decisions about which software to adopt and how to engage with the communities and companies developing it. The ecosystem's health depends on sustaining multiple approaches: community projects, corporate open source, COSS ventures, and hybrid models all contribute irreplaceable value.

The ideal balance between community and commerce, freedom and sustainability, remains contested and contextual. What matters most is maintaining the core principles that made open source transformative: accessible code, collaborative development, transparent processes, and the conviction that shared innovation ultimately serves everyone's interests. Whether software is free as in freedom, open as in source, or commercial as in sustainable, its value emerges from the communities that create, maintain, and improve it together.


Disclaimer

The information presented in this article is provided for educational purposes and represents an overview of the evolution from Free and Open Source Software (FOSS) to Commercial Open Source Software (COSS). All trade names, trademarks, and brand names mentioned herein are the property of their respective owners. The Distrowrite Project makes no claims to these marks and acknowledges the rights of their owners.

Whilst every effort has been made to ensure the accuracy and completeness of the information presented, technology and business landscapes evolve rapidly. Readers are encouraged to verify current details independently, particularly regarding specific product offerings, licensing terms, and company positions, which may have changed since publication.

This article does not constitute legal, business, or technical advice. Users and organisations should consult appropriate professionals when making decisions about software licensing, business models, or technology adoption.

The Distrowrite Project explicitly does not endorse or promote activities involving malware, viruses, or harmful content that may compromise the integrity of networks, devices, or other infrastructure. The discussion of various software models and licensing approaches is intended solely to inform readers about legitimate commercial and community software development practices.


References

  1. Business models for open-source software – Wikipedia https://en.wikipedia.org/wiki/Business_models_for_open-source_software

  2. What is Commercial Open Source Software | Webiny
    https://www.webiny.com/blog/what-is-commercial-open-source

  3. A business model for commercial open source software – ScienceDirect https://www.sciencedirect.com/science/article/abs/pii/S0950584918301277

  4. Archetypes of open-source business models | Electronic Markets
    https://link.springer.com/article/10.1007/s12525-022-00557-9

  5. The Historical Case for Fair Source – Open Path
    https://openpath.quest/2024/the-historical-case-for-fair-source/

  6. Red Hat – Wikipedia
    https://en.wikipedia.org/wiki/Red_Hat

  7. How Red Hat Cracked the Open-Source Code – Medium https://medium.com/@wendyloh_1819/how-red-hat-cracked-the-open-source-code-the-journey-from-free-software-to-a-34-billion-exit-f5454acba5c3

  8. The Red Hat model only worked for Red Hat | Open Core Ventures https://www.opencoreventures.com/blog/the-red-hat-model-only-worked-for-red-hat

  9. Doubling down on open, Part II | Elastic Blog
    https://www.elastic.co/blog/licensing-change

  10. FAQ on Software Licensing | Elastic
    https://www.elastic.co/pricing/faq/licensing

  11. Is MongoDB Truly Open Source? A Critical Look at SSPL – Percona
    https://www.percona.com/blog/is-mongodb-open-source/

  12. Navigating unexpected license changes in open source software – SD Times: https://sdtimes.com/os/navigating-unexpected-license-changes-in-open-source-software/

  13. Server Side Public License – Wikipedia
    https://en.wikipedia.org/wiki/Server_Side_Public_License

  14. Richard Stallman – Wikipedia
    https://en.wikipedia.org/wiki/Richard_Stallman

  15. What is free software? – Free Software Foundation
    https://www.fsf.org/about/what-is-free-software

  16. Free software movement – Wikipedia
    https://en.wikipedia.org/wiki/Free_software_movement

  17. The Free Software Definition – Wikipedia
    https://en.wikipedia.org/wiki/The_Free_Software_Definition

  18. Why Open Source Misses the Point of Free Software – GNU Project: https://www.gnu.org/philosophy/open-source-misses-the-point.en.html

  19. Eric S. Raymond – Wikipedia
    https://en.wikipedia.org/wiki/Eric_S._Raymond

  20. History of the OSI – Open Source Initiative
    https://opensource.org/history

  21. Open Source Initiative – Wikipedia
    https://en.wikipedia.org/wiki/Open_Source_Initiative

  22. Bruce Perens – Wikipedia
    https://en.wikipedia.org/wiki/Bruce_Perens

  23. Open-source software movement – Wikipedia
    https://en.wikipedia.org/wiki/Open-source_software_movement


💹

Comments

Popular Posts