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

Salvatore Sanfilippo argues that AI will transform software distribution, turning repositories into templates and users into developers, but the author contends that vendors must still own the part beyond the template, citing Red Hat's guarantee and the failure of forks like KeyDB and Redict. The author notes that at Mergify, they used an LLM to generate a custom OpenTelemetry deserializer instead of upstreaming it, illustrating that AI enables regeneration of thin layers while the substrate remains, and concludes that the real template is the vendor's product decisions, not a repository.

Every Customer Gets the Same Software. That's Ending. SaaS shipped one product to everyone because maintaining a version per customer was impossible. That was never a principle. It was a budget, and the budget just changed. Salvatore Sanfilippo https://antirez.com/news/170 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 https://redis.io/ , 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. I described this loop in Open Source Is Getting Used to Death /blog/open-source-is-getting-used-to-death/ . I wrote it then as a diagnosis. This time I’m the mechanism. 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. This revises something I wrote five months ago. In the saaspocalypse post /blog/the-saaspocalypse-wont-kill-saas/ I listed maintenance among the costs AI hadn’t touched. I’d narrow that now. It hasn’t made maintenance easier in general. It has made carrying a divergence forward easier. Smaller claim, and the one this rests on. 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 /blog/the-saaspocalypse-wont-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. Related posts The AI Free Lunch Is Almost Over /blog/the-ai-free-lunch-is-almost-over/ Free dinners from Foodora ended. Free Claude Code dinners are next. Read more → /blog/the-ai-free-lunch-is-almost-over/ The SaaSpocalypse Won't Kill SaaS /blog/the-saaspocalypse-wont-kill-saas/ Wall Street wiped $300 billion from SaaS stocks and declared the model dead. They're right about the wrong thing. Read more → /blog/the-saaspocalypse-wont-kill-saas/