In 1998, a Microsoft executive called Linux a cancer.

No, and that’s worth being precise about. Microsoft’s Halloween Documents were a deliberate strategy — internal memos plotting how to spread fear and doubt about a competitor. Most AEC incumbents never did anything that calculated. The comparison isn’t about intent. It’s about the pattern: a company built a profitable model on lock-in, treated an outside shift as a threat to manage rather than a signal to read, and paid for it in years of catching up. The instinct is the same even when the moral weight isn’t.

What’s the actual “walled garden” in construction software — can you be specific?

Proprietary file formats that don’t export cleanly. Data that’s technically owned by the customer but structurally trapped, because pulling it out means losing the organization that made it useful in the first place. Integration marketplaces that charge rent on connections that should just work. Seat-based pricing that discourages the exact behavior — more people touching the data — that makes the platform more valuable to everyone using it. None of these are evil. They’re just revenue models built on friction, and friction has an expiration date.

How does the “bad guy who won’t say yes” story connect to the Microsoft argument?

It’s the same walled-garden problem showing up from the buyer’s side instead of the vendor’s. Microsoft’s lock-in was deliberate — a strategy imposed top-down. The client’s stack sprawl wasn’t imposed by anyone; it accreted. A free trial here, an eager estimator there, no one structuring an evaluation because no one was told there was one to structure. Fifteen years of that, across every department, and you get the same outcome as a deliberate lock-in strategy — a company that can’t easily leave its tools — without anyone ever deciding to build it that way. Different cause, same trap.

What does “AI removes the CRUD” actually mean?

Most point solutions in construction software exist to do four things to a particular flavor of data: create it, read it, update it, delete it. A submittals tool, a punch list tool, a scheduling tool — different UI, different vendor, same four verbs underneath. That layer used to require its own dedicated application because nothing else could reliably do structured data entry and retrieval against a plain-language request. A model that can read a spreadsheet or an inbox and act on it in plain language does the same four verbs without the dedicated app. The argument isn’t that AI makes construction software obsolete — plenty of it does real work beyond CRUD. It’s that a lot of what got sold as a category was actually just filing, and filing no longer needs its own login.

If people just want spreadsheets, email, and a smartphone, why did the industry end up with a twelve-tool stack at all?

Because each tool solved a real, narrow problem for the person who adopted it, and nobody was responsible for looking at the stack as a whole. The estimator wasn’t wrong to want better estimating software. The problem is that decision got made department by department, trial by trial, with no one asking whether the company needed a twelfth login or just needed the eleven tools it already had to talk to each other. The complexity is a byproduct of local optimization, not a plan. That’s exactly why it’s vulnerable now — nothing structural is holding it together except habit.

Why does AI make this moment different from past waves of construction tech change?

Because the workaround got easy. In past cycles, if a platform didn’t do what you needed, you either lived without it or built custom integrations that took a team of developers and six months. Now an owner or a project team can pull data out, run it through a model, and build the workflow themselves in an afternoon. That’s what happened with enterprise IT and Linux — it wasn’t that Linux got so much better, it’s that using it quietly, without vendor permission, became easy enough that people just did it. AI just did that to construction data, and it did it to twelve tools at once instead of one server.

Did Microsoft actually change its mind about open source, or was it just business?

Business, and that’s the point. Nadella didn’t have some come-to-Linux moment. The cloud made the old model unsustainable — enterprise customers were going to run Linux whether Microsoft liked it or not, and Azure needed to be the best place to run it or lose that business entirely. Reading that arc as a moral conversion misses the lesson. It was a company recognizing that what they were protecting had stopped being worth more than what it was costing them.

Isn’t this just another way of saying “get disrupted or die”?

Not quite, and it’s a meaningful difference. “Disrupt or die” implies some scrappy outsider is going to blow up the incumbent from below. What actually happened to Microsoft — and what’s more likely to happen in AEC — is quieter than that. It’s not a competitor beating you. It’s your own customers routing around you a tool at a time, the same way that client’s departments quietly adopted software nobody evaluated, until one day the workaround is the default and your platform is the thing they tolerate instead of the thing they need.

What should an incumbent actually do differently, concretely?

Start where Microsoft started: with the smallest, least threatening move that acknowledges the direction of travel. Their first act wasn’t “love Linux.” It was one code contribution to fix a virtualization driver, because enterprise customers needed it. For AEC software, that might look like making export actually work the way it’s supposed to, opening an API that isn’t gated behind an enterprise tier, or letting a customer’s own AI tools touch their own data without a fight. Small, honest moves toward openness, made early, are cheaper than the alternative made late.