Building an Open Source Gateway to Sell an Enterprise Platform

Building an open source gateway to sell an enterprise platform

I built an open source API gateway. Apache 2.0 licence. Anyone can use it, fork it, sell it. The goal was not charity. The goal was to sell an enterprise platform.

This is the story of why I did it, what I put in the open source version, what I kept for the enterprise version, and what I got wrong.

Why open source first

Enterprise software sales have a trust problem. A VP of Engineering does not buy a platform because a sales deck looked nice. She asks her engineers: "Have you used this?" If the answer is yes, the sale is warm. If the answer is no, the sale is cold.

Cold enterprise sales take 6 to 12 months. Warm ones close in weeks. The difference is whether engineers already know your product.

Open source solves this. Engineers find your gateway on GitHub. They use it for a side project, then a small service, then something that matters. By the time their company needs the enterprise version, they already trust the core. They have read the code. They have filed issues. They know how it behaves under load.

No amount of ad spend gets you there.

What goes in open source vs enterprise

Getting this wrong kills the project. Give away too much and nobody pays. Give away too little and nobody adopts.

The split I chose: the data plane is open source. The control plane is enterprise.

The data plane is the thing that handles requests. Routing, authentication, rate limiting, circuit breaking, AI proxy. This is what individual developers need. This is what gets adopted on GitHub. This is what builds the community.

The enterprise version adds everything an organisation needs when they run the gateway at scale across teams. Ontology intelligence. Governance rules. Compliance reporting. Multi-tenant isolation. A plugin marketplace.

This is not a new idea. GitLab did it with CE and EE. Elasticsearch did it. Redis did it. The pattern works because it maps to how companies actually buy software. Individual engineers adopt the free thing. Then someone needs audit logs, SSO, or tenant isolation, and that is when procurement gets involved.

The community effect

I did not expect how much the community would improve the product.

When you have a hundred companies running your gateway, you get bug reports your QA team would never write. Edge cases with specific cloud providers. Strange timeout behaviour behind particular load balancers. Memory leaks that only show up after 72 hours of steady traffic.

Contributors fixed things I did not know were broken. Someone in Berlin rewrote the retry logic to handle connection pools better. A team in Sao Paulo found a race condition in the circuit breaker that only appeared under very specific traffic patterns. These are problems that internal testing does not catch because internal testing does not have enough variety.

But community contributions need review. Every pull request takes time. Some are good. Some are not. Some are well-intentioned but break something else. You need maintainers who can say no without being rude. That is harder than it sounds.

The honest downsides

Open source is expensive. Not in licence fees, but in time.

Most open source users will never pay you anything. They will file issues, ask questions in Discord, and expect responses. Supporting them is part of the deal. If you ignore them, the community dies. If you spend all your time on them, the enterprise product stalls.

Feature requests create tension. The community wants things that make the open source gateway better for individual use. The enterprise roadmap wants things that make organisations pay. Sometimes these overlap. Often they do not. A community member wants a dashboard. The enterprise team needs RBAC. You have the same engineers building both.

Then there is licensing. I chose Apache 2.0. This means anyone can take the code, modify it, and sell it without giving anything back. A cloud provider could wrap my gateway in a managed service tomorrow and I would have no legal recourse.

I chose Apache 2.0 anyway because restrictive licences slow adoption. BSL and AGPL scare corporate legal teams. When a developer at a bank wants to try your gateway, the first thing that happens is a licence review. Apache 2.0 passes that review in a day. AGPL can take months, and sometimes the answer is no.

Yes, some companies will take the open source code and never buy the enterprise version. I decided that faster adoption was worth more than the revenue I might lose. So far, that bet has held.

The revenue model

The enterprise platform is where the money comes from. The open source gateway is the top of the funnel, not the product itself.

Enterprise customers pay for the things they cannot build themselves quickly. Governance that maps to their compliance framework. Tenant isolation that their security team will approve. An ontology layer that understands their API estate. Building any one of these properly takes months.

There is also a plugin marketplace with revenue sharing through Stripe Connect. Third party developers build plugins for the gateway. They set their price. We take a percentage. The marketplace gives other developers a reason to extend the platform. More plugins means more use cases covered, which means more users, which means more enterprise buyers.

The plugin marketplace is still early. But the logic is sound. Every plugin someone else builds is a feature I did not have to build. Every plugin that solves a niche problem makes the gateway relevant to a company that might not have considered it otherwise.

What I would do differently

I underestimated how much time community management takes. Hire a developer advocate earlier than you think you need one.

Another mistake: I waited too long to draw the line between open source and enterprise features. Some things I gave away early should have been enterprise from the start. Once something is open source, you cannot take it back without destroying trust. Be deliberate about that boundary on day one.

The open source gateway works as a go-to-market strategy. It is not free. It costs engineering time, support time, and the constant discipline of maintaining two versions of a product. But when a VP of Engineering calls your sales team and her engineers already use the open source version, you are not selling. You are just agreeing on a price.