Every Customer Gets the Same Software. That's Ending.

Salvatore Sanfilippo thinks AI changes how software gets distributed, not just how it gets written: repositories become templates rather than finished products, users become developers, projects carry several branches instead of one polished release.

He’s right about the mechanism. He’s pointing it at the wrong target.

Someone has to own the part past the edge

A template gets you most of the way. Someone still has to own the rest.

Buy from a vendor and the vendor owns everything past the edge of the template. They guarantee it still works after you’ve bent it into your shape. Red Hat guarantees their build, not your fork of it. Use a repo as a template and you own the extension forever, alone.

For a small library, fine. For Redis, not fine. And not because forking a database takes a giant: KeyDB was a couple of people, Redict essentially one, Salvatore carried Redis himself for years.

It takes something harder to buy than headcount. Somebody still there in five years because their livelihood depends on it.

Most companies who fork discover, eighteen months in, that they’ve accidentally hired a database team. So the template model doesn’t rescue open source.

It needs a vendor to work at all.

We already did this, and we didn’t give it back

A few weeks ago we needed to read OpenTelemetry data at Mergify. The Python deserializer used too much memory and had no streaming, which at our volumes was the difference between working and not. We described the constraints to an LLM and it wrote us one. Faster, streams, fits.

Did we upstream it? No.

Not out of bad citizenship. I’ve spent twenty years in open source. Upstreaming is work: generalize the fix, argue the API, write tests for cases you don’t have, wait for review, then maintain it. And the payoff has collapsed, because anyone who needs the same thing with different priorities generates their own in an afternoon instead of adopting ours.

But look at what we regenerated. A deserializer. Not the protocol, not Postgres, not the kernel. Nobody asks an LLM for a storage engine and then trusts it with their data.

There’s a floor, and our library sits on it. You regenerate the leaves, you keep the substrate. What dies isn’t open source. It’s the layer thin enough to be worth rewriting and boring enough that nobody misses the community around it.

The template that matters isn’t a repository

It’s the vendor’s own product. Salvatore’s templates are real, just not in a repository.

When you don’t want to hardcode a decision, you expose an option. But options are finite, and past a point they contradict each other. Eventually you decide. Those decisions are the product. They make it your software rather than someone else’s.

Every customer got the same decisions because maintaining a version per customer was impossible. The industry found seams instead. Salesforce gives you metadata, ServiceNow gives you your own instance, Shopify gives you themes, everyone else gives you feature flags. All of them work by putting your changes somewhere the vendor never has to merge.

That’s why “we don’t do custom” hardened into doctrine, complete with a moral vocabulary. Bespoke work was undisciplined, forks were technical debt, and the customer asking for their own build was the villain of the roadmap meeting.

It was never a principle. It was a budget.

SAP was doing this the whole time

Enterprise software already worked this way and we treated it as a cautionary tale. Two companies both “on SAP” share maybe 80% of the system and diverge completely after that, because their approval workflows are genuinely different and no configuration reconciles them.

We also know what it cost. ERP migrations take years because of that customization, and custom code remediation is the biggest variable in the schedule.

So, the bet: AI makes the migration cheap too. The same thing that writes the variant carries it forward, reconciles it against a new release, and tells you what broke.

If that holds, the customization penalty that made per-customer software ruinous evaporates. If it doesn’t, everything above describes a trap, and a lot of companies are about to rediscover why we stopped.

I think it holds. I’ve been wrong before.

We already do it to ourselves

At Mergify, every engineer has built their own software factory manager, the thing that drives agents through a task. Not one shared tool with options. Separate tools, all different, because the engineers disagree about how work should be organized and they’re not wrong to. Some drive everything from a CLI. Some want a web UI.

Nobody standardized them. Nobody even proposed it. The cost of having your own dropped below the cost of agreeing on someone else’s, and the argument that would have eaten a quarter in 2019 never happened.

The SAP story, one level down.

The end of the common UI

Plenty of people argue that agents don’t need interfaces, so the UI is dead. Different subject.

What ends is the common UI. Not the interface. The shared one.

You will still have a screen. It just won’t be my screen. Support gets interesting when “click the button in the top right” stops meaning anything. Documentation screenshots stop matching. Onboarding someone who used the product at their last job stops being an advantage.

We don’t do any of this at Mergify. I don’t think we’re ready, and I’m not sure the tooling is either. I still believe the saaspocalypse won’t kill SaaS. But this change is coming, and it arrives from the inside rather than as a competitor.

For thirty years, everyone running the same build was the entire point. It was also a constraint we couldn’t afford to break.

You’ll still be able to send me a screenshot of the product we both pay for. I just won’t recognize it.