If Customers Can Maintain the Fork, What Are We Selling?

One customer conversation has stayed with me.

The customer was using our open-source product, but they had forked it. They were making the fixes they needed and cherry-picking changes from upstream into the version they wanted to maintain.

They liked the product enough to take ownership of their own version. That is a meaningful endorsement. It also raises an uncomfortable commercial question: what would make them pay us?

I have heard a less committed version of the same argument from prospects. They believe their existing team, with help from AI, can handle deployment and maintenance. Against that alternative, our commercial offering looks expensive.

A working fork and an estimate of future maintenance costs are different kinds of evidence. Neither establishes AI’s effect on the long-term cost of ownership. But these conversations make me less comfortable with a familiar assumption: eventually, running open source yourself becomes enough trouble that paying the vendor is the obvious choice.

What if that moment arrives much later? What if, for a substantial group of users, it never arrives?

Customers only need to maintain their differences

When we discuss whether AI can replace complex software, we often set an unnecessarily high bar. Could it rebuild a database? Could it reproduce years of engineering, compatibility work, and production experience?

For a customer maintaining a fork, the database already exists. They can start with a working product, change the parts they need, and selectively bring in upstream fixes. They do not need to reproduce the organization that built it.

The vendor develops a product for many workloads and environments. It has to manage compatibility, releases, and behavior beyond any one deployment. The customer may need one version to work for one relatively stable set of requirements. They can defer an upgrade, ignore features they do not use, and test against their own workload.

Download Excalidraw source ↗Click diagram to enlarge

Text version

Vendor maintaining the shared product

1. Many workloads: Support behavior beyond one customer deployment.
2. Many environments: Maintain compatibility across supported configurations.
3. An ongoing release path: Develop capabilities and fixes for the broader product.

Customer maintaining a fork

1. One deployment: Keep a version working for relatively stable requirements.
2. Selected patches: Maintain specific differences and incorporate chosen upstream changes.
3. Tests for their workload: Verify changes against the workload they operate.

AI may reduce work within the narrower scope. The customer still depends on upstream development.

That narrower scope has limits. Patches become entangled. A small fix can depend on a larger architectural change. A fork can drift far enough that a security update becomes difficult to incorporate. The work includes verifying changes and operating the system, not just producing code.

But we should not assume that every fork is a delayed disaster. The relevant question is what it costs to maintain the customer’s specific differences. If AI makes understanding code, adapting patches, and writing tests cheaper, that cost may fall without AI ever becoming capable of building the whole product.

Forking is not new. What may be changing is how many teams find it practical.

Saved time has to justify the price

A common sales argument compares a subscription with the cost of hiring engineers to operate the software. That can be reasonable when the customer would otherwise need to hire. It is less persuasive when the engineers are already there and will remain there after the purchase.

A managed service still needs people on the customer’s side to understand the data, integrate the system, investigate application behavior, and work with the provider. The relevant comparison may be the existing team running open source with AI assistance versus the same team using a commercial service with AI assistance.

Existing engineers are not free. Maintenance takes time away from other work, and a service may remove on-call burden or reduce the risk of an incident. Those benefits deserve to be counted. So does the work that remains after the purchase.

The sales case has to explain the difference. A few hours saved each week do not automatically justify pricing the service against an entire engineer. The value depends on how much work it removes, what the team can do with the recovered time, and whether it changes the cost or likelihood of failures.

If the subscription grows with compute or data volume while the perceived maintenance burden stays roughly constant, labor savings alone become a harder argument to sustain. The vendor needs to show what additional value grows with the bill.

Calling the customer shortsighted does not resolve that mismatch.

Control is part of the buying decision

A customer may actively prefer maintaining a fork. They choose the version, decide which fixes matter, and change behavior without waiting for a vendor’s roadmap.

A commercial offering might remove work while introducing constraints: a different upgrade cadence, unsupported customizations, or behavior the customer can no longer modify. The decision includes both the subscription price and the control the customer gives up. A discount addresses only the price.

This makes me wonder whether some open-source businesses package their commercial offerings around the wrong transition. We expect users to move from operating the software themselves to letting us operate it. Some may want to keep operating it while selectively buying capabilities from us.

Help validating a patch, diagnosing a difficult failure, or maintaining a particular release could be valuable on those terms. It could also produce much less revenue per customer than a full commercial platform.

Adoption and revenue can move apart

AI could make an open-source product easier to adopt. It could help users understand the documentation, integrate the product, investigate errors, and make changes that previously required specialist knowledge.

The same assistance could make it easier to remain self-managed. A project could gain users and become more useful while the original vendor finds it harder to convert those users into paying customers.

Download Excalidraw source ↗Click diagram to enlarge

Text version

Potential adoption effect

1. AI assistance: Help understanding and integrating the product.
2. Easier to start: Learn, integrate, and troubleshoot.
3. More potential users: Adoption may become practical for more teams.

Potential self-management effect

1. AI assistance: Help understanding code and adapting changes.
2. Easier to keep running: Patch, test, and maintain.
3. A stronger option to stay self-managed: Some users may have less reason to purchase the commercial offering.

These are hypotheses. Revenue still depends on conversion, spending, and retention.

That does not mean revenue must fall. A larger user base could outweigh a lower conversion rate. It means adoption alone would tell us less about the health of the business.

The customer maintaining a fork still benefits from upstream development. They have found a way to use much of that work without buying the commercial offering. That possibility is built into open source; AI may change how often it is practical.

This raises a funding problem beyond any one sale: who pays for the broader engineering work that all these users continue to depend on?

“They should pay because they benefit” describes a funding need. It does not give the customer a reason to buy.

A paying customer does not establish a moat

I can see several directions worth testing.

Better operating economics. A service that runs the same workload with fewer resources can be worth buying even when self-management requires little labor. The advantage has to hold against both self-hosting and competing providers. Being the original author does not guarantee it.

Expertise, validation, and support. Supported releases, tested backports, and help with difficult failures could let customers retain control while buying assistance where it matters. The challenge is making that repeatable. Supporting a bounded set of configurations is very different from taking responsibility for arbitrary customer forks. Revenue can grow while the engineering burden grows just as quickly.

A more complete workflow. Solving a broader business problem could create stronger reasons to buy than operating one component. It could also introduce more custom integration work, some of which AI may make easier for customers to do themselves.

Each direction could produce a business. None automatically produces a durable advantage. That requires a further answer: why can’t the customer, or another provider, deliver the same value on comparable terms?

Better testing, accumulated operational knowledge, efficient infrastructure, distribution, and trusted relationships may all help. Their value has to show up in something the customer experiences: lower costs, fewer failures, faster recovery, or work they no longer need to do.

There is also an outcome worth taking seriously: a useful open-source product might support a healthy, focused company at a smaller scale or lower margin than its founders imagined. That would be a different business outcome, not a failure of the software.

What I want to learn from these forks

I want to follow these customers beyond the initial deployment. How does maintenance change after several upgrades? What happens when a fix touches an unfamiliar part of the system? Does AI reduce the effort of verifying a change as much as it reduces the effort of producing one?

On the commercial side, I want to understand what customers are rejecting. The need for a supplier? The price or charging model? A bundle of capabilities they do not need? The requirement to give up control over something they already operate successfully?

Those answers imply different product decisions. They should not all end in the same discount negotiation.

For now, a customer maintaining their own fork is neither proof that open-source commercialization is broken nor reassurance that they will eventually come back and buy. They are a reminder that a useful product and a compelling paid offering are separate things.

The question I keep returning to is this:

If we assumed from the beginning that customers could easily run, modify, and maintain our open-source software, would we build the same commercial product we sell today?