Everyone complaining about Microsoft buying GitHub needs to offer a better solution

Microsoft is buying GitHub for $7.5 billion dollars, and predictably, there’s a developer backlash.

GitHub, though notionally a for-profit company, has become an essential, integral part of the open-source community. GitHub offers free hosting for open-source projects and has risen to become the premiere service for collaborative, open-source development: the authoritative source repository for many of these projects, with GitHub’s own particular pull-request-based workflow becoming a de facto standard approach for taking code contributions.

The fear is that Microsoft is hostile to open source and will do something to GitHub (though exactly what isn’t clear) to undermine the open-source projects that depend on it. Comments here at Ars, as well as on Slashdot, Reddit and Hacker News, suggest not any specific concerns but a widespread lack of trust, at least among certain developers, of Microsoft’s behavior, motives, and future plans for the service.

These feelings may have been justified in the past but seem much less so today.

Microsoft today is a company with a wide range of high-profile open-source projects, hosted on GitHub. Among other things, there’s the Visual Studio Code developer-oriented text editor, there’s the .NET runtime, and there’s the Chakra JavaScript engine from the Edge browser. Even Microsoft’s new documentation system is backed by GitHub.

These projects are all hosted on GitHub, and by most accounts I’ve heard, Microsoft is doing open source in an effective, community-engaged way. Publishing source code is not the same as developing in the open; there are corporate open-source projects where all development is done privately, in-house, with few-to-no outside contributions accepted. The code is published periodically (often without the full commit history, so providing no way to see how the code was incrementally developed) with an open-source license attached. For the most part, Microsoft hasn’t used this model; instead, it uses the GitHub for authoritative repositories, with all development published to GitHub as it’s done. Microsoft welcomes outside contributions, uses GitHub’s issue tracking to publicly record bugs and feature requests, and the projects engage with their user and developer communities to prioritize new development. This is a corporation doing open source the right way.

That’s not to say that Microsoft has always been like this, and the company has expressed hostility to open source—in 2001, then-CEO Steve Ballmer said that “Linux is a cancer” because of the viral nature of its GPL license—and is often accused of trying to “Embrace, Extend, and Extinguish” platforms and standards that it doesn’t control, after the term was used in a 1995 company memo to describe its HTML strategy. I’m not aware of any examples in which Microsoft has actually engaged this strategy successfully—although both Microsoft and Netscape developed all manner of proprietary extensions to HTML, it was ultimately Netscape’s failure to respond to Internet Explorer 4, 5, and 6’s speed, relative stability, and superior (though still poor) standards compliance that won the browser war, not Microsoft’s extensions—but the term is still widely used by critics of the company as if it offered some explanatory power. It doesn’t.

The Microsoft of today is a company that understands and embraces open-source development, both in the strict technical sense of publishing source code and in the broader sense of community-driven, collaborative development. The movement appears to be genuine, and frankly, that’s not something that we should find altogether surprising: there’s a hell of a lot of programmers working at the company, and many of them are users or contributors of open-source software themselves. They get it; it was only a matter of time before the company did, too.

GitHub almost certainly needed buying

As a private company, we don’t know exactly what GitHub’s bank account looks like, but we can make some reasonable inferences. The company has had two rounds of venture capital funding, one for $100 million, a second for $250 million. Leaked financials from 2016 painted a picture of a company burning cash at a prodigious rate, with salary and benefits alone rivalling revenue. Even a more positive analysis of the numbers suggests that GitHub was on track to have burned through that $250 million by around the middle of this year.

GitHub is also said to have been looking for a new CEO for about a year. Taking so long to find a new CEO doesn’t necessarily mean that there was a problem: perhaps a strong candidate fell through at the last minute causing the search to be restarted or something. GitHub’s CEO search doesn’t necessarily mean that the company’s problem is entirely financial—for example, there may be lingering fallout from the sexism and harassment claims from 2014—but the search suggests that the company is struggling to find someone willing, able, and confident who can tackle these problems, and money issues have to rank among the concerns of the CEO of an unprofitable company.

If money problems were indeed looming, GitHub had only a few solid options. Its backers could, of course, have decided to cut their losses and let the company fold. The effect of this on the open-source world would be devastating, and it’s hard to imagine that any prospective buyer could ever do more harm than this would cause. If the desire was to keep the company as a going concern, that meant raising more money. That presents three options: another round of VC funding, an IPO, and a sale.

Both an IPO and another round of venture capital cash would share a similar problem: any putative investors will look at the books, and if the books are an endless sea of red ink with no profitability in sight, those investors might be scared off. Existing backers with doubts about the business might have wanted out, pushing things toward an IPO or sale rather than another funding round. IPOs take time, and that may have been a luxury GitHub didn’t have.

GitHub makes its money from enterprise customers, with both a service for private cloud-hosted repositories and an on-premises version of the GitHub software stack. To turn a profit, the company needs more enterprise customers, and it needs to acquire them at lower cost.

In contrast to a funding round or an IPO, a sale to another company changes the parameters somewhat: it can make the path to profitability that much shorter. A cash infusion doesn’t offer any direct access to these enterprise customers that GitHub needs. Selling to, say, Microsoft, or Amazon, or Google, would open up access to those companies’ existing reach into enterprise markets. GitHub would no longer be solely responsible for building its sales channels: it could take advantage of ones that its new owner already has. This greater reach can boost revenue much faster than a mere lump of cash ever could.

Being bought also opens the door to certain synergies, which is to say, job losses; while we wouldn’t expect any immediate changes, it wouldn’t be tremendously surprising to see HR, sales, and marketing get the axe sooner or later as they get subsumed into Microsoft. As with enterprise sales channels, this is something that merely taking cash can’t do.

And if not Microsoft, then who?

There’s a handful of reasonable candidates with pockets deep enough to buy GitHub. Aside from Microsoft, companies such as Google, Amazon, Apple, Facebook, IBM, and Oracle all likely offer the right combination of “technology” and “money” to handle such a purchase.

It’s hard to imagine anyone cheering for an IBM or Oracle purchase. Oracle’s lawsuit with Google over the use of Java in Android—along with the pricing of its database and the way it effectively killed off open-source Solaris development—make it perhaps one of the most widely hated, least-trusted companies in technology, especially when it comes to open source. IBM’s engagement with open source appears to be negligible, and the company is generally perceived to be in decline. It’ll lumber on for many years yet, selling new mainframes to existing mainframe customers, and its research into AI and quantum computing might one day pay off. But, right now, GitHub would be very out of place.

Facebook doesn’t offer the enterprise reach that would boost GitHub’s profitability, and it uses Git competitor Mercurial internally. While Facebook does invest in developer tooling (for example, there are open-source C++ libraries developed in Facebook, and Facebook has contributed to development of the Clang/LLVM compiler), it isn’t in the business of selling tools and services to developers. There are also outstanding trust issues.

Apple offers stronger enterprise reach, though it is still lacking. But as a company, Apple has shown vanishingly little interest in developing the kind of platform-neutral, language-neutral service that GitHub offers, and it has historically invested little in developer tooling. Apple’s open-source engagement is mixed; some of its open-source efforts (such as the WebKit rendering engine) are run in an open way, but others are delivered only as periodic code dumps, with all development handled in house.

Three suitors

Amazon, Google, and Microsoft, in contrast, all have strong enterprise reach, and they all sell platforms and services to the developer community. This sets them apart as plausible homes for GitHub. All three companies have overlap with GitHub. Amazon and Google both already offer hosted Git repositories (AWS CodeCommit and Google Cloud Source Repositories, respectively). Microsoft has Visual Studio Team Services (VSTS) which, among other things, offers hosted Git repositories. Microsoft’s overlap is perhaps the most considerable, because VSTS also has issue tracking and other capabilities as an integrated feature. And Microsoft’s understanding of the developer tools market is perhaps the greatest of the three: the company has been selling developer tools for its entire existence, creating software for this audience long before Google or Amazon even existed.

All three companies can build on GitHub in useful ways, too, such as automating deployment to their respective cloud platforms and integration with their build and testing systems. Microsoft has even performed one such integration already: at Build this year, the company announced that GitHub repositories could be connected to its App Center mobile testing service to perform automated testing each time new code is committed. Microsoft’s developer story is perhaps the more complete here—Visual Studio is a highly respected development environment, and it too has built-in support for GitHub. But any of these companies could make a solid case for buying GitHub.

Amazon’s reputation in the open-source world is very poor. Though the company’s cloud services are market leaders and well respected, the company seems to have made a point of not engaging with the open-source world. This doesn’t mean that an Amazon purchase would necessarily undermine GitHub’s importance to open source (and just as with Microsoft and Google, many Amazon engineers are likely GitHub users themselves, so even if management interest is lacking, there’s grass roots support for GitHub). But it certainly doesn’t make such a coupling a natural home for a service that has become so important to the open-source world.

Google’s track record in open source is mixed. Some projects, such as the Chromium browser, are developed in the open; others, such as Android, are not. The company has published many libraries and development frameworks as open source. Google and Microsoft both clearly understand the demands that open-source projects face: both engage actively with open-source communities and, consequently, both are reasonable candidates as GitHub’s owner.

Best fit

But Microsoft’s product fit is arguably the more natural. Google’s internal version-control system is a proprietary, in-house system called Piper. It is very scalable and has many interesting features, and nobody but Google can use them. Microsoft, in contrast, is migrating much of its development to Git. The company has had to modify Git to handle the scale it needs, but it is working with the Git developers to get these modifications accepted into the main Git codebase, with the intent being that, eventually, stock-standard Git will do everything the company requires. Microsoft and GitHub have also collaborated to bring support for these extensions to GitHub and non-Windows platforms.