Windows will almost certainly never be open source, but virtually all Microsoft Windows engineers are now using the open-source program Git to build Windows on.
Microsoft hasn’t just become an enthusiastic open-source user; the company is now using the Git version control system to build Windows itself. The once prime example of proprietary software development is now relying on open source to create its trademark operating system. Who would have thought it?
Actually, you might have if you’ve been paying close attention. Back in 2013, Microsoft announced its roadmap for adding support for Git to its Visual Studio development-tool suite and Team Foundation app-lifecycle-management technologies. Later that same year, Microsoft Technical Fellow and TFS chief Brian Harry announced Microsoft would be backing Git as its distributed source-code-control platform.
Not everyone in Microsoft liked this idea, but as Harry blogged at the time, « the more we looked at it, the more it looked like the right thing to do ».
As the years went by, Microsoft even made its own significant open-source contributions to Git. In 2017, Microsoft open-sourced Git Virtual File System (GVFS) , under the MIT License. GVFS enabled Microsoft’s product teams to scale the Git client to deal with its monstrously large source code repos.
Since then, Microsoft started porting all — and I mean all — the Windows code to Git and GVFS. The work is now largely done and Microsoft is enjoying the fruits of its open-source labor in creating the largest Git repo on the planet.
Harry wrote, « Over the past 3 months, we have largely completed the roll-out of Git/GVFS to the Windows team at Microsoft ». That was no small job. « The Windows code base is approximately 3.5M files and, when checked in to a Git repo, results in a repo of about 300GB. »
That’s just the files. « 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. All 3 of the dimensions (file count, repo size and activity) , independently, provide daunting scaling challenges and taken together they make it unbelievably challenging to create a great experience. »
Harry admitted this was a scary experience. « The first, and largest, jump happened on March 22nd when we rolled out to the Windows OneCore team of about 2,000 engineers. Those 2,000 engineers worked in Source Depot on Friday, went home for the weekend and came back Monday morning to a new experience based on Git. People on my team were holding their breath that whole weekend, praying we weren’t going be pummeled by a mob of angry engineers who showed up Monday unable to get any work done.
« Much to my surprise, quite honestly, it went very smoothly and engineers were productive from day one. »
It wasn’t all smooth sailing. « We discovered that first week that our UI for pull requests and merge conflict resolution simply didn’t scale to changes that large. We had to scramble to virtualize lists and incrementally fetch data so the UI didn’t just hang. We had it resolved within a couple of days and overall, sentiment that week was much better than we expected. »
Today, almost all Windows developers are working on Git. In the next few months, the last 500 programmers will move to Git.
They have every reason to make the move. According to Harry, « the scale the system is operating at is really amazing. Let’s look at some numbers. »
Microsoft has continued to tune GVFS for remote use. Harry explained, « The Windows Team Services account is located in an Azure data center on the west coast of the US… The 80th percentile for Clone for a Windows engineer is 127 seconds. Since a high percentage of our Windows engineers are in Redmond, that number is dominated by them.
« We ran a test from our North Carolina office (which is both further away and has a much lower bandwidth network) . A clone from North Carolina with no proxy server took almost 25 minutes. With a proxy configured and up to date, it took 70 seconds (faster than Redmond because the Redmond team doesn’t use a proxy and they have to go hundreds of miles over the internet to the Azure data center) . 70 seconds vs almost 25 minutes is an almost 95% improvement. »
Impressed? Microsoft will be happy if you used GVFS. After all, GVFS is an open-source project and you are welcome to try it out. All you need to do is download and install it, create a Visual Studio Team Services account with a Git repo in it, and you’re good to go. Other Git programs include Atlassian SourceTree and Git Tower.
Ironically, there’s not currently a Linux Git client that supports GVFS, but is internal Microsoft support for Linux and Mac support. Saeed Noursalehi, a Microsoft programmer manager, wrote on the GVFS bug list, « Yes we definitely want to support Mac and Linux, and we are looking for people with file systems expertise on those platforms. »
Linus Torvalds, Linux and Git’s creator, once said, « If Microsoft ever does applications for Linux it means I’ve won ». I think Microsoft using Git to create Windows counts as a win too.
Related Stories:
