If one considers how desperately Microsoft tries to squeeze additional revenue from Windows (forced cloud account, ads, browser war 2.0) one has to wonder at what point they'll simply shut down OS (i.e., kernel and plumbing-level user-space tools) development completely.
I mean yes, it has been a proud piece of Microsoft but the OG NT kernel team probably left by now and from a management perspective it doesn't offer any revenue to develop an OS kernel.
Otoh, how big is their OS engineering team? Drivers are usually developed elsewhere. So maybe 100 folks or so? With a relatively low quota of non-devs, I assume? So Microsoft would potentially save what, tens of millions of dollars per year? Maybe they just continue this as some kind of tradition department.
> the Windows team is about 4,000 engineers and the engineering system produces 1,760 daily “lab builds” across 440 branches in addition to thousands of pull request validation builds
Ah right, the gp comment was specifically about the kernel, not the whole OS, sorry.
Regarding the kernel, I think it's not really possible for Microsoft to port Windows to the Linux kernel without breaking its backward-compatibility policy. Or maybe it would need something like WSL but reversed? But anyway I'm not sure it would make much sense.
That said, I didn't even touch a Windows system for maybe more than 10 years now…
Microsoft notoriously has major issues implementing new features or fixing bugs due to their commitment to backwards compatibility.
E.g. I've been told personally by Microsoft developers in the know that certain oddities or performance differences between POSIX and Windows come down to a handful of obscure but tricky test regression failures, and nobody could justify the time spent on bridging the gap. This was in the context of improving Git performance on Windows.
So even if Microsoft made the management decision tomorrow to ditch NT and ship Windows as a Linux distro, it's unclear how they could square that with backwards compatibility in a way that would result in overall cost savings for the foreseeable future.
The weight of that single word "tricky" in tricky test regression failures is very high!
I can't imagine the obscure craziness you'll be encountering when working on a codebase that's easily over 25 years old, supporting billions and billions of devices.
Yes, although having never been at Microsoft (and thus just speculating) I wouldn't underestimate the managerial effect of siloing either.
There are many tricky problems in major companies that are actually relatively easy with say a month of developer time, but any single team affected by it can't justify that over a workaround that takes a week to implement.
Then nobody adds up cost of 10 different teams needing to each repeat that twice.
Did you miss the 72% market share of Windows on desktop machines? That is still a massive market, and if nothing else, pulls consumers into the rest of the MS ecosystem.
So I doubt MS is abandoning OS development any time soon.
I don't feel like MS ecosystem is that attractive to consumers. In enterprise for sure, everyone uses Teams, Outlook and MS Office, and Azure is popular for hosting. But in most people's personal lives it's smartphones that are most utilized, which naturally draws people to Google's and Apple's ecosystems.
Only reasons I even bother to install Windows are gaming and MS Office provided by my university.
I mean yes, it has been a proud piece of Microsoft but the OG NT kernel team probably left by now and from a management perspective it doesn't offer any revenue to develop an OS kernel.
Otoh, how big is their OS engineering team? Drivers are usually developed elsewhere. So maybe 100 folks or so? With a relatively low quota of non-devs, I assume? So Microsoft would potentially save what, tens of millions of dollars per year? Maybe they just continue this as some kind of tradition department.