Lean Software ■ who profits, who pays
The call came because a machine had died, which is the ordinary way these things begin. What made it less ordinary was what had been running on it: a database application a teenager had assembled in a school computer course, forms dragged onto a screen, buttons wired up, the whole thing finished in an afternoon. The grandfather had been enormously proud, and he was right to be. The boy had built something that worked.
That was around the turn of the century. By the time I was called, the file held every customer the company had, and the only software that could read all of it was the application the boy had made. The original computer had gone west, and the operating system underneath would not install on anything you could buy. So we virtualised it, ran the old system on a Linux host, and throttled the processor, because the code had timing loops calibrated against hardware that no longer existed and ran itself into a wall when given a modern chip.
Nobody in that story did anything foolish. That is the part worth sitting with. The boy did what he had been taught. The grandfather trusted the person in front of him, which is what people do. And nobody at any point asked the one question that would have mattered, because nobody had ever told them the question existed.
The question is this: if we ever want to leave, what comes with us?
It sounds obvious written down. It is almost never asked at the moment of purchase, and there is a decent reason for that. At the moment of purchase you are thinking about arriving, not leaving. The demonstration shows the software doing the thing you want. Nobody demonstrates the export, because an export is not a feature anybody has ever been excited by, and because the honest answer is often that it exists in a reduced form which loses the fields you care about most.
What binds you is rarely a contract. It is a file format only one program fully understands, a query language nobody else speaks, a schema that lives in the application rather than in the data. Twenty-five years ago that was a database file on a network share. The mechanism has not changed at all. Only the packaging has.
Which brings us to the interesting part, because a great many people believed they had solved this by choosing open source, and the last three years have been an education.
What a narrow door looks like
In March 2024 Redis changed its licence. A fork appeared almost immediately and became Valkey, and here is what matters about it: Valkey forked from Redis 7.2.4 and kept the wire protocol identical, RESP2 and RESP3 unchanged. Existing clients connected without a line of code being altered. RDB and AOF files from Redis 7.2 loaded natively. For an operations team the migration was an endpoint change and an afternoon of nerves.
The same year, OpenTofu did the equivalent job for Terraform. Same state file format, so state sitting in S3 or Azure Blob works for either tool. Same provider plugin protocol, so one provider binary serves both. Teams pointed the new binary at the old state and carried on. It is now past version 1.8, has been downloaded something on the order of ten million times, and runs in production at Fidelity, Boeing, Capital One and AMD.
Neither of those escapes happened because the licence permitted it. Licences permit forks all the time and most forks die quietly. Those two worked because the interface between the tool and everything around it was narrow, stable and written down: a wire protocol, a file format, a plugin contract. When the interface is that narrow, the tool underneath is genuinely replaceable, and the fork is an inconvenience rather than a migration project.
There is a sting in the tail, and it belongs here rather than in a footnote. That compatibility is a state, not a possession. Redis 7.4 and 8 have moved on, and a straight file-level copy into Valkey no longer works; you need a logical migration, replicating from a compatible version or reading the keys over the wire and writing them out again, which is a proper faff on a live system. The door was open. Doors do not stay open by themselves.
The door that was narrowed
Then there is the other case, and it is the instructive one.
When Elasticsearch changed its licence in 2021, AWS forked the last open version into OpenSearch. Same code, same APIs, same everything, and on paper the same easy exit as the two above. Except that from version 7.13 onwards, Elastic's own client libraries carry a check that inspects what they are talking to and refuses to proceed if the answer is not an Elastic cluster. The Beats agents from 7.13 do not support OpenSearch at all.
The workaround OpenSearch shipped is the detail I would put on a slide if I ever had to explain vendor lock-in to a room of executives in ninety seconds. There is a cluster setting, compatibility.override_main_response_version, which makes the cluster report itself as version 7.10.2 rather than what it actually is. The recommended client versions for OpenSearch are pinned at 7.13.4, 7.13.3, 7.13.0 depending on the language, because after that the door closes.
Grant Elastic its reasons, because they were real. A cloud provider had taken the work and sold it as a managed service without contributing, and being cross about that is not a strategy. A client check can also be read as ordinary engineering caution: if you ship a library, you would rather not be blamed for what it does against a server you have never tested. Both of those are defensible. The effect is still that a piece of software now has to misreport its own version number in order to be spoken to, which is a fine example of a technical decision doing two things at once.
The thing that never had a door
Now hold that against something dull.
The configuration of a FreeBSD system lives in a file of shell variable assignments. Not a format with a parser, not a schema owned by a product: assignments, in text, which every tool on the machine already reads. The argument you hand a command by hand is character for character the argument that goes in the file. Nothing translates anything.
Count what survives of it and the number is faintly absurd. Of the 406 configuration variables shipped in 2012, 340 still work today, fourteen years on. Eighty-four per cent. The sixty-six that went are not breakages: they are ATM networking, Novell IPX, binary compatibility with commercial Unixes that have themselves since departed. The interface held its shape while the world it pointed at moved on.
There is no export from that arrangement because nothing was ever shut in. There is no fork, because there is nothing to fork away from. Somebody who learned to read those files in 2012 can read yours this afternoon, and a diff between two machines is a complete answer to how they differ.
Nobody needs to take up FreeBSD on the strength of that. The point is what a narrow interface buys, and what it costs: dull to look at, and impossible to sell.
Who pays, and when
Here is the part that separates this from a licensing row, and it is a matter of timing.
Nobody pays on the day of the decision. The company with the database file paid fifteen years later, on the morning a power supply failed. The teams running Terraform paid in August 2023, four years after choosing a tool that carried the Mozilla Public License and doing nothing wrong whatsoever.
IBM completed its acquisition of HashiCorp in February 2025, and on 11 March 2026 the licensor named in the file changed to International Business Machines Corporation. The people affected made a sound decision in 2019 and woke up seven years later to find that the language their infrastructure is written in belongs to a company they never chose.
That gap between decision and invoice is exactly why the question does not get asked. Whoever signs is not the person who takes the call, and by the time the call comes the person who signed has been promoted twice.
The point
The grandson grew up. He has a lanyard now, and trainers, and a deck of fourteen colours, and he is genuinely good at the presenting bit. Across the table sits somebody with a budget and no way of telling a durable interface from a beautiful one, judging on the only criterion anybody ever gave them, which is whether the person in front of them seems to know what they are talking about.
Nothing about that is stupid on either side. It is just that in twenty-five years, with all the frameworks and the certifications and the conference tracks, we never got round to teaching the one question.
Ask a vendor how their software goes in and you will get a demonstration and a smile. Ask how it comes out, and watch what happens to the room.