If I were in charge of Windows product strategy I think I would create competing subdivisions that replicate the model of Linux distributions but on the NT kernel. Sworn to binary compatibility but inspired to try different monetization schemes.

Meanwhile my mind has taken a deeper dive into the rabbit hole fantasy of competing Windows distribution divisions. I'd expect it to seem like a total failure : the surface. E.g. with Steam users refusing to get lured into the "gamer Windows" (something with an X in the name), the "crippled version that is entirely ad-funded" (10, basically) drawing too much hate for the entire brand while still not being crippled enough to push people to paid options and the one you can get with the Office subscription being a little too incompatible for employee lockout reasons with the plethora of in-house essentials required to run at customers. But Microsoft could still come out stronger, having a well defined place for bad ideas to go to die. And who knows, one of the niche distributions might be essentially sysinternals with a kernel and a package manager.

For corporate and government, it was not free. And these are where the money is.

I once worked for a corp that didn't have subscription. The rationale was, that is was not important who was running which version at their computer, and the subscription was thus a cost on top of OEM license that didn't bring any value. Since the computers were refreshed every 4-5 years anyway, they always had a supported Windows version.

Problem is, most software doesn't exist in a vacuum; it is part of an ecosystem. Security updates that you might pay for are not enough, because the ecosystem is constantly changing around the program you bought.

I'm author of HashBackup. It uses remote object storage services so if there are incompatible changes made on the storage side, the software has to adapt. What if IP4 is no longer supported? Adapt. A library like Boto2 gets rewritten and the old version loses support. Adapt. Google Sites decides to force you to migrate to a new version that looks like shit. This just happened to me, and it's so bad I'm having to do a whole new documentation site.

Just keeping software working has become a big challenge because of ecosystem changes.

Stop changing things just to change them. But if you're actually changing for a good reason, consider the downstream effects of your changes.

I can take a bash script from 20, maybe 30 years ago, and know that it will still do what it's supposed to do, and all the standard commands it calls, like sed, awk, and grep will also do what they are supposed to do. Bits don't rot by themselves. Careless developers in the ecosystem make changes and don't consider backward compatibility, and we euphemistically call it "bit rot."

That's a bit unfair. The iPhone 13 just came out and one of the memes and jokes going around is that it looks the same as the previous phone and users are just buying the same thing again. Even tech people I know are joking about it.

So the UI people are always going to be busy because even people in the industry equate looks to changes. If the looks don't change they will all be scratching their heads confused why this is Windows 11 when it looks identical to 10.

There are even companies outside software business, that pay contractors per tickets, basically a budget is assigned and the contractor does as much tickets as they are capable of for the given budget.

Now the quality of the code is not for the faint of heart.