It's GitHub, Not GitHope
4 open source battlefields. Airbyte picked right. Iceberg picked wrong.
Open source isn’t charity—it’s competitive strategy.
If you can’t name the specific business outcome you’re trying to achieve, you’re not “doing open source.” You’re publishing code and hoping the internet turns it into distribution.
So do this before you touch a license or write a README:
Name the outcome. Pick the battlefield.
There are only four real outcomes open source reliably produces:
Market-making: make a standard exist so you can win the market it creates.
Ecosystem: get other people to extend your product and build businesses on top of it.
Reputation: become the trusted expert so users, talent, and buyers come to you.
Exploration: learn what the market actually wants before you bet the company.
Pick one. Most teams pick zero. They ship a repo, write a launch post, and wait for GitHub stars to become revenue by osmosis. Two years later: drive-by PRs, “community,” and no business impact.
And if you pick the wrong battlefield, you don’t just waste time—you can lose the war you thought you were fighting.
June 4, 2024: Databricks announced it would acquire Tabular—the company founded by Apache Iceberg’s original creators. Iceberg was supposed to disintermediate Databricks. Instead, the commercial center of gravity ended up inside the incumbent.
Iceberg the project won adoption. Tabular the company lost the business war.
#1 Market-making wars: To win a standard, you have to give it away
The objective: Make the market exist so you can win it. Create a protocol/format that breaks an incumbent’s lock-in—and turns your product into the obvious “best implementation” of the new default.
What you sacrifice: Control. You’re trading ownership for adoption. You’re betting the pie grows faster than your slice shrinks.
How you die: You succeed technically…and lose commercially. You create the standard, then a bigger player becomes the center of gravity (distribution, enterprise deals, defaults), and you become “the people who started it.”
You’re in a market-making war if…
You keep saying “we need this to become the standard” unironically.
Your buyer won’t switch unless the ecosystem around the thing exists (connectors, integrations, vendor neutrality).
Your “competitor” isn’t a product—it’s a lock-in (cloud defaults, proprietary formats, entrenched workflows).
If the market stays fragmented, you lose. If it converges, you finally have a shot.
Do this next week
Write the disintermediation sentence.
“If this becomes the standard, it breaks ____’s lock-in by decoupling ____ from ____.”
Choose whether you’re actually willing to give it away.
Market-making requires real openness—commercial reusability included. If you restrict commercial use, you’re not fighting a standards war. You’re doing controlled distribution and calling it a revolution.
Define where you control the standard.
Winning a standard is rarely about the license alone. The real leverage usually sits in one or two places:
who ships the default (managed service, marketplace, cloud console)
who controls compatibility (test suites, certification, “works with” badges)
who owns governance and the name
If you can’t point to at least one control point, you’re not market-making.
You’re donating infrastructure.
What it looks like in the wild
When Google open sourced Kubernetes, they weren’t being benevolent. They were disintermediating AWS. Kubernetes decoupled container orchestration from any single cloud, weakening the lock-in layer and shifting power to the clouds that executed best around it.
Databricks played the same game with Delta Lake. Open table formats threatened “Databricks clones,” so open sourcing Delta was a standards move: win the format, slow competitor convergence, keep control of the commercial center of gravity.
MongoDB did it for NoSQL. The category needed a shared language across ecosystems—drivers, integrations, tooling. That only happens when commercial actors can participate freely.
And then there’s the nightmare outcome.
Iceberg had the technical win. Engineers loved it. Adoption grew. But Tabular couldn’t win the business war fast enough. Databricks announced it would acquire Tabular—the company founded by Iceberg’s original creators. The project meant to disintermediate the incumbent ends up with its commercial center of gravity inside the incumbent.
That’s the core danger of a market-making war:
You can be right. You can even win adoption.
And still lose the war.
If you’re not willing to truly give it away—and you don’t have a plan to become the default implementation—you’re not market-making.
You’re cosplaying.
#2 Ecosystem wars: Ecosystems only work until you try to tax them
The objective: Get other people to build your product for you. Plugins, modules, connectors, templates, integrations, consultants—an economy that extends your surface area faster than your team ever could. You become the hub everyone orbits.
What you sacrifice: Future extraction flexibility. The ecosystem only forms when builders believe they can create their own commercial value on top of you—without asking permission every step of the way.
How you die: You win adoption…then panic and overtax. You change the rules once the ecosystem depends on you. The builders fork, the partners leave, and the center of gravity snaps away from you overnight.
You’re in an ecosystem war if…
Your roadmap is fundamentally unscalable without third parties (there are too many “edges”).
The “real product” is hundreds of integrations, not one killer feature.
You want consultants and agencies selling implementations because that’s your distribution.
Your best case is: a thousand small businesses depend on you, and that dependence compounds.
Do this next week
Define what third parties should build—and what they must never need you for.
List the top 10 extensions you want outsiders to create (modules, connectors, add-ons). Then draw the boundary: what’s core, what’s extensible, what’s off-limits. If builders can’t predict the boundary, they won’t invest.
Write the “tax policy” before you have leverage.
Ecosystems don’t die because companies monetize. They die because monetization feels like rule-changing. Decide now: what will always remain open? What will be paid? What’s the line you won’t cross once people bet their livelihoods on you?
Pick a license that matches the war.
Ecosystem wars require commercial reusability. If third parties can’t legally sell on top of you, you’re starving the ecosystem’s oxygen supply.
What it looks like in the wild
WordPress didn’t win because Automattic built everything. It won because millions of creators, agencies, and plugin businesses made money on top of it. The ecosystem was the moat.
Terraform did the same thing in infrastructure-as-code: modules, providers, consulting practices, enterprise integrations—an entire economy orbiting HashiCorp’s center.
Then comes the inevitable trap: at some point you want to capture value.
You attracted builders by being open. Now you want to extract.
That’s where ecosystem wars are decided.
HashiCorp pushed too hard. The move to the Business Source License signaled: “Those commercial uses you built? Now you need our permission.” The ecosystem responded the only way it can: OpenTofu forked—fast.
If your goal was ecosystem longevity, that was catastrophic. If your goal was liquidity, maybe it was rational—IBM closed the acquisition on February 27, 2025 for $6.4B.
But here’s the punchline:
You can run the attract-extract play once.
After you change the rules, the ecosystem won’t trust you a second time.
If you’re in an ecosystem war, your main enemy isn’t a competitor.
It’s your own temptation to tax too early, too hard, and too unpredictably.
#3 Reputation wars: Win the conversation before you try to win the market
The objective: Become the trusted expert. Use open source to earn credibility, mindshare, and talent—so when buyers show up, you’re the default choice before they compare features.
What you sacrifice: Speed to “big outcomes.” Reputation compounds slower than a standards win. You don’t get to declare victory with a protocol everyone adopts. You build authority brick by brick.
How you die: You ship code and call it “community,” but never become the reference point. No point of view. No teaching. No narrative. Your repo exists, but your name doesn’t.
You’re in a reputation war if…
You don’t have distribution, but you can earn trust.
The buyer needs conviction (“this is safe, real, credible”) more than they need a spec.
Your product category is fuzzy and people need vocabulary to even describe the problem.
The best talent you want could choose ten other companies—credibility is your recruiting weapon.
Do this next week
Pick the hill you’re going to die on—opinionated and specific.
Not “we’re open.” Not “we’re modern.” A real stance: “X is broken because Y, and the new default is Z.” If your thesis can’t offend anyone, it can’t recruit anyone either.
Turn your repo into a credibility machine.
One golden path demo. One “why” doc that teaches the mental model. One brutally honest “when not to use this.” The goal isn’t completeness—it’s trust.
Make contribution legible.
Clear issues, fast maintainer feedback, public roadmap signals. Reputation is built in the comments section. If contributors feel ignored, you don’t look “open.” You look understaffed.
What it looks like in the wild
dbt Labs didn’t win a standards war. They didn’t build a giant plugin economy first. They won a reputation war so hard it turned into category creation.
Before dbt, “analytics engineering” wasn’t a job title. It wasn’t an identity. dbt didn’t just ship a tool—they packaged a worldview: how analytics should be built, tested, reviewed, deployed. Then they reinforced it with community, content, and a clear point of view.
The open source project let practitioners try it without permission.
The community let them talk about it with peers.
The content let dbt own the language.
Every “analytics engineer” job posting is a downstream win—even at companies that don’t use dbt.
That’s the power of a reputation war: you win the conversation first, and the market follows later.
If you’re early-stage, this is the most underrated battlefield. It’s survivable, it’s compounding, and it doesn’t require you to outspend incumbents.
You just have to be relentlessly useful—and unmistakably opinionated.
#4 Exploration wars: Use open source to learn before you commit
The objective: Reduce risk. Validate demand, discover real use cases, and let users tell you what matters—before you spend 18 months building the wrong thing.
What you sacrifice: Ego. Exploration requires admitting you don’t know yet. It’s not “we’re the standard.” It’s “help us find the truth.”
How you die: You treat it like reputation (“look at our stars!”) instead of learning. You optimize for optics, not signal. You collect GitHub applause and miss the actual product insight.
You’re in an exploration war if…
You’re not sure who the real user is, or what they’ll pay for.
You suspect there are 3–5 different use cases and you need to see which one bites hardest.
Your market is noisy and everyone claims demand, but nobody has pull.
You need real-world edge cases more than you need more code.
Do this next week
Instrument for signal, not vanity.
Track: what gets installed, what gets configured, where people drop, what issues repeat. Stars are applause. Usage is truth.
Force feedback into the product.
Add a “what were you trying to do?” prompt in docs/issues. Add templates for bug reports that capture context. Your goal is to extract use cases at scale.
Write the pivot criteria now.
“If we see repeated demand for X from Y users, we commit.”
“If we don’t see it by Z, we kill it or reposition.”
Exploration without decision rules becomes endless wandering.
What it looks like in the wild
Exploration is how you earn the right to escalate.
It’s also how you de-risk buyers: enterprise customers like open source because it’s a hedge. Even if you die, the artifact survives. That check-box alone closes deals sometimes—not because they expect you to fail, but because procurement needs the exit hatch.
The founders who win treat open source like a radar system:
ship → observe → learn → narrow → commit.
If you start with market-making ambition when you only have exploration-level understanding, you don’t look bold.
You look doomed.
You’re not Databricks: Pick the war that fits your position
Most founders describe their open source strategy using market-making language.
“We’re going to be the standard.”
“We’re going to disintermediate X.”
“We’re building the open alternative to Y.”
That’s not a strategy. That’s a vibe.
Here are the three questions that decide whether you’re being real—or just repeating the Databricks soundtrack:
1) Do you have distribution to win a standards battle?
Market-making wars are won by whoever becomes the default in enterprise buying paths: cloud marketplaces, managed services, procurement relationships, integrations, benchmarks, the “recommended” button.
If you don’t control a channel that can make you the default, you can still create the standard—but you can’t guarantee you’ll own the center of gravity.
That’s how you end up as the Wikipedia footnote.
2) Do you have 3–5 years of runway to wait for ecosystem effects?
Ecosystems don’t form on your timeline. They form when enough third parties believe they can build real businesses on top of you—then slowly, visibly, they do.
If you need monetization this quarter, you’ll be tempted to tax early, change terms, or close doors.
That temptation is the fork factory.
3) Can you survive if a bigger player adopts your standard and out-executes you on it?
This is the Iceberg nightmare: you win technically, the market converges, and the incumbent simply absorbs the commercial surface area.
If the answer is “no,” market-making isn’t brave. It’s suicidal.
You can’t afford to give it away like Google
Google could give away Kubernetes because the payoff wasn’t Kubernetes revenue. It was cloud leverage. Weakening AWS’s lock-in was worth far more than anything they could charge for orchestration.
Databricks can fight market-making wars because they have distribution, budget, and the ability to buy outcomes—sometimes literally by acquiring the winners of wars they didn’t start.
You probably can’t.
So stop asking: “Which war sounds best in a pitch deck?”
Start asking: “Which war can we actually win?”
4 Questions to tell which war you are actually in?
Do you need the market to exist before you can win it? → Market-making war.
You’re trying to create a standard that disintermediates an incumbent.
Do you need others to extend your product? → Ecosystem war.
You’re trying to become the hub developers and partners build on.
Do you need credibility, talent, or early demand? → Reputation war.
You’re trying to own the conversation so adoption follows.
Do you need to learn before you commit? → Exploration war.
You’re trying to derisk, discover pull, and find the real wedge.
Sequence matters: Airbyte’s path is the blueprint
Airbyte didn’t become a unicorn by opening a repo and hoping.
They escalated the battlefield based on stage:
Reputation first: earn trust with data engineers, show up relentlessly, prove you understand the pain.
Exploration alongside it: learn which connectors mattered, which workflows were real, where incumbents were weakest.
Ecosystem next: let others extend the surface area faster than the core team could.
Market-making only after: once they had earned distribution and legitimacy, they could fight bigger wars.
That’s the point most teams miss.
They start with market-making ambition when they only have exploration-level understanding and reputation-level resources.
And then they’re surprised when “open” doesn’t turn into “outcome.”
Pick the battlefield that matches your resources, your timeline, and your position.
Because two years from now, you’ll either have a business outcome you can point to—
or a repo with a lot of stars and a blog post you barely remember writing.