GTM Playbook for Open Source
Why donating your open source project to a neutral foundation before you need the trust is the GTM decision
Enterprises scale mission-critical open source around foundation-backed projects
When I moved to Switzerland in March 2022 after the war in Ukraine started, I spent the better part of a year at VSHN AG building ISV partnerships and selling managed cloud services, Kubernetes specifically. The company was interesting in two ways: it was governed by Sociocracy 3.0 principles, and it was open source to its core.
What I really enjoyed was being in the room when the decisions were made: which platforms to certify, which vendors to stake client relationships on, which open source foundations to trust enough to build a delivery practice around.
What I noticed then, and haven’t stopped thinking about since, is that the open source companies that earned deep SI commitment all had something in common. It wasn’t the GitHub star count. It was the adoption rate and compatibility in the stack. It was an answer to the question every SI partner manager asks, usually in private:
“If this company disappears, folds, or gets weird, am I stuck?”
The ones who had a good answer all had a neutral foundation holding their core IP. The ones who didn’t, we hedged our bets. We kept one foot out the door. We recommended, but we didn’t commit.
Bill Gurley published a timely piece in May 2026 called “From Open Source Software to Open Source Strategy” that names the pattern with precision. You breathe open source in SF; it’s a trend but also a necessity. And I’m having a version of the same conversation with early-stage tech founders.
Gurley conducted fundamental research. What I would like to double down on is what the GTM playbook actually looks like in today’s practice. I want to examine a live example unfolding this year, one layer down the stack from anything Gurley wrote about.
Adoption: 55% of enterprise operating systems and 49% of cloud infrastructure now run on open source
IBM spent $34B acquiring Red Hat in 2019, $6.4B for HashiCorp in early 2025, and $11B for Confluent in March 2026. Salesforce paid $6.5B for MuleSoft in 2018. The Linux Foundation’s 2025 State of Global Open Source report found that open source now runs 55% of enterprise operating systems, 49% of cloud and container infrastructure, and 40% of AI/ML workloads. The most-cited benefit in that same survey was reduced vendor lock-in, at 84% of respondents.
In other words, open source wins in the enterprise, and it’s no longer a question of engineering effort or security. The question is about stack compatibility, maintenance, and the business model built around it.
The canonical open-source model, in my opinion, is the Red Hat model: release an open source project, build a company around service, support, and value-added commercial features on top. Distribution is free. Revenue comes from what sits above the open layer. There’s a second, more powerful pattern, one that’s less about building a business and more about winning a strategic war. We’re seeing this second pattern, Open Source Strategy, more often. It has been deployed at least six times in the past fifteen years with results that reordered entire industries.
4 ingredients of the Open Source Strategy
Most successful Open Source Strategy plays share 4 elements.
1. Named adversary
The adversary has to be a specific company whose lock-in or pricing power is costing everyone else real money: Apple's iPhone for Android, AWS's cloud ecosystem for Kubernetes, Google's mapping monopoly for the Overture Maps Foundation. The adversary is the reason followers rally. Name an enemy, and a project becomes a movement.
2. Neutral foundation
The Linux Foundation, Apache Software Foundation, Cloud Native Computing Foundation, and Eclipse Foundation all serve the same function. These bodies hold the open source project's IP in trust, enforce licensing, manage governance, and, most critically, ensure that no single company can recapture what was donated. This is what separates Kubernetes from Android.
3. Formal alliance with written commitements
The Open Handset Alliance had written commitments from Nokia, HTC, Samsung, and Motorola before Android launched publicly. CNCF has formal membership tiers with contribution obligations. A community is people who use your software. An alliance is companies that have formally committed to building on your platform and will be harmed if it fails. The difference is legally and commercially meaningful.
4. Commercial layer must stay proprietary
The open source project is distribution. Revenue comes from the managed cloud version, the enterprise support contracts, and the partner certification program. The founding company captures value from the services layer, not from taxing the open layer. This is why the ecosystem trusts the open layer: no one is extracting rent from it.
What I find most interesting is the intrinsic motivation. Most open source plays are defensive. The goal isn’t to beat the incumbent. The goal is to reduce the incumbent’s power over you.
The ultimate goal in the GTM for open source is not about revenue or the valuation. You are making the incumbent’s pricing power or lock-in irrelevant to everyone who follows you.
Why Kubernetes, OCP, and RISC-V succeeded where Android and Apollo got recaptured
Android (2007): 73% global handset share, zero neutral foundation
Google launched it to prevent Apple from doing to mobile what Microsoft did to desktop via Windows. The Open Handset Alliance was real. The result was real: 73% of global handsets, 3.9 billion active devices. But Google kept control. There was no neutral foundation. By tying Google Maps, Gmail, and the Play Store to the "Google-approved" version of Android, Google effectively recaptured the platform it called open. The play worked commercially. It didn't work as an "Open Source Strategy" in the full sense.
Open Compute Project (2011): $132B in 2025 infrastructure spend from donated hardware designs
Meta open-sourced its internal data center hardware designs and donated them to a foundation. The adversary was traditional hardware vendors charging 60% gross margins. OCP-recognized infrastructure spending is estimated at $132B in 2025, growing to $295B by 2029. Zuck didn’t need to build a new business from OCP. It needed to eliminate supplier pricing power. Every dollar not going to hardware vendor margins flows to Meta’s bottom line. Classic defense.
Kubernetes (2014): 82% production adoption, AWS now a Platinum CNCF contributor
Probably the most important case for founders to understand. Google took its internal Borg container orchestration system, open-sourced it, and immediately donated it to CNCF. The adversary was AWS's cloud lock-in. The outcome: 800+ CNCF member organizations, 82% of organizations running Kubernetes in production, and AWS, the specific company Kubernetes was designed to neutralize, is now a Platinum-tier CNCF contributor. AWS had to support it because its customers demanded it. That's the classical playbook.
RISC-V (2010): 4,600+ members and 20 billion cores, governed in Switzerland
An open CPU architecture from UC Berkeley that commoditized Intel and ARM licensing fees. It's now at 4,600+ member organizations in 70 countries, with roughly 2.5 billion cores shipped annually and a projected 20 billion by 2031. It's governed in Switzerland, making it effectively sanction-proof. China has made RISC-V a national policy. The U.S. Congress has attempted to restrict open source semiconductor standards. When governments try to regulate an open source project out of existence, you know it has become globally strategically consequential.
Overture Maps Foundation (2022): Meta and Microsoft migrated off Google’s basemap in 2024
AWS, Meta, Microsoft, and TomTom founded this to commoditize Google Maps. The adversary is Google’s proprietary global map data, built at enormous cost, underpinning Search, Maps, Waze, Android Auto, and Waymo. As LLMs and AI agents need geospatial grounding, whoever controls the base map controls a hidden lever over the AI ecosystem. Overture commoditizes that layer. Production-ready 1.0 shipped in 2024. Meta migrated Facebook and Instagram basemaps to it. Microsoft uses it in Azure Maps.
The pattern is simple, but it’s not always easy to name the enemy, build a neutral foundation, form a formal alliance, and keep the commercial layer proprietary.
DeepSeek R1 (2025): $600B wiped off Nvidia in a single day, no foundation in sight
DeepSeek breaks the pattern in an instructive way, however, it belongs in my list. On January 20, 2025, the Chinese lab released R1, a reasoning model that would later be disclosed in a peer-reviewed Nature paper to have cost roughly $294,000 to train, excluding the separate $6M spent on the underlying base model. Within a week, R1 had passed ChatGPT as the top free app in Apple’s US App Store, and Nvidia lost roughly $600B in market value in a single trading day as investors questioned whether frontier AI needed anywhere near the compute spend the US labs were projecting. DeepSeek released R1’s weights under the MIT License, the most permissive open source license available, alongside 6 smaller distilled versions built on Qwen and Llama base models.
The adversary here is an export control regime. US restrictions on advanced AI chips pushed Chinese labs toward creative efficiency instead of the compute-maximalist path OpenAI and Anthropic were running: better reinforcement learning, aggressive distillation, and open release as a distribution strategy in markets where direct enterprise sales into the US and its allies were never going to be an option. R1 shipped alongside a wave of other open-weight Chinese models as part of a broader, state-supported push to make open release the default competitive posture for labs that can’t out-spend the compute leaders.
OpenAI and Microsoft alleged, and OpenAI later formalized in a memo to the US Congress, that DeepSeek had trained R1 in part on ChatGPT’s own outputs, an accusation DeepSeek has not admitted to and that remains legally unresolved. That’s distillation as an allegation of IP extraction. DeepSeek’s own distillation of R1 down into those open 1.5B to 70B parameter models is a separate and undisputed contribution: the clearest public demonstration that a large reasoning model’s capabilities can be compressed into small, task-specific models that outperform equivalent models trained from scratch. That’s a meaningful part of why the smaller, purpose-built SLMs that companies are shipping into production today score better on narrow benchmarks, accuracy, bias, and fairness included, than the general-purpose frontier models they’re distilled from.
The pattern is consistent across the cases above: name the enemy, build a neutral foundation, form a formal alliance, and keep the commercial layer proprietary.
DeepSeek shows the pattern still works with the foundation and the alliance replaced by a state’s industrial policy, a variant every founder building in or against a China-adjacent market should recognize.
Nvidia’s Nemotron: 95% indistinguishable from Claude
Every case above plays out one layer of the stack removed from where I spend most of my working time. The narrative is changing once again, and the question is:
Who owns the intelligence layer?
It's worth looking into because it's playing out in an adjacent layer of the AI stack, and it changes what "open source strategy" should mean for anyone building on top of a model provider today.
Start with the stack itself, described in its simplest form: chips, models, applications. Right now the model layer is a duopoly led by the U.S., sized roughly $60B in ARR for Anthropic and $40B for OpenAI. Anthropic has also been explicit about wanting a safety-driven regulatory regime that would tend to entrench that duopoly rather than break it up. That's a market producing concentration and a policy conversation that might ratify it.
Context: Nvidia has had a competitive open source model, Nemotron, for a while and sat on it. Nvidia might have downplayed it deliberately, since its biggest customers, OpenAI and Anthropic among them, wouldn't have loved seeing how far Nvidia's own model had progressed. That only became public after OpenAI announced its own chip ambitions, Anthropic started designing silicon, AMD closed deals with both labs, and Elon signaled he'd build his own fab. Once your best customers become your competitors at the chip layer, you stop protecting their comfort at the model layer.
Why would a chip company want a competitive, commoditized model layer at all?
If you're an application built on top of a model, you don't want to be beholden to one provider. If you're an enterprise, you don't want to hand over your proprietary data to your only option. If you're a chip company, a duopoly at the model layer is a monopsony risk at the chip layer, especially once the labs you sell to start fabricating their own silicon. Every layer of the stack (chip vendors, application builders, enterprises with something to protect) shares the same incentive: a healthy, competitive model layer with a long tail of buyers, not two.
There’s a named adversary (a model-layer duopoly, and implicitly the labs pushing to entrench it). There’s a real commercial motive for followers to rally, the same incentive structure Overture had against Google Maps. What’s missing, so far, is the neutral foundation and the formal alliance. Nemotron isn’t sitting inside CNCF or a Linux Foundation project. It’s still Nvidia’s, released to make Nvidia’s hardware and hosting stack the default way to get “good enough” intelligence for free. That’s the Android pattern more than the Kubernetes pattern: open enough to commoditize the threat, proprietary enough that the beneficiary is still the company that provides it.
The commercial mechanism showed up within weeks. On June 29, Nvidia and Palantir announced a partnership to run AI inside classified and air-gapped government systems, meaning networks cut off from the public internet. The deal pairs Nvidia’s chips and open Nemotron models with Palantir’s data software, letting agencies run modern AI on secret data without it leaving their control, and continually improve those models inside their own environments as they’re used in production. That’s the whole Android playbook in a single announcement: give away the model to make the hardware and the integration layer indispensable. No foundation touches Nemotron in this deal, and Palantir is a commercial distribution partner. The open weights are the hook. The revenue sits in the chips, the software, and the air-gapped deployment Palantir PLTR 0.00%↑ sells around them.
There’s a second thread worth naming for anyone building AI GTM right now: the deflationary economics. Token costs are most likely to fall 90% in the next three years, which changes the calculus for open-weight models generally. When intelligence is nearly free, the reason to build proprietary moats at the model layer weakens, and the reason to build them at the application and data layer strengthens. This is directly relevant to the pitfalls below: the same sovereignty vs. lock-in arguments apply. An enterprise or government agency worried about exposure through a major cloud model API faces the same duopoly dynamic, just one layer up.
The real lesson is that this pattern recurs at every layer of every stack where one or two companies have pricing power over everyone downstream. Watch which layer of your own stack has a duopoly problem. That’s where the next Kubernetes-shaped opportunity is sitting, waiting for someone to actually donate the project instead of just cracking the door open.
Failure modes that kill most open source GTM
I see the following 3 failure modes:
1. The Android trap: keeping ownership while building the ecosystem
The company retains ownership of the open source project while building the ecosystem. SIs, partners, and clients never fully trust it because the question “what happens if this company pivots or closes the source” has no good answer. Enterprise adoption plateaus. That’s Nvidia’s Nemotron position right now: it commoditizes a competitor’s advantage while keeping the asset firmly in-house.
Signs you’re in the Android trap: partners build on your platform but hedge with proprietary integrations, SIs express interest but defer formal commitment, your open source community is active while your enterprise sales cycle stretches to 12+ months.
Source: Geeksforgeeks.org. Android ecosystem
2. Commercial eclipse: how Baidu Apollo’s robotaxi business ate its open platform
The best cautionary tale here is Baidu Apollo, launched in July 2017 as “the Android of autonomous driving.” The concept was correct, and the partners were real: Toyota, BMW, Ford, Nvidia, Bosch. Then Baidu’s commercial Apollo Go robotaxi business overtook the open platform in internal resource allocation. The open platform never found a neutral foundation. The industry never coalesced. Nearly a decade later, there’s still no open standard for autonomous driving. Apollo hasn’t built a path to become the standard.
Signs of commercial eclipse: your open source project’s roadmap is set by your commercial team’s quarterly priorities, community pull requests wait months, and foundation governance stays permanently “on the roadmap.”
Source: CBInsights
3. Wrong adversary narrative: naming a technical problem instead of a threat
You describe your problem as a technical challenge rather than as an acute threat. Nobody rallies around “interoperability.” People rally around “we’re going to be held hostage by this specific company if we don’t act now.” Technical problems generate evaluation cycles. Named threats generate coalitions.
Signs of the wrong narrative: your pitch generates “interest” rather than urgency and action. Investors have no good answer to “why now,” or even worse, your answer is a TAM, SAM, SOM number.
Source: Wiki Labs Tech Insights
5-Step Playbook for Open Source GTM Strategy
Step 1: Name the adversary as a specific company, not a category
"Legacy IT fragmentation" is not an adversary. "AWS, Azure, and Google controlling government AI data under the US CLOUD Act" is an adversary. The specificity creates the urgency that creates the coalition.
Step 2: Donate to a neutral foundation to build the ecosystem’s trust
The common instinct is to wait until the project is mature, the community is large, the commercial model is proven. This is backwards. The foundation decision is what makes potential partners trust the platform enough to build on it in the first place. Donate early. The governance structure is the GTM move.
Step 3: Build a community with formal alliance with governance seats, you don’t neeed an army of followers
One credible partner with a formal written commitment, defined contribution obligations, and a governance seat is worth more than 10k GitHub stars. The founding partner tier should exist before you announce the alliance publicly. Skin in the game is the signal the rest of the market needs.
Step 4: Keep the commercial layer explicit and separate from the open layer
Open source is distribution. The business is what sits above it: managed cloud hosting pre-certified for relevant compliance frameworks, certification programs for partners who want to sell your platform commercially, enterprise support contracts productized as tiers. Clarity here prevents the most common investor objection: "if it's open, how do you make money?"
Step 5: Let the regulatory moment do its magic
The best open source plays arrive when external pressure creates urgency. You show up at the right moment with the open alternative. In European govtech right now, the EU AI Act, NIS2, and the EU Data Governance Act are doing more selling than any sales team could do alone. Your job is to be visibly and verifiably the open answer when non-US buyers start asking about the US CLOUD Act.
Pitfalls to watch for: team size, investor pricing, foundation choice, fork risk
Step 2 is simple: donate to a neutral foundation before you need the ecosystem's trust. It's genuinely hard to execute for the founders who need it most: early-stage teams building sovereignty-sensitive infrastructure for government, healthcare, or financial services, where the regulatory tailwind is strongest and the resources are thinnest. Four tradeoffs come up every time.
Team size turns donation into a second full-time job
Donating a core asset to a foundation means months of governance process, a board seat negotiation, and an ongoing engineering commitment to a body you no longer fully control. For a small team also closing enterprise contracts, that's a second full-time workstream.
Early investors priced the company on the IP a foundation would take
A state fund or early strategic investor is, in part, underwriting the value of the company's IP. Donating that IP to a foundation before or shortly after the round closes complicates the cap table story. This is easiest to resolve with venture money that expects the open layer to be a loss leader, and hardest with early money still valuing the company on the asset itself.
Foundation choice carries risk, and picking wrong is expensive
The obvious foundation on a whiteboard isn't automatically the one your actual buyers respect. Whether a procurement officer or a compliance office treats "governed by this foundation" as "trustworthy" is an open question in most sectors, and re-litigating governance a year later in front of the same buyers is expensive.
A well-resourced competitor can absorb a donation better than the founder who made it
Google could absorb the risk of Kubernetes being forked against it. A pre-seed team usually can’t. If a larger, better-capitalized vendor forks the donated project and out-executes the original team, the founder has given away the asset without capturing the commercial upside.
None of this makes the foundation step wrong. It makes it a sequencing and negotiation problem worked out over several quarters, not a single decision in a pitch deck: line up the foundation conversation early, negotiate governance terms before the round closes, and build the commercial narrative so it survives the shift from “we own this” to “we steward this.”
GTM self-audit
Open source as a strategic weapon isn’t a new idea. What’s new is the gap between how sophisticated operators understand it and how most founders actually execute it. It’s also worth watching in real time: the same fight is now breaking out at the model layer.
If you’re building on open source, 5 questions are worth checking against your current GTM:
Can you name the specific company whose pricing power or lock-in you’re commoditizing?
Is your open source project governed by a neutral foundation, or does it live inside your company?
Do you have at least one formal founding partner with written commitments and a governance seat, or just a community?
Is your commercial layer clearly separate from the open layer, with a defined path to revenue?
Are you positioned to capture the urgency of an external regulatory or competitive moment, or are you still explaining the technical problem?
If the answer to any of those is no or not yet, that’s the GTM work still ahead of you. A “not yet, and here’s why” on question 2 usually reflects the real work of sequencing a hard, resource-constrained decision correctly, a less quotable but more useful thing for founders and their CMOs to plan around than “just donate it.”
The companies that get this right build Kubernetes. The ones that don’t build Apollo.
That’s my version of the Open Source Playbook, how I see it. The work left is sequencing it deliberately, on a timeline that respects how thin early-stage resources actually are.
If you’re building GTM around an open source project right now and want a second pair of eyes on where you sit against these five questions, reply to this post, drop me a line, or visit oksanameier.com. I read every comment, and the adversary-narrative and foundation-timing questions in particular are worth working through before your next fundraising conversation.
References
Gurley, B. (2026). “From Open Source Software to Open Source Strategy.” p3institute.substack.com, May 9, 2026.
Raymond, E. S. (1999). The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O’Reilly Media.
Linux Foundation. (2025). State of Global Open Source Report 2025.
Open Compute Project Foundation. (2025). Annual Report.
Cloud Native Computing Foundation. (2025). Annual Survey Report.
Palihapitiya, C. (2026, June newsletter). Coverage of the June 29, 2026 Nvidia and Palantir partnership to run AI, including open Nemotron models, inside classified and air-gapped government systems.
This article reflects my personal analysis and experience. It is not investment advice. All data is sourced from public sources.