What could derail Microsoft’s integration of GitHub

Share: Print

Microsoft’s intended acquisition of GitHub, which the tech titan announced yesterday, may change the shape of developer workflows for years to come. The deal, worth $7.5 billion, is among Microsoft’s largest acquisitions and presents a strategic opportunity for both firms.

It’s a move that makes perfect sense from the standpoint of Microsoft’s business. GitHub has become a key part of the modern software development workflow, pioneering the use of the Git source control tool for both open source and commercial projects. The site has become developers’ de facto resume, allowing them to work with open source and show off their personal projects.

GitHub also offers private source code management tools, so enterprises can keep a handle on their code in the same way public projects on the site do. That fits in well with Microsoft’s focus on supporting the software development efforts of larger organizations. In other words, it’s a lynchpin of modern developers’ workflows at work and at home. In that context, it’s easy to see why Microsoft would want to acquire the company.

However, an acquisition of this magnitude carries significant risks for Microsoft. Here are the biggest potential issues it and the broader developer community face in the time ahead.

GitHub’s community could abandon it

Because GitHub’s value is tied in part to how many developers use it regularly for personal and open source projects, a developer exodus from the service would drastically reduce its value to Microsoft. GitHub’s support for enterprise development workflows is good, but likely isn’t worth the company’s full purchase price. That’s why Microsoft must carefully manage its interactions with the developer community.

Some open source projects are already moving to source control providers like GitLab (which reported a massive spike in migrations over the weekend when reports of the acquisition first surfaced), and other projects will likely move in the coming months as maintainers opt to migrate away from Microsoft. At this point, the reasons behind the migration seem largely philosophical, rooted in Microsoft’s historical opposition to open source as well as its continued patent licensing campaigns  against Android hardware manufacturers.

It’s worth noting that Microsoft’s stance toward open source software has changed in the years since then-CEO Steve Ballmer called Linux a “cancer.” The company holds memberships with several organizations dedicated to promoting and advancing open source, including the Linux Foundation, Cloud Native Computing Foundation, Cloud Foundry Foundation and Apache Software Foundation.

Microsoft is the largest organizational contributor to projects on GitHub and hosts a wide variety of open source code repositories on the site. Several key members of the Azure team are high-profile contributors to and maintainers of open source projects, including Kubernetes cofounder Brendan Burns, who’s now a distinguished engineer at Microsoft. At this point, the tech titan seems committed, from CEO Satya Nadella on down, to participating in and promoting the open source ecosystem.

But even with its apparent commitment to open source, it’s possible for Microsoft to commit an error that would run afoul of a larger swath of the GitHub community, driving them to another site. Because the core Git version control software is open source, it’s easier for users and projects to move away from GitHub than a site like LinkedIn, which doesn’t have significant competition in many markets. 

That said, there are strong network effects in play that help retain users and keep them engaged with GitHub. The company also has built out advanced features on top of Git that other companies haven’t yet replicated or don’t offer in the same way, and those could keep people around as well.

Microsoft could fail to integrate GitHub effectively

Even if the community sticks around, Microsoft still must contend with integrating GitHub’s capabilities. There’s a lot of potential in connecting Visual Studio to GitHub. For example, Microsoft could help developers using Visual Studio products to more easily integrate open source functionality from projects managed on GitHub into applications they’re developing.

Such a system could take the form of a quick start workflow that automatically sets people up with proof-of-concept projects that showcase a new framework, programming language or tool. Alternately, it could help automatically configure a system to work according to best practices. 

Microsoft must reckon with questions about how GitHub’s products fit into its own portfolio. For example: Visual Studio Team Services and GitHub both offer planning, source control and code review tools. Which offering should enterprises use? At this point, Microsoft is saying either or both will work. VSTS connects to GitHub for source control, so companies could use both products if their integration’s make sense for a given workflow.

Then there’s the matter of Atom, GitHub’s lightweight, extensible text editor that’s similar but not identical to Microsoft’s Visual Studio Code. Some developers prefer one over the other. Will Microsoft maintain two similar projects, just for the sake of keeping both sides happy? That appears to be a poor decision for the long term.

Issues with integration seems like the hurdle Microsoft is most likely to trip over. Historically, the company hasn’t been great at quickly streamlining products that have slightly different but overlapping capabilities. For example, the boundaries between SharePoint and OneDrive for Business are incredibly fuzzy, especially when it comes to groups that collaborate through Microsoft Teams. Theoretically, an organization can use both for slightly different file-sharing purposes, but are both needed?

Failing to effectively integrate acquisitions has come back to bite Microsoft in the past, whether it’s the company’s blockbuster purchase of Nokia’s smartphone business or its purchase of Skype, which managed to squander a massive lead in consumer videoconferencing.

Putting former Xamarin CEO Nat Friedman in charge of GitHub could help in that regard, since the acquisition of his company in 2016 and its incorporation into Microsoft offer what would seem to be the best roadmap for drawing parts of GitHub closer to Microsoft’s core.

In an introductory post following the announcement of the acquisition, Friedman said that Microsoft plans to keep GitHub independent “as a community, platform and business.” That’s good news for GitHub’s existing users, but it could mean that deeper integration with Microsoft services will suffer in exchange for GitHub’s independence.

Microsoft could integrate GitHub too deeply

It’s possible Microsoft could focus too much on connecting GitHub’s offerings with its own products to the detriment of integrations with other services. If that happens, it would become less useful to organizations that rely on applications like Slack (as opposed to Microsoft Teams), AWS (as opposed to Azure) and so on. Given the company’s public statements on the acquisition, Microsoft is aware of that risk.

But awareness and action are two different things. And though it could be a tough call to dedicate technical resources to maintaining features that directly compete with Microsoft products, it is something the company has increasingly done under Nadella’s leadership.

Given Microsoft’s commitment to GitHub’s independent operation, over-integration seems unlikely to be an issue, especially considering the company’s track record with its acquisition of LinkedIn. The enterprise social network appears to have significant independence under its new owners.

Acquisitions on this scale carry significant risks, but it seems like Microsoft is about as set up for success with GitHub as it possibly could be. The next question will be whether the company can follow through on its promises.

About the author

Blair Hanley Frank is a technology analyst covering cloud computing, application development modernization, AI, and the modern workplace.

Share: