For most of the last decade, open source companies made money in two ways.
The first was selling to self-hosting enterprises: the project is open, the operational and compliance features: SSO, RBAC, audit logs, fine-grained policy, sometimes HA sit behind a commercial license. The second was a managed service, for teams who wanted the software but not the operational burden.
I want to argue that the second pillar was never a strong reason to be open source, and that the first pillar is now under pressure from a direction most of us didn't plan for.
The managed-service justification was always thin
If your product is good and you have a reasonable free tier, you get the "I don't want to run this myself" customer regardless of your license. Nobody picks a hosted database because the source is on GitHub. They pick it because it works and the pricing is predictable.
The customer that actually required open source was the large enterprise. They wouldn't start a procurement conversation without source access and a self-hosting path. Exit risk, audit requirements, air-gapped environments and a security team that reads code. That was the buyer open source unlocked, and that buyer was usually willing to pay for the enterprise tier because writing and owning that tier themselves was expensive.
That last clause is the part that changed.
What AI actually changes
The features we gated were rarely hard: SSO, RBAC, audit logging, custom retention policies. This is well-understood work with abundant reference implementations but they still needed to be built by hand by a team of engineers. This often meant several months of planning, iterations and constantly keeping up with the open core.
With current code generation, a competent platform team can take the permissively licensed core and build those features themselves, shaped to their own identity provider, their own policy model, their own compliance reporting. Because most of the surrounding code is open, the generated result tends to be decent as the model has the actual interfaces to work against, not a guess at them. Deployment and monitoring they were already doing, since they were self-hosting anyway. I'm watching the monitoring half of this get good in real time while building navflow.ai; it isn't finished, but the direction is not ambiguous.
So the enterprise tier, as a bundle of capabilities, is a weaker fence than it was.
Someone still has to own it
The one thing AI hasn't touched is who is accountable for the result.
Writing the code got cheap. Owning it did not. Whoever generates that internal auth layer still signs off on it, still carries it across every upstream upgrade, still gets paged when it fails at a bad hour, and still sits in front of the auditor explaining it. The AI is not on the on-call rota and is not on the compliance report (as yet). As long as humans are answerable for what the software does, an internal fork is a permanent commitment, not an afternoon's work and buying a supported version stays a rational way to move that commitment onto someone else.
That doesn't undo the erosion. It slows it, and it means the fence that survives is the one made of ongoing responsibility rather than of code.
Distribution is moving, and it moves in favour of open source
While one argument for being open weakens, another one strengthens.
A growing share of tool discovery and adoption no longer happens through search and a landing page. It happens inside a coding agent. Someone describes what they're building, and the model proposes a stack and writes the integration. If your source, your docs, and your API surface are public, models can recommend you and write code against you that actually compiles. If you're closed, you are largely invisible to that path and you get whatever the model remembers from your marketing site.
This makes agents a user class you have to design for, on par with humans. Concretely, it means quickstart guides for agents, error messages that describe the fix rather than the symptom, documentation structured for retrieval rather than for a linear read, permissive licensing on the parts you want vendored, because an agent will paste your quickstart into someone's repo either way.
I don't think this offsets the pressure on open core. But it does mean the answer isn't to close up. It's to change where the line sits.
The obvious move is a license change. I don't think it works here.
The industry's standard response to this kind of pressure has been to change the license: BSL, SSPL, and similar source-available terms, sometimes with a delayed conversion back to an open license.
It has a real advantage over what I'm about to propose: one codebase. No second build to maintain, no feature drift, no separate test matrix. That is not a small thing, and any alternative has to beat it on something else.
But it doesn't address the problem I've described. These licenses were designed to stop cloud providers from reselling the project as a service. They generally permit an end user's internal production use. So a license change does nothing about an enterprise using an agent to build its own enterprise tier as that was never the thing the license restricted.
What it does do is cost you the first pillar. Plenty of enterprises have blanket procurement rules against source-available terms. You lose foundation and distro packaging, you lose some of the default trust, and the pattern after a license change is well established: a fork appears, backed by the parties who dislike the new terms, and now you're competing with your own project's history.
So: it costs you what open source was buying you, and it doesn't defend against the thing that's actually eroding.
Where I'd draw the line instead
The split I'd make is between running the software and running a fleet of it.
The open project is one complete, production-grade deployment. Every capability the software has, it has in the open edition, at full strength. No in-memory queue standing in for a distributed one, no artificial ceilings. That matters beyond principle: if the open edition is a weakened build, then nothing a prospect validates locally predicts production, and in data infrastructure the interesting failures are precisely the ones a single-node dev build can't produce. A crippled edition doesn't earn trust. A company should still be able to take the open project, run it in production, and never pay me. That's the deal, and it has to be real.
The commercial product is a separate system that sits above that and handles how the system runs rather that what the system does. it operates deployments, coordinated upgrades and rollbacks across clusters, failover supervision, tenancy and quota management, policy enforcement, cost controls, observability across the whole cluster rather than a single instance. It's closed and commercially licensed, and the customer runs it inside their own infrastructure. Self-hosting is preserved end to end, which is the thing the enterprise buyer actually required.
I'd rather state the obvious objection than have it stated for me: isn't a closed control plane just feature gating with better vocabulary? The difference is what happens to the customer who declines to buy. Under feature gating, they get a deliberately incomplete product and are supposed to feel the gap. Here they get the whole thing and it works — what they don't get is the layer that only becomes relevant once they're running many of these, across teams, over years. That layer isn't a piece I removed from the product. It's a different product, and it's one whose value comes from operational leverage rather than from a capability that can be regenerated.
Which is also why it holds up better against the pressure I described. An enterprise can generate an SSO integration in an afternoon. Building something that stays correct across partial failures, version skew, and rollback paths — and then owning that forever, per the previous section — is a different proposition. And unlike a license clause, this line is a product boundary rather than a legal one.
The costs are real. You're maintaining two systems with a stable contract between them, and that contract becomes a compatibility surface you can't casually break. The open engine has to stay good enough to be chosen on its own merits, or the community that makes any of this work goes elsewhere. And you'll get less credit for openness than you would have five years ago, because a lot of people will read "closed control plane" and stop there.
I don't know how this settles
I'm not confident in any of this as a prediction. The economics of building software are moving faster than the business models built on top of them, and most of what I've written here is a reading of a situation that could look different in a year, including the parts I'm most sure about.
What I'm reasonably confident of is the smaller claim: gating capabilities is a weaker strategy than it used to be, and gating operations is a stronger one. The rest is worth arguing about, and I'd rather argue about it in public than be quietly wrong.
Meanwhile I keep building. navflow is open source: https://github.com/glassflow/navflow
Top comments (0)