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.

“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.

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:

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

There are two fundamentally different OSS community shapes.

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:

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

Federation OSS

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.

Open-source works best on well-understood problems.

Why?

Because the market already has:

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.

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:

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.

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.

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:

…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.

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.

This deserves to be explicit.

Cloud-hosting your OSS project is:

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.

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.

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.