Should Your Developer Company Go Open-Source?

A decision framework for founders who want leverage, not vibes

I’ve been asked a few times about my approach to open-source in the past few weeks, so decided to write this article to structure my thoughts.

Most founders get the open-source decision backwards. They start with “open-source is great for distribution” and work backwards to justify it.

That’s how you end up with:

• an OSS project nobody meaningfully contributes to,

• a “community” Slack that is actually a support queue,

• and a monetization strategy that competes with your own free tier.

Open-source is not a distribution hack. It is an architectural decision about your product, your business model, and your execution bar.

The wrong one is expensive to reverse.

After building Airbyte into a large open-source data infrastructure company, I’ve been asked dozens of times: Should we go open-source?

Here is the framework I use to answer that question.

1. Open-source is not a value statement. It’s a strategy.

“Developers love open-source.”
“Open always wins.”
“Proprietary is dead.”

None of these are useful statements. The only question that matters is this: Does open-source structurally help this product win?

Win can mean:

• faster adoption,

• stronger defensibility,

• lower customer acquisition friction,

• or better long-term monetization.

If you cannot explain how OSS compounds one of those for your specific product, you are not making a strategic choice. You are following vibes.

2. Start with your user, not your philosophy

A hard filter first: Only technical users are emotionally sensitive to open-source.

Builders care about OSS for:

• inspecting and trusting code,

• self-hosting and control,

• extensibility,

• learning and ideology.

Non-technical buyers still care about OSS, but instrumentally:

• lower vendor risk,

• easier internal adoption,

• reduced lock-in,

• better auditability.

This distinction matters because it leads to the most important OSS test.

3. The federation test: does user = contributor?

There are two fundamentally different OSS community shapes.

Federation-type OSS

• Many users

• Many contributors

• The product improves as the community grows

This only works when the user persona and contributor persona are the same, or at least sit in the same team.

Airbyte worked because data engineers used connectors and built connectors. Most infra and data projects follow this pattern. Now flip it.

An open-source Segment-like product would have:

• PMs as users

• data engineers as contributors

That breaks the loop. When contributors are serving users rather than being users, you don’t get federation. You get a stadium.

4. Stadium vs federation is not semantics. It changes outcomes.

Federation OSS

• Strong network effects

• Contribution velocity compounds

• Tends toward standards

• Winner takes most

Stadium OSS

• A small core team builds

• The community watches, occasionally extends

• No inherent product network effect

• Multiple winners can coexist

Neither model is bad. Confusing them is lethal. If you expect community contributions without persona alignment, you will wait forever.

And yes, in federation-type OSS, winner takes most. Not because of ideology, but because contributors optimize for impact per hour and visibility. Nobody wants to maintain the 7th most popular orchestrator.

In practice, markets converge to one to three leaders. Rarely more, in both cases.

5. Problem maturity matters more than code quality

Open-source works best on well-understood problems.

Why?

Because the market already has:

• shared vocabulary,

• established mental models,

• clear comparison points.

OSS required market education when it has to do category creation and community creation at the same time. While it doesn’t mean it can’t be successful, it requires some extra efforts.

6. OSS wins by bypassing permission, not by being “free”

One of the strongest OSS adoption drivers is data sovereignty. Open-source is self-hosted by default. That matters less because of cost and more because of speed. Procurement is slower than curiosity.

OSS lets engineers start:

• without security review,

• without vendor onboarding,

• without legal approval.

This is why OSS is such a powerful bottom-up wedge in data, infra, and security. Sensitive data and high blast radius amplify this effect.

Important framing shift: OSS is not the product. OSS is the entry point.

7. Extensibility and control are double-edged swords

Extensibility is a legitimate OSS advantage. It is also how many OSS companies destroy themselves.

Extensibility only works if:

• extension points are explicit and stable,

• the core stays boring,

• contributors do not fork the roadmap.

Here is the uncomfortable truth: If you cannot say no to contributors, you should not run a federated OSS project.

Governance is not optional. It is part of the product.

8. Define the OSS wedge before you write code

This is where most teams fail. The question is not “what should we open-source?” The question is “what job should OSS fully solve?”

A durable pattern:

• OSS maximizes time to first value (you should measure your time to your aha moment for an OSS user, this is what will drive your OSS adoption)

• Paid solves coordination, scale, and risk

At Airbyte, OSS fully solves the single-user use case. One engineer moving data from A to B, fast.

Anything involving:

• teams,

• scale,

• reliability guarantees,

• governance,

• or operational coordination

…does not belong in OSS.

This does two things simultaneously:

• maximizes bottom-up adoption,

• preserves a clean, non-hostile path to monetization.

If your OSS roadmap starts accumulating enterprise features, your conversion rate will collapse. Slowly at first. Then all at once.

9. OSS expands the market because most companies build

Most companies build before they buy. And when engineers build, they start with open-source. Not because they hate vendors, but because OSS accelerates learning and reduces early risk.

That’s why OSS increases market size. You address both build and buy.

Now add a new variable. AI is rewriting how companies build. Faster, cheaper, and messier.

A new question founders must ask: Does my OSS product compose with AI-assisted building, or compete with it?

Individual code is increasingly commoditized. Ecosystems, connectors, and battle-tested surfaces are not.

10. Hosting your OSS might not be a revenue strategy

This deserves to be explicit.

Cloud-hosting your OSS project is:

• a distribution convenience,

• a pricing anchor,

• a control plane.

It is not differentiation. If a more mature cloud solution already exists, OSS will not magically erase that gap.

Extensibility, control, deployment flexibility, all of that are differentiators. To be clear, I’m not advocating that all OSS companies should have a self-hosted premium solution primarily. My point is that we should focus on differentiations, which ones resonate the most with which audience for which budget. This should drive your product strategy.

11. The hidden costs nobody likes to talk about

Open-source raises the execution bar.

You sign up for:

• permanently high documentation quality,

• public roadmap discipline,

• backward compatibility paranoia,

• community support at scale.

OSS also locks in decisions early. APIs, data models, and extension points become public contracts.

Ask yourself early: which mistakes am I willing to live with for the next ten years?

Because you will.

A final decision stack

Before committing to open-source, you should be able to answer yes to most of these:

• Is my user persona technical?

• Is my contributor persona the same as my user persona?

• Is the problem already well understood?

• Does OSS bypass a real adoption bottleneck?

• Can I clearly define the OSS wedge and the paid boundary?

• Can I say no to contributors?

• Does my business survive a fork?

If not, closed-source is not a failure. It is often the smarter move.

Open-source is powerful. But only when it is deliberate.