内部开源系列之二 —— 经典案例
Mon Jun 12, 2017 | 2800 Words | 大约需要阅读 6 分钟 | |
引子
InnerSource 的介绍，我似乎陷入了一种不知该从何讲起的尴尬局面，也就是所谓的破局，理论？历史？案例？实践？文化？曾几何时，脑子灵光一闪，希望通过某个假想中的案例来阐述，从管理、文化、开发、协作、产品、生态、人才等多个角度来逐步细致将一个InnerSource贯彻到底。但是想法总归是想法，需要时间来慢慢的完善。难道是我的每周一篇文章时间定错了？还是应该将InnerSource单独拿出来，独立成系列？我陷入了思考和停滞状态。
但是，国人的思维是喜欢案例的！尤其是你出身于某个案例，因为保守，不愿冒险！好吧，思考归思考，材料还的积累。于是有了此文，尝试将现有的InnerSource案例整理出来。
InnerSource 案例
在一个普遍推崇模仿、山寨的文化中，谈案例是最受欢迎的，我也顺着这个思路来写一篇试试水，以实际行动来验证下。
InnerSource 正如我在上一篇文章中所提到的，不是什么新的概念和实践，而是有很多学界和厂商都在研究、运行，下面笔者就列出一些业界公开的案例。
PayPal
PayPal 是在2013年施行的InnerSource，主要是内部的开发效率遇到了严重的问题，由于PayPal是一家跨国公司，各个国家的清算情况又不尽相同，于是牵扯到沟通、协调、覆盖代码等问题，在施行InnerSource之前，PayPal施行过两种办法：自顶向下的强制和驻场。最终证明这都不可行。
PayPal从开放源代码软件中汲取了灵感，尤其是来自Apache软件基金会的实践。他们发现了开源软件的组织原则，即每个项目都有各个金字塔的层：用户，在最底层；贡献者；可信任的提交者；最上层是架构师／开发者的领导者。PayPal评估了这些个情况后，作出最大的变化是引入“可信任的提交者”角色。
从2015 年开始，PayPal 在InnerSource施行成功之后，开始了他们的积极推广之旅，成立了InnerSource corporate-vs-community-better-open-source 社区，每年做一次InnerSource的调查，并组织面向全世界的InnerSource峰会。
PayPal 自身是InnerSource的积极受益者。这点是毋庸置疑的。当然这也得感谢PayPal的技术带头人：Cedric Williams。
沃尔玛
沃尔玛给人的感觉，和领先的IT技术似乎无关，但是，沃尔玛一直在电商方面努力着。技术方面从eBay挖来了Jeremy King，Jeremy King上任以来就在推行InnerSource，在一篇报道中指出： > 沃尔玛的研发团队有一千多人，他们每个月要做约30000次代码部署，但是King仍认为他们只是“世界上最大的创业团队”而已，因为有的公司做一个项目可能就会要上千人了。沃尔玛的一千多名研发工程师分布在约100个小组中，每个小组有10-20人，开发、构建、测试和部署等全部由小组自行负责，以DevOps模式工作。尽管大家的工作模式都是持续集成、迭代开发，不可避免地有时候某些团队会由于任务过多而成为瓶颈，这样在小组之间可以共享、开发和贡献代码就非常重要，可以在某种程度上避免这样的“单点故障”了。King举例道，比如某个工程师需要能连接到支付网关上，但负责支付网关的团队手上已经堆积了5个更重要的项目了，没时间做这个。在这种情况下这个工程师可以自己把相关功能实现了，然后再请支付网关团队的人审核通过，就可以了。或者比如说一个支付团队的工程师对于购物车等功能忽然有了什么新想法，那他就直接简单的作出原型来，然后通过GitHub提交给对应团队就好了。
InnerSource除了让沃尔玛的基础设施及时的赶上时代，还为这个传统的零售业巨头吸引人才提供了很大的契机：
沃尔玛推行开源的开发方式之后，对开源社区成果的使用和回馈行为还帮助他们吸引了许多技术人才。在他们准备录用的候选人中，50%手中还握有Google、Apple、Facebook、LindedIn或其他硅谷著名公司的Offer，可是最终这些人中有70%还是选择了沃尔玛。King把争夺人才胜利的原因归功于两点：一是小而专的团队，二是开源。“大家都对我们已经取得的成就非常赞赏，同时也希望如同在创业公司工作一样。”
当然，沃尔玛也在积极的参与到开源中来，不仅鼓励工程师积极的参与到上游的开发中，还将内部的项目开源出来，如云管平台OneOps、Electrode移动开发平台。
AutoDesk
AutoDesk 是一家专有软件公司，他们并没有任何开源方面的消息，但是设立了开源战略总监这样一个职位。我们的InnerSource也是从这里了解到的。
AutoDesk 的开源战略总监Guy Martin，Guy Martin的经历很有意思，早期在Sun工作，通过JavaCar项目认识了开源，之后在Motorola从事InnerSource的工作，为PHP和Scuttle等开源项目做过贡献。
GM在Autodesk的另外一部分工作就是负责企业内部开源。他表示，对于一个拥有超过150个产品的公司，合作开发在产品研发的各个阶段都起着非常重要的作用。同时，随着Autodesk的很多产品开始与云相关。可重用组件对保证用户体验变得十分重要。内部开源很好的保证了这些组件的开发进度和质量。
Google 向来是支持开源的，是少有的对开源有着执着情怀的公司。在开源界享有盛誉的GSoC，以及将开源放在战略地位的“开源项目办公室”。一个和开源有着如此渊源的公司，是如何实施InnerSource的呢？
其实，这是笔者照着InnerSource的理念为Google强加的，Google本身可能对这个概念并不感冒，至少没有过公开的表态。理由有2:
- 众所周知，Google 全公司采用的是一个代码仓库！Google的所有员工都可以查看修改源代码。
- 在《SRE运维揭秘》一书中，作者谈到gRPC等项目的高效性，得益于不同部门的透明协作。
就凭两篇论文，就可以说明，Google内部对于开源方法论运用之娴熟！当然，这也和Google的文化有关，他们本身受益于开源，始终是开源的支持者。
其它
在IEEE的一篇论文：InnerSource —— 企业内部采用开源方法实践 中，谈到采用InnerSource的有飞利浦医疗保健、阿尔卡特朗讯、飞利浦研究院、惠普、IBM、SAP等，当然InnerSource本身的方法论也在不断的变化着，其实现在PayPal所倡导的，和当年Tim O’Reilly首次提出的概念已经相差很远了。
现在是云计算、大数据、人工智能的时代，这些曾经走上浪潮之巅的公司的案例相信很多人已经不怎么感兴趣。所以InnerSource也得与时俱进，增加新的内容，但是笔者更加的倾向于InnerSource的外延性更多了，更加的强调企业参与到社区上游项目的重要性，以及人才的管理上。
后续
InnerSource 已经发展为一个庞大的课题，开源之道会慢慢、逐步为大家介绍、引进，并分享业界的经验。下期我们聊聊InnerSource Common刚刚发布的《企业搞内部开源必须弄明白的几件事》。欢迎留言反馈。