Born Open Startup
A startup that is "Born Open" is one that rejects the traditional notion of proprietary knowledge appropriation (e.g., obtaining patents). For these companies, software patents are often viewed as an obstacle rather than an asset.
Instead, a Born Open startup views itself as part of an ecosystem. These firms typically operate autonomously but share interconnected goals, participating in a community with shared governance to prevent the exclusive appropriation of technology.
The Philosophy of Open Strategy
According to Mekki MacAulay (2010):
"Open strategy involves the collective production of a shared good in an open fashion such that the resulting product is available to all, including competitors. In the case of open entrepreneurship, 'born-open' startups are entrepreneurial ventures whose business models are designed specifically based around a collective good."
If the technology is viewed as a hub that connects a network of stakeholders, it forms a value network that nurtures the technology. This creates a self-reinforcing virtuous circle where the shared resource becomes more valuable for all players.
Business Models: How to Monetize "Free"
Open source flips the conventional IP paradigm. It operates on the philosophy that shared effort is more efficient and effective than closed systems. West and Gallagher (2006) suggest four strategies for capturing value:
- Pooled R&D: Lowering innovation costs by sharing the development burden with a community. Competitors in the same industry often collaborate on foundational, non-differentiating infrastructure. By contributing to shared open-source projects (such as the Linux kernel or Kubernetes under the Cloud Native Computing Foundation), companies drastically reduce their individual Research and Development expenses. They avoid reinventing the wheel, share the maintenance burden, and instead focus their proprietary budgets on unique, user-facing features that drive their actual revenue.
- Spinouts: Creating independent ventures that require less direct investment while still benefiting the parent. A tech company may develop a powerful internal tool, open-source it, and spin it out as a separate foundation or startup. This allows the new entity to attract external venture capital and community contributions, reducing the parent company's financial risk. The parent continues to benefit from the technology's rapid, ecosystem-driven maturation without having to fund the entire engineering team. A notable example is Google releasing Kubernetes (inspired by its internal Borg system) to the open-source community, which ultimately fostered an ecosystem that drove heavy adoption of containerized cloud services.
- Selling Complements: Offering paid services, hardware, or premium features on top of a free core. Frequently referred to as the "Open Core" model, businesses offer the base software at no cost to remove friction, build massive user bases, and establish industry standards. They then monetize by selling enterprise necessities. These complements often include fully managed cloud hosting (SaaS platforms), advanced security tools (like Single Sign-On and compliance auditing), proprietary analytics, and dedicated 24/7 technical support. Companies like MongoDB, Elastic, and Automattic (WordPress) rely heavily on this strategy.
- Attracting Donations: Accelerating development through external contributions of code or resources. In the open-source ecosystem, "donations" encompass both financial backing (via corporate grants, Open Collective, or GitHub Sponsors) and invaluable "sweat equity." When a community rallies around a project, external developers contribute by fixing bugs, translating documentation, testing edge cases, and building new features. This crowdsourced labor effectively serves as an extension of the core engineering team, vastly increasing the project's velocity and resilience without adding to the traditional payroll.
The Concept of "Forking"
When factions in an open source community disagree about the future direction of the technology, they may create a Fork.
This occurs when a project develops a separate work stream from the main trunk. There are two primary types:
- Community Forks: Driven by users to maintain momentum, preserve open-source philosophies, or ensure continued community governance. A prominent example is the evolution of MariaDB from MySQL. In 2009, following Oracle's acquisition of Sun Microsystems (which owned MySQL), the original lead developer of MySQL, Michael "Monty" Widenius, created the MariaDB fork. This was done out of concern over Oracle's stewardship and future licensing changes, ensuring that a highly compatible, "drop-in replacement" database would remain freely available and fully open-source under the GNU General Public License.
- Commercial Forks: Used to develop a stable, enterprise-grade product—often with paid support and proprietary branding—without infringing on the original stream's licensing. For example, Red Hat Enterprise Linux (RHEL) operates as a commercial derivative of the upstream, community-driven Fedora project. Red Hat takes the bleeding-edge open-source code from Fedora, rigorously tests and stabilizes it, and packages it into a commercial subscription model. While the underlying source code remains open in compliance with licenses like the GPL, Red Hat strictly protects its trademarks and proprietary support binaries, successfully commercializing the software while still contributing upstream.
Sustainability: Can Code be Immortal?
Open source philosophy argues that project artifacts should be preserved for the collective. However, sustainability requires a minimum level of attention from a critical mass of investors or developers to ensure the technology survives even if the original creators move on.
In reality, software does not exist in a vacuum. Code that is completely abandoned quickly falls victim to bit rot or software decay. While the source code itself doesn't physically degrade, the ecosystem around it—compilers, operating systems, hardware architectures, and third-party dependencies—constantly evolves. Without active maintainers to patch security vulnerabilities, update deprecated APIs, and ensure modern compatibility, a once-thriving project will eventually break and become a liability rather than an asset.
This friction highlights a critical human vulnerability in open source: the "bus factor" and maintainer burnout. Many foundational pieces of the modern internet (as seen in incidents like the Log4j vulnerability or OpenSSL's Heartbleed bug) are often maintained by solo developers or small, unfunded teams working as volunteers. When these individuals face burnout, lose funding, or shift their focus, the project stagnates. True longevity requires moving beyond passion to establish resilient community structures.
To achieve actual sustainability, the tech industry has increasingly turned to institutional stewardship. Organizations like the Linux Foundation, the Apache Software Foundation, and corporate sponsorship programs help transition critical projects from individual endeavors into supported infrastructure. By providing legal frameworks, funding for routine maintenance and security audits, and a neutral ground for competing companies to collaborate, these foundations supply the continuous energy required to keep the code functional.
Ultimately, there is a stark difference between archiving code and sustaining it. Initiatives like the GitHub Arctic Code Vault or Software Heritage can preserve source text for millennia as historical artifacts. But for software to remain "immortal" in a practical, living sense, it requires the ongoing, active metabolism of a dedicated human community.
Video Overview: Open Source Economics
References
E15, Part 1: Mekki MacAulay, world's top open-source strategy expert for enterprises, RedHat
Featuring Mekki MacAulay • Published: March 2021 • Source: RedHat
In part one of this episode, enterprise open-source strategy expert Mekki MacAulay discusses how large organizations leverage open-source models, community ecosystems, and collaborative architectures to build competitive advantage and drive enterprise-level digital transformations.
Related Theories
To disrupt the Closed Tech Giants, you must rely on West & Gallagher's (2006) models: build a massive ecosystem, pool community R&D, and sell complements to survive.
Reach 100 Code Quality before the Closed Giants crush you, and don't let Capital hit $0!