Why companies move to Linux

In fifteen years of building analytics systems and machine learning models, across a decent number of employers and clients, I have deployed production code onto exactly zero Windows servers. Not out of preference — it simply never came up. Every database, every scheduler, every model serving endpoint, every container I have ever shipped ran on Linux, and nobody in any of those rooms ever proposed otherwise.

That is a strange thing to notice about your own career. On the desktop this argument has been running for thirty years and shows no sign of resolving. On the server it ended so quietly that most people outside the trade never learned there had been a contest.

Who moved, and roughly when

The names are worth saying because they undercut the assumption that this is a hobbyist position. The companies streaming video to your television, the ones running the search you used this morning, the ones holding your photographs — their infrastructure runs on Linux. So does the platform hosting most of the world's software development. So does every one of the fastest supercomputers on the planet, which is not a majority claim but a complete one.

Even Microsoft moved. Their own cloud runs an enormous quantity of Linux, they ship a Linux compatibility layer inside Windows for developers, and they contribute to the kernel. When the company with the most to lose from this outcome adopts it in its own infrastructure, the argument is not really an argument any more.

Why, in the order that actually mattered

The reason people usually give first — that it is free — is the weakest one, and I say that as somebody who cares about costs. Licence fees are real but they are small next to salaries. If price were the whole story the migration would have happened differently and earlier.

The first real reason is that a server is not a desk. It has no screen, nobody sits at it, and a graphical interface on it is pure overhead — memory and attack surface spent on a thing nobody will ever look at. A system designed to be operated by typing, remotely, by someone who is not in the building, is a better fit for the job. That is not an opinion about elegance; it is a description of the workload.

The second, and this is the one that decided it for my profession: repeatability. A server you configured by clicking is a server nobody can rebuild. When it dies — and it will — somebody has to remember what was done to it, in what order, at three in the morning. A server whose configuration is a text file is a server you can recreate from nothing, identically, a hundred times, automatically. The entire modern practice of running infrastructure rests on that property, and it requires a system where every setting is a file you can read, version and copy.

The third is uptime, and specifically the ability to fix things without stopping. A machine serving customers cannot reboot on a vendor's schedule. Being able to patch, adjust and replace parts of a running system — and, when necessary, to read the source to understand why something misbehaves — turns a class of outages into a class of inconveniences.

The part that is about power, not technology

There is a fourth reason, rarely stated out loud in vendor meetings, and it is the one I find most interesting.

A company that builds its core systems on a platform owned by another company has handed that company a permanent seat at its own strategy table. Prices can change. Terms can change. A product can be discontinued, or bundled into something you did not want, or made conditional on buying something else. None of this requires bad faith — it is simply what it means to depend on someone else's commercial decisions.

Building on a platform that nobody owns removes that seat. Your supplier can raise their prices and you can take the same software elsewhere, because the software was never theirs to withhold. That is the actual strategic argument, and it is why large organisations that could easily afford licences choose open infrastructure anyway. They are not economising. They are refusing to be negotiated with from a position of weakness.

What a five-person company takes from this

Not the technology. A small company does not need container orchestration or a configuration management system, and anybody trying to sell them one is solving their own problem rather than the client's.

What transfers is the reasoning. Those large organisations asked three questions before choosing: can we rebuild this from scratch if it dies, can we still run it if our supplier's terms change, and can we find out what it is doing when it misbehaves. Those questions scale down perfectly. A small business storing its documents somewhere should ask exactly the same three about that somewhere, and the answers are usually more revealing than any feature comparison.

And the honest counterweight, because this article would otherwise be a sermon. None of the above makes Linux the right choice for a reception desk running scheduling software that exists only for Windows. The server argument was won on the merits of server work, and it does not automatically transfer to every machine in the building. I run Linux on the desktops I prepare because I checked what those people actually use, not because the servers settled it.

Still, the coincidence is worth sitting with. The machines that must not fail, that are run by people paid to know better, that carry consequences when they are wrong — those machines converged on one answer decades ago. It is a strange kind of consensus, arrived at independently by organisations that agree on almost nothing else.