DEV Community: Ashish Bagri

Open core was a licensing strategy. It needs to become an architectural one

Ashish Bagri — Fri, 24 Jul 2026 13:07:02 +0000

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

Your AI agent isn't hallucinating- it's reading garbage context

Ashish Bagri — Mon, 20 Jul 2026 12:39:51 +0000

Your agent isn't hallucinating. It's reasoning correctly over the wrong inputs.

Here's a failure pattern every team running agents in production has hit:

An alert fires. The agent investigates: pulls metrics, checks recent deploys, scans logs, proposes a fix. The fix is confidently, articulately wrong. Instinct says blame the model (bad reasoning, needs a better prompt, maybe a bigger model).

Then someone reconstructs what the agent actually saw. The metrics query returned a 5-minute-old cached aggregate. The deploy list was fetched before the relevant deploy landed. The log window was truncated at 1,000 lines and the line that mattered was #1,014. Given those inputs, the agent's conclusion was reasonable. It just wasn't debugging the incident that happened.

It's garbage in, garbage out, with a twist that makes it worse for agents than for any previous software. A dashboard shows you the garbage. A human sees a stale chart and might notice the timestamp. An agent consumes the garbage silently and acts on it, with fluent reasoning layered on top. The output doesn't look like garbage; it looks like a confident, well-argued investigation. That confidence is what makes it dangerous.

Why is this surfacing now

For chatbots, context was mostly a retrieval problem over documents; mediocre retrieval meant a mediocre answer a human would shrug at. Three things changed with production agents:

Agents act. A stale metric doesn't produce an off paragraph; it restarts the wrong service or pages the wrong team at 3AM. The cost went from cosmetic to operational.
The input surface exploded. A production agent reads metrics, logs, deploy history, tickets, and chat from separate systems, each with its own latency, rate limits, caching, and clock. The "world" it reasons over is stitched together from partial snapshots, inside the model's reasoning loop, where nobody can inspect it.
Errors compound. A single wrong input gives a slightly wrong answer. A 20-step investigation where step 3's conclusion becomes step 4's premise turns a small input error into a confidently wrong remediation.

Teams see the failure, file it as a reasoning problem, and reach for a bigger model or a longer prompt. The failure was upstream of the model the whole time.

Five ways context goes bad

Stale: true when fetched, then the world moved. Caches and polling intervals manufacture staleness silently.
Partial: pagination limits, truncated log windows, retries that quietly gave up. The agent reasons over what arrived, not what didn't.
Unordered: events from six systems, six clocks, interleaved wrong. Causality inverts: the deploy looks like it followed the errors it caused.
Lossy: every transformation in the pipeline throws something away on purpose. Embeddings drop exact identifiers and word order. Summarization drops whatever seemed unimportant; the exact judgment the agent exists to make. Stack a few of these and the model ends up reading a paraphrase of a summary of a sample.
Unattributed: the agent can't tell where a fact came from or when it was captured. Two contradictory data points arrive with equal authority, and the model just picks one.

None of these are model problems. A better model reasons more elegantly over the same bad inputs and arrives at the same wrong answer with nicer prose.

"Just wait for bigger context windows"

Context windows are in the millions of tokens now. Why not pipe everything in raw and let the model sort it out? Three problems:

Long context degrades. The "lost in the middle" effect (Liu et al.) and the more general context rot (Chroma's study, tested across 18 models) both show accuracy dropping as input length grows. A million-token window isn't a million tokens of reliable attention.
Cost scales with tokens. Every token is paid for on every reasoning step. For an agent running hundreds of investigations a day, "send everything" is a bad unit-economics decision.
The window can't fix what never arrived. Freshness, completeness, ordering, and provenance are properties of the systems collecting the data. No model recovers a log line truncated upstream or un-stales a cached metric.

Context engineering is a systems discipline

"Context engineering" has displaced "prompt engineering" for a reason. Anthropic's own guidance treats context as an engineering problem, not a wording problem. But even that's often applied narrowly, just packing the window better. The real discipline looks more like data infrastructure than writing.

Good context is:

Complete over a defined window — "everything about service X in the last 30 minutes" is a guarantee, not a hope.
Fresh, with staleness measured, not accidental.
Ordered, on one clock, so causality survives.
Lossless where it counts. Structured and typed for cheap querying, but with original records preserved.
Attributed: traceable to a source and a moment.
Replayable: the property that matters most after something breaks. The postmortem question isn't "why did the model say that," it's "what did the model see." If context was assembled from live API calls, you can't answer that. Τhe caches have rotated and the APIs have moved on. Treating agent context as a durable, ordered record turns forensics from guesswork into a replay.

The takeaway

The industry has spent two years making agents better at thinking and almost no time making sure they're thinking about the right thing. The models are already good enough to be dangerous when fed garbage and fluent enough that the garbage stays invisible until the postmortem.

Next time an agent fails in production, run the cheap experiment before reaching for a bigger model: reconstruct exactly what it saw, and ask if you'd have done better with the same inputs. Usually the answer is no. What looks like a reasoning failure is usually a context failure, and context failures are fixable with engineering today.

I'm building NavFlow, open source and self-hosted, giving production agents one correlated read path across your systems — complete, fresh, ordered, lossless, and replayable — so the model's reasoning is the only variable left.