For one, it's big. When I was working on part of the UIPlat team for Windows, my private enlistment just included build infra and maybe 5% of the sources and associated tools/tests and it still took up 60+ GB (100+ GB with binaries). I don't think you can just throw it on Github.
Two, compatibility. Even if you fix a bug, it usually needs to be versioned in some way to avoid breaking apps that rely on the bug. OS code, once shipped, becomes feature. Fixes require a fair amount of due diligence besides just identifying the problem and the correct fix. The historical context of how the issue was introduced and how it has migrated to other branches needs to be understood by grepping through the source history graph. Suites of build verification tests, regression tests, integration tests, and unit tests need to pass. Although Microsoft has extensive infrastructure for buddy builds and integration staging, external parties won't. So at best they could suggest a fix to Microsoft to complete the due diligence on. But usually suggesting a fix is easy and vetting it is the grueling part.
Three, private forks of Windows seem like maintenance and compatibility nightmares. Fragmentation would likely disrupt windows update's ability to apply patches and keep the system secure. Windows' ability to run across so many devices is kept sane by keeping a relatively small, consistent trusted computing base. Merging together forked Windows repos is a disaster. The XBOX team forked Windows 8 for a few months and made some tweaks to get XBOX One out the door, and then some folks had the nasty job of having to try and consolidate the codebases against moving targets. No one has enough context or time to perform these kinds of merges individually, nor would ever volunteer to, so they need to be massive coordinated efforts between teams.
Four, variants. You're not going to want to deal with all the possible permutations of Windows SKUs, processor architectures (ARM/X86/AMD64/IA64), build flavors, etc.
Five, it's a mess. There's plenty of archaic cruft, possible trade secrets, and lurking vulnerabilities. Open sourcing everything would be like opening Pandora's Box. It's too risky. Curating out some portion of this to open-source would be a massive undertaking and ongoing maintenance cost.
I think it makes more sense to take more mature modules, like .NET core or Roslyn, and open source them as separate entities. Modules are more reusable, and community-driven changes are easier to curate when they can be isolated. Windows has some components which it probably makes sense to open-source, but the entity as a whole is too unwieldy in its current form. .NET is designed more modularly.
TL;DR - Windows is an unwieldy behemoth and would be difficult to open source.
Two, compatibility. Even if you fix a bug, it usually needs to be versioned in some way to avoid breaking apps that rely on the bug. OS code, once shipped, becomes feature. Fixes require a fair amount of due diligence besides just identifying the problem and the correct fix. The historical context of how the issue was introduced and how it has migrated to other branches needs to be understood by grepping through the source history graph. Suites of build verification tests, regression tests, integration tests, and unit tests need to pass. Although Microsoft has extensive infrastructure for buddy builds and integration staging, external parties won't. So at best they could suggest a fix to Microsoft to complete the due diligence on. But usually suggesting a fix is easy and vetting it is the grueling part.
Three, private forks of Windows seem like maintenance and compatibility nightmares. Fragmentation would likely disrupt windows update's ability to apply patches and keep the system secure. Windows' ability to run across so many devices is kept sane by keeping a relatively small, consistent trusted computing base. Merging together forked Windows repos is a disaster. The XBOX team forked Windows 8 for a few months and made some tweaks to get XBOX One out the door, and then some folks had the nasty job of having to try and consolidate the codebases against moving targets. No one has enough context or time to perform these kinds of merges individually, nor would ever volunteer to, so they need to be massive coordinated efforts between teams.
Four, variants. You're not going to want to deal with all the possible permutations of Windows SKUs, processor architectures (ARM/X86/AMD64/IA64), build flavors, etc.
Five, it's a mess. There's plenty of archaic cruft, possible trade secrets, and lurking vulnerabilities. Open sourcing everything would be like opening Pandora's Box. It's too risky. Curating out some portion of this to open-source would be a massive undertaking and ongoing maintenance cost.
I think it makes more sense to take more mature modules, like .NET core or Roslyn, and open source them as separate entities. Modules are more reusable, and community-driven changes are easier to curate when they can be isolated. Windows has some components which it probably makes sense to open-source, but the entity as a whole is too unwieldy in its current form. .NET is designed more modularly.
TL;DR - Windows is an unwieldy behemoth and would be difficult to open source.