Skip navigation
Github acquisition.jpg Getty Images

Microsoft’s GitHub Acquisition Changed Windows Development Forever

Microsoft’s GitHub acquisition has caused Windows devs to “go native” by learning to love open source ways of thinking and doing.

This summer marked two years since Microsoft, the company whose former CEO once declared Linux a cancer, acquired GitHub, one of the most important platforms for open source software development. At the time, more than a few proponents of open source viewed the deal warily, worrying that it was the latest manifestation of Microsoft’s plot to embrace, extend and extinguish open source--or, at the least, that Microsoft aimed to monopolize and corporatize the thriving community of independent projects hosted on GitHub. Two years on, though, the worst fears about Microsoft using GitHub to get in the way of the open source developers seem not to have played out. I’d argue that Microsoft’s GitHub acquisition has had the opposite effect: It has helped bring closed-source, Windows-oriented developers into the open source cultural fold.

In other words, the GitHub acquisition has caused Windows devs to “go native” by learning to love the open source ways of thinking and doing that gave birth to GitHub in the first place.

Windows vs. Linux Developer Culture

To understand the impact of Microsoft’s GitHub acquisition on Windows developers, you first have to recognize the cultural divide that has traditionally separated Windows developer culture from its Linux-oriented counterpart. (To be clear, I’m talking here not just about developers who write code for Windows operating systems or the Linux kernel specifically, but also those who write end user applications for the broader Windows and Linux ecosystems.)

That divide plays out along several fault lines:

  • Code openness: There are certainly closed-source applications for Linux, and there are open source apps for Windows. By and large, however, most Linux development is open source, and most Windows development is closed. By extension, Linux devs assume the code they write will be available to the world at large, while Windows devs write as if only people inside their organization will ever see it.
  • Bug management: Relatedly, if you write an open source app for Linux, it’s easy to adopt the “many eyeballs make all bugs shallow mantra” and rely on your users to help you find and fix bugs. If you develop for the Windows universe, however, you face greater pressure to find and fix bugs yourself--ideally before they reach end-users.
  • Pace of development: Linux developers tend to like to release new versions of their applications or platforms early and often. That’s why Ubuntu has two new releases each year, for example. In contrast, major updates to Windows applications are usually fewer and further between. Windows users wait years between new Windows versions.
  • Integrated toolsets: Linux developers are accustomed to constructing their toolsets by picking and choosing from a variety of different options. You can combine an IDE and CI server of your choice with an SCM tool of your choice, for example. If you program for Windows, you’re more likely to use a platform that integrates everything you need into a single package.
  • CLI vs. GUI: Linux devs tend to be at home on the CLI, while Windows programmers rely more heavily on tools with graphical interfaces.
  • Integration with the cloud: A majority of the tooling and platforms for the cloud, like Kubernetes and OpenStack, integrate natively with Linux. Therefore, writing and deploying apps in the cloud may feel a little more natural for Linux devs than it does for those in the Windows ecosystem.

Admittedly, these are all sweeping generalizations, and I’m stereotyping Linux and Windows devs more than a little. (It’s worth noting, too, that there are plenty of programmers out there who code competently for both Linux and Windows.) But I do think that differences like these in how Linux and Windows developers think and operate contribute to a notable cultural divide between the two groups.

If you’re someone who has spent 20 years writing code for Windows, you’ll likely feel out of sorts if you try to jump into the world of Linux software development, and vice versa. That’s not just because the development tools are different; it’s because the entire underlying culture is different.

Through GitHub, Windows Devs Learn to Think Like Linux Devs

At least, that’s the way things have traditionally been. They’re now changing thanks to the GitHub acquisition, which has pushed Windows developers to start thinking more like their Linux-oriented counterparts.

That’s due largely to the fact that GitHub is, at its technical core, a platform based on paradigms that originated in the Linux world. After all, Git, the source-code management tool for which GitHub is basically a Web frontend, was itself written by Linus Torvalds.

As such, Git and GitHub force developers of all backgrounds to think and work like Linux devs. Git is a CLI tool, and even though GitHub provides a Web interface for performing a lot of common Git-related tasks, it’s more or less designed with the assumption that developers also know how to work from the command line when necessary.

GitHub encourages coders to make their code open. Although you can keep code in a private GitHub repository if you like, being able to share code publicly and collaborate with others via an open forum is part and parcel of what GitHub is all about. You miss out on some of the core value of GitHub if you don’t let anyone see or share your code.

GitHub works with a variety of other tools. It doesn’t force developers to commit to any particular platform or toolset, or try to be an all-in-one development platform.

GitHub’s revision-tracking features make it ideal for projects that aim to release code rapidly, even if it means taking some risks. It also makes it easy to include end users in the bug management process by having them report issues through GitHub.

In short, if you use GitHub, you will end up working in the same cultural vein as Linux developers have for decades. It might feel a little strange at first if you come from a Windows background.

Microsoft’s Embrace of Open Source Culture

By acquiring GitHub, then, Microsoft validated and legitimated open source culture among Windows developers. Obviously, the acquisition doesn’t mean that Windows developers now have to work through GitHub, but it is a major sign to them that Microsoft sees Linux developers’ way of doing things as a good way of doing things.

I would draw a different conclusion on this topic if Microsoft had used the GitHub acquisition to kill off the open cultural motifs inherent in GitHub, as some feared it would. But it hasn’t. If anything, GitHub has only become more open under Microsoft’s direction. Recently, GitHub committed to making even its own internal development roadmap open. That’s a step that is in line with the approach taken by most major open source projects, but very unusual for a closed-source platform.

If you have followed Microsoft’s evolution over the past seven or eight years, you know that there’s more to this story than just GitHub. The company has embraced open source in lots of other ways, from ending the anti-open source patent wars, to bringing native Linux tooling to Windows, to joining the Linux Foundation. It’s not as if Microsoft’s support for GitHub’s Linux-oriented workflows came out of the blue.

Unlike the GitHub acquisition, however, most of Microsoft’s other pro-open source moves were arguably more about extending Microsoft’s brand image than baking open source ideas into its core business model. In contrast, Microsoft’s decision to acquire GitHub, and its subsequent continuation of support for open source cultural paradigms within the platform, places a major pillar of open source culture at the center of Microsoft’s business. The move will prove to have profound, long-lasting impacts on the way developers in the Windows ecosystem think and work.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.