Microsoft now uses Git to develop Windows, along with its open source Git Virtual File System to help manage the ~300GB repository
Frederic Lardinois / TechCrunch :
Context & Ripple Effects
In 2017, Microsoft's Windows team was still living on a proprietary source-control system that choked on a repository of roughly 300GB — a scale problem shared by the largest monorepos in the industry. Rather than fork Git or abandon it, Microsoft built Git Virtual File System and open-sourced it, letting virtualized file access make a repo that size workable in the standard toolchain.
The move reads differently in hindsight: it was an early act in the developer-courtship campaign that led Microsoft to buy GitHub a year later and to keep shipping Windows-adjacent openness, from Linux-like Coreutils and WSL containers to open-sourcing the Windows Subsystem for Linux itself. The Git migration is the moment the world's largest closed-source codebase started running on the same infrastructure as its open-source rivals.
First-order effects
- Windows developers gain a mainstream workflow on Git instead of Microsoft-internal tooling, while the ~300GB monorepo becomes a public stress test that GVFS has to survive at enterprise scale.
Second-order effects
- A working GVFS removes Git's scale objection for other large-repo shops — Google-scale monorepo holdouts get a credible path to standard Git — and it hands GitHub a flagship proof point ahead of the acquisition that resolved its profitability question.
Third-order effects
- Microsoft's pattern of adopting outside infrastructure and then contributing tooling back (GVFS, later open-sourcing WSL) became the template for winning developers through compatibility rather than lock-in — the strategy under which GitHub scaled from roughly $200M–$300M ARR to $1B ARR and 90M+ active users.
The trend: Platform vendors are converting proprietary development stacks onto shared open-source infrastructure and competing on tooling quality instead of lock-in.