为什么微软是收购GitHub最好的选择

6月4日，微软公司正式宣布以75亿美元收购代码托管平台GitHub。如果一切顺利，该交易预计将于今年年底前完成。然而，消息一出，就有相当一部分开发人员对此表示不满。

如今，GitHub正在为各类开源项目提供免费托管服务，并已经成为开源开发协作领域的首选服务。除了作为各类项目的权威源代码库之外，GitHub自身独特的pull请求工作流程也在客观层面成为代码贡献领域的标准实践。

而对于此次收购，人们担心的点是微软曾对开源软件抱有“敌意”，并有可能会对GitHub采取某些措施（尽管具体还不清楚），从而给高度依赖该平台的开源项目造成危害。甚至已经有相当部分开发人员在网络评论中表现出对微软在行为、动机以及未来服务计划等层面的信任缺失态度。

事实上，如今的微软已经今非昔比。

首先，微软自己本身就拥有众多高端开源项目，并将其全面托管在GitHub之上。除此之外，微软还在GitHub上托管着面向开发人员的文本编辑器Visual Studio Code、.NET运行库、Edge浏览器的Chakra JavaScript引擎等等。就连微软旗下的最新文档系统也得到了GitHub的支持。与此同时，据了解微软还在以有效的方式参与社区贡献并编写开源代码。

发布源代码与开放式开发并不是一回事。有些企业建立开源项目，但所有开发工作都在内部进行，这意味着其几乎不接受外部贡献。这类代码会定期发布（通常不提供完整的提交历史记录，因此无法查看代码是如何逐步开发完成的），同时附有开源许可。在大多数情况下，微软并没有采取这样的方式。相反地，其利用GitHub作为权威代码库，并将所有开发成果都发布到了GitHub当中。此外，它还欢迎外部贡献，利用GitHub的问题追踪功能公开记录错误及功能请求，就各项目与对应用户及开发者社区进行沟通，从而确定新的开发优先级。

当然，微软公司在开源领域也有一些“黑历史”。比如它曾经公开对开源社区表达过“敌意”——2001年，时任CEO的Steve Ballmer曾表示“Linux是一种癌症”，因为其GPL许可具有病毒的性质。同时，他还在微软1995年的企业HTML策略备忘录当中，明确提到应“拥抱、扩展及消灭”无法控制的平台与标准。

但时至今日，微软已经能够理解并接受开源开发方式，包括严格技术意义上的源代码发布以及更为广泛的社区驱动协作开发。坦率地说，这种趋势似乎已经不可逆转，而且我们也完全能够理解微软的思路：公司内部有很多程序员都在工作，而其中相当一部分都是开源软件的用户或贡献者。他们已经意识到这一点，因此微软选择这样的道路也只是时间问题。

作为一家私营企业，我们并不太清楚GitHub公司的运营状况，但作出一些合理的推断应该并不困难。该公司已经进行了两轮风险融资，其中一笔为1亿美元，另一笔为2.5亿美元。2015年发布的财务数据则让人大吃一惊，该公司正以惊人的速度烧钱——单是员工的薪酬与福利就足以消耗掉全部收入。即使对这些数字作出更为积极的分析，GitHub公司在今年上半年也已经花掉了2.5亿美元。

此外，GitHub公司在过去一年时间中也一直在物色新的CEO人选。当然，用这么长时间寻找新任CEO倒并一定是什么大问题，或许某位理想的候选人在最终阶段选择退出，因此致使该公司不得不重新开始寻找。此外，GitHub公司CEO悬而未决也并不一定代表着该公司面临的只有财务问题——举例来说，其中也可能存在性别歧视与性骚扰等曾于2014年传出的风波。不过必须承认的是，长达一年的追寻意味着GitHub公司很难找到有意愿、有能力且有信心带领企业解决上述难题的人选，此外长期无法盈利也使得不少CEO候选人对这一职位望而却步。

因此，如果资金问题确实存在，那么GitHub对于自己的下一步只有少数几个选择：进行又一轮风险融资、首次公开募股或者整体出售。

上市与风险融资都会带来类似的后果：任何投资者都必然要查看其财务情况，而其中一望无际的赤字往往会将投资者吓得退避三舍。因此，该公司的现有投资方可能更倾向于上市或出售这两种途径。相比之下，首轮公开募股需要相当长的筹备时间，而GitHub目前最缺的恐怕正是时间。

与风险融资或公开募股相比，整体出售拥有几大突出优势：其能够显著缩短盈利能力的实现过程。现金注入并不能帮助GitHub直接与企业客户相对接。而接受微软、亚马逊或者谷歌等巨头的收购，则可帮助其直接迈入企业市场。GitHub不再需要自行建立销售渠道，而可以利用收购方的既有渠道，并通过更大的影响力获得远快于单纯现金注入的业务构建速度。所以，无论是不是微软，GitHub被收购几乎早已注定。

其实有能力买下GitHub的人选不算多，但也不算少。除了微软之外，谷歌、亚马逊、苹果、Facebook、IBM以及甲骨文等公司都有可能提供正确的“技术”与“资金”组合完成这笔收购。

不过很难想象会有人支持IBM或甲骨文买下GitHub。甲骨文对谷歌公司在Android系统中使用Java的诉讼、高昂的数据库产品定价以及扼杀开源Solaris开发等行为已经使其在开源领域当中成为最受人诟病的公司之一。而IBM与开源社区之间的合作似乎微不足道，而且人们普遍认为蓝色巨人正步入衰退。这种颓势已经存在多年，其正在向现有大型机客户销售新的大型机设备，虽然IBM在人工智能与量子计算领域的研究可能终有一天会带来回报。然而，目前其显然还不适合收购GitHub。

Facebook公司不具备提升GitHub盈利能力所必需的企业合作关系网，而且其内部使用的还是Git的竞争对手Mercurial。虽然Facebook公司确实在投资开发者工具（例如其开发出了开源C++库，也在Clang/LLVM编译器的开发当中作出了贡献），但其并不向开发者销售工具与服务。此外，信息安全问题仍然深深困扰着Facebook公司。

苹果公司的企业覆盖面更广，但却仍然不够理想。比如它对于开发GitHub这种强调平台中立性与语言中立性的服务方案的兴趣相当有限，而且其在开发者工具方面的投入也一直比较低。此外，苹果公司的开源合作表现可谓参差不齐——其在部分开源领域（例如WebKit渲染引擎）以开放方式运作，但其它开源工作则仅保持着周期性代码交付（实际开发工作皆立足内部环境处理）。

亚马逊、谷歌以及微软相比之下皆拥有更为强大的企业影响力，而且也都向开发者社区销售平台与服务。这意味着三者是成为GitHub较为合理的最终归属。同时，三家公司也都与GitHub存在着业务重叠。亚马逊与谷歌已经提供托管Git代码库（分别为AWS CodeCommit与谷歌云源代码库）；微软公司则拥有Visual Studio Team服务（简称VSTS），包括托管Git代码库。

其中微软的交集最值得关注，因为VSTS同样提供问题追踪与其它集成化功能。此外，微软对于开发者工具市场的理解也在三者当中最为深入：它一直在销售其开发工具以满足自身需求，而且早在谷歌与亚马逊参与之前就在为受众创建相关软件。

因此，三家公司都能够通过具有实际意义的方式推动GitHub发展，例如将其自动部署至各自云平台当中，并与自身构建与测试系统相集成。微软公司甚至已经完成过一次这样的整合：在今年的Build版本当中，微软方面宣布GitHub代码库将能够直接接入其App Center移动测试服务，以便用户在每次提交新代码时执行自动化测试。除此之外，微软的开发者市场探索也走得更进一步——Visual Studio是一套备受推崇的开发环境，其同样内置对GitHub的支持能力。

但是，需要注意的是，亚马逊在开源领域的声誉相当糟糕。尽管该公司的云服务已经成为市场领导者且备受尊重，但其似乎已经明确表示不会参与开源事务。当然，这并不代表着亚马逊的收购必然会损害GitHub的利益（正如微软与谷歌一样，亚马逊内部的众多工程师也身为GitHub用户，因此即使管理层缺乏兴趣，基层人员也将为GitHub提供强有力的支持）。然而，这样的组合恐怕很难使GitHub继续成为开源领域的天然聚居地。

此外，谷歌公司在开源领域的表现也有好有坏。其在Chromium浏览器等项目当中以开放形式进行开发; 但Android等项目则仍然保持着内部开发方式。谷歌与微软双方都很清楚开源项目所面临的实际需求：与开源社区积极合作。正因为如此，二者无疑是GitHub收购方的合理人选。

相比较而言，微软的产品拥有更为自然的固有适应性。谷歌公司的内部版本控制系统为Piper，这是一套专有内部系统。其拥有强大的可扩展性，同时亦提供众多有趣的功能; 但除了谷歌之外，其他人并不能加以使用。为此，微软公司还正在将其大部分开发项目迁移至Git当中。这使得它必须修改Git以满足自身大型项目的规模需求，但其目前正在与Git开发人员合作以将这些修改引入主Git代码库当中，从而最终以标准化方式确保Git能够满足微软的所有工作需要。

上述工作无疑极具现实价值，因为微软公司所做出的修改并不仅仅是为了自身利益。GitHub利用这些扩展也将能够更好地满足企业客户的需求。大多数企业的代码库在规模上虽然不可能与高达300 GB的微软Windows版本库相比肩，但有时候仍然会超出Git的标准要求。GitHub需要满足企业客户需求方可实现盈利，在这方面微软的独特优势正在于其已经开发的Git并解决了这类需求。

总的来说，一方面，微软公司为GitHub提供的必要功能（大部分属于付费企业客户功能）能够保证该开源社区处于更健康的运营状态；另一方面，微软也拥有销售渠道，拥有能够使Git（以及GitHub）的企业支持服务获得更大收益的受众基础，同时也拥有广泛的开发者支持群体。

因此，对这笔交易抱有不满的朋友们其实大可不必如此，您不妨以乐观的态度庆祝GitHub找到了最适合自己的新东家。