InnerSource仅仅是一个名称，它是一种在企业内部应用开源软件实践的软件开发方法。来自 PayPal 的技术带头人 Cedric Williams，在开源大会 OSCON上解释了在 PayPal 如何使用 InnerSource 来打破孤岛、加强合作、增加生产力。
实践开始于 18 个月以前，清算平台的团队当时大概需要花 2/3 的时间来重写由区域团队所提交的代码。而区域团队，有一个很重要的职责，那就是确保 PayPal 能够在不同国家符合当地的一些规定。这种情况对于谁都没有益处。清算团队没法做好自己的本职工作，而区域团队所话费时间写的大量代码而别人又用不上。
PayPal 从开放源代码软件中汲取了灵感，尤其是来自 Apache 软件基金会的实践。他们发现了开源软件的组织原则，即每个项目都有各个金字塔的层：用户，在最底层；贡献者；可信任的提交者；最上层是架构师／开发者的领导者。PayPal 评估了这些个情况后，作出最大的变化是引入“可信任的提交者”角色。
找到合适的可信任的提交者可不是一个简单的决定：清算团队中只有 10% 的人是这样的角色。Williams 在此回答了人们一个问题，成为可信任的提交者需要哪些技术技能？首先必须有深厚的技术功底，然后对于代码库的核心了如指掌，即使有了这两样也不能成为最出色的。可信任的提交者还必需拥有良好的人际交往能力，他们要成为教练员。他们需要以积极、清晰的方式来沟通。举例来说，不要说“这些代码无法接受”，而是需要这么去说“这是我需要你去做的方可接受你的代码，这里有几点原因［...］”。
不出所料，引入可信任提交者角色带来了政治上的扯皮风险，所以不得不小心的去处理，无论是清算团队内部还是外部。为了使全局能够接受变化，可信任提交者不仅仅要审核来自区域团队所提交的代码，还要审核来自清算团队其他成员所提交的代码。
实施 6 个月之后效果出来了，清算团队再也没有花时间去重写别人的代码了，而仅仅花了 10% 的时间去做审核代码的工作，该团队进行了一次大规模的重构，且在没有做任何计划的情况下提升了 4 倍的性能。团队成员的心态也从排斥转变为积极的接受。一个最大的副产品是所有相关的沟通都通过写作来完成，多数是在 Github 上：PayPal 使用 Github 来托管他们的开源软件，使用企业版 Github 来托管他们的闭源项目。这使得能够在所有的团队之间进行知识共享和传播。
在 InnerSource 之前，PayPal 尝过不同的方法，它们是：自顶向下的强制和驻场。
第一种方法，即自顶向下，是比较传统和古老的了。定义严格的规则和利益相关者，自顶向下，让人们承担责任。这无法解决问题，但是可以产生很多的会议。
驻场的情况会好一点。来自各个区域团队的高级工程师们都被租借到圣荷西，和开发团队的成员们在一起工作。驻场能够达到知识的共享，且能够对彼此团队的行为有所了解。非常遗憾的是 ，一旦这些工程师们回到了各自的区域团队之后，他们就会成为瓶颈。他们发现找不到时间或者是没有所需要的技能将他们所学到的传授给他人。
Williams 为 InnerSource 的入门者提供了一些建议。在第一步，在你的工程师团队中将可信任提交者限制在 10%，要求所有的代码都须公开审核，且要确保代码的审核要聚焦于完成什么从而使代码更加的良好；第二，要求所有的对话都是成熟的、得到尊重的；第三，分享你的经验。PayPal 将于 11 月 9 号在加利福尼亚的圣荷西举办首届InnerSource 峰会。PayPal 还为此赞助了一本小书，目标读者是哪些想进一步学习此方法的人们。
注册/登录 InfoQ 发表评论