![]()
上个月，又一次以member的身份参加国际内部开源基金会InnerSource Commons组织的InnerSource Summit 2021，并分享了一个议题。现在抽一点时间，写下我参加本次Summit的一些感受，并分享给大家。
首先介绍一下什么是内部开源和内部开源基金会。内部开源(InnerSource)就是在企业内部，采用开源社区习惯的方式进行协作，简单来说就是在企业内部开放源码，并接受其他团队的贡献，可以参考这里（gitee上关于内源的专栏）。 而国际内部开源基金会（InnerSource Commons，https://innersourcecommons.org/）就是一个企业间交流和分享内部开源方法论和落地实践的社区，它创建于2015年，采用类似Apache开源软件基金会即501（c）（3）非赢利组织的方式运作，每年都会举行Summit来集中进行内部开源经验的分享和交流。疫情之前Summit是在线下，疫情之后以线上的方式运行。同时也有一些其他的协作内容，包括books，patterns, learing-path等。
然后介绍一下本次的InnerSource Summit，时间是2021年11月17日到18日，共有25+ Speaker在线上进行专题分享，同时在Slack的专门频道上交流。
下面是我从视频上的截图，可以看到全部spearker，按照身份基本上分为三类，
- 基金会的管理人员：包括Chairman Danese Cooper，VP Georg Grutter，执行总监Clare Dillion
- 开源社区的名流：包括Apache基金会创始人之一Brian Behlendorf， 畅销书《People Powered》的作者Jono Bacon，
- 当然最多的是各个企业进行内部开源实践的负责人，包括微软，IBM，Morgan Stanley，US Bank，Bloomberg，Shell，Didi等。
![]()
我来重点介绍几个我觉得有意思的talk吧。
- Danese Cooper的Chair's Address
- 微软同学的分享
- Morgan Stanley同学的分享
1. Chair's Address.
Danese Cooper 是开源著名的活动家，也是InnerSource Commons社区的创始人。
跟往常一样，她的Slide总是从Happy InnerSource Day开始，
![]()
今年已经是InnerSource Commons社区创建的第7年了，时间过的真快。
![]()
在她的分享中，她回顾了社区的进展，现在社区中有1500+用户来自500+企业，都是已经在采用InnerSource方法的企业。
国外著名的企业包括3M，IBM，Microsoft，SAP，Ford，Nike，SAP，Walmart，Morgan Stanley，Nasa等，
国内著名的企业包括腾讯，百度，华为等。
![]()
2. 微软同学的分享--InnerSource at Microsoft
微软负责InnerSource的Senior Program Manager Arno分享了《InnerSource at Microsoft》。
他在talk中提到，微软的雇员超过18万，其中50%是工程师，公司代码仓库超过8万，每个季度约有1百50万次代码提交。
![]()
在这种公司里面推行InnerSource是一个很大的挑战，他们从2014年开始建立开源办公室即OSPO，2018年起成立公司级的InnerSource推进组织。
他提到在微软内部，采用ALL-In的方式，即绝大多数项目都是内部开源状态，全部工程师都能看到并做贡献。有些项目外部贡献相当多，比例在15%到35%之间，（说老实话，这个比例很让我吃惊。）他们完善了HR的Review Process来激励工程师进行协同贡献。还组织了很多运营活动，包括定期的Meetup，Casestudies，还有Hack events等来帮助和推广内部开源项目。
他们还建立了比较详细的度量体系，包括项目级别的度量来帮助项目分析和改进， 和公司级别的度量。
项目级别的度量主要度量PR相关的指标，（PR means patch request，即提交一个patch。）
例如对 PR的反应时间，要求做到比较短，推荐做到平均1小时以内进行反馈。要求PR内部的平均时间应该和PR 外部贡献的平均时间保持一致。
公司级别的度量包括参与协同的人数等。
他的总结是经过3年多的努力，“InnerSource Does Move the needle”。 我特地查了下“Move the needle”，在微软这个说法是指有明显的改善。
To move the needle is to have a noticeable effect, presumably positive.
3. Morgan Stanley同学的分享--Moving a Legacy Codebase to an InnerSource Model
这个talk吸引我的是，一般金融企业相对比较保守，Morgan Stanely这种金融企业也能做内部开源吗？第二是新创的代码容易进行新方法的尝试，对于老代码Legacy项目做内部开源是很难的。所以我把她的分享好好看了下。
这位同学谈到她们有一个20年的老项目，是一个java的lib，被很多其他业务部门所使用，现在打算进入维护状态不再继续基于此进行新功能的开发了。他们采用内部开源的方式希望可以达到如下目的：
- 直接引入最终用户来提升这个老项目的生命周期
- 通过内部开源贡献bugfix来解决维护团队人力不足的情况
- 测验内部开源方法是否可以在公司内work
这种方式进行了两年多，他们意识到InnerSource不是把代码开源就完了，然后就可以坐等贡献和入了。
InnerSource要取得好的结果，要让协同部门做高质量的贡献，必须做好如下的事情。
- 项目要容易build
- 项目要有好的文档，告诉用户如何读懂代码
- 项目要有好的测试
这些都是花费了维护团队不少人力完成的事情，事实上他们是在偿还技术债务。
之后跟协作团队还需要很好的沟通，包括了解彼此的期望，即哪些feature是维护团队希望协作团队贡献的，哪些feature是协作团队的需求。
代码贡献的code style是什么，贡献新功能的测试覆盖率要求是多少，等等。
运行了两年多，维护团队花了不少人力完善build脚本，开发文档和测试脚本，跟贡献者的沟通也花了不少时间。
"Was it worth the effort？
Yes，absolutely it was. "
项目采用内源方式进行工作，完全达到了事前预期，项目延长了生命力，有源源不断的贡献者提交bugfix和新的功能，有些长期贡献者甚至成为这个项目的co-owner，一起leading开发和项目规划等。
现在她所在部门负责的所有代码仓库，都采用内部开源的方式进行工作。
最后她总结到：
1. InnerSource 一个老项目花费的人力比她预想的多，需要完善build，测试和文档，但她也承认这本来就是项目组早该完成的事情
2. InnerSource 既提升了他们自己的开发体验，又在用户中受到非常大的欢迎。
当然这次Summit还有很多有意思的分享，视频总的链接在这里。
滴滴负责内部开源的安旭同学分享了她在滴滴内部推行InnerSource的实践和体会；
我也简单分析了一下InnerSource和DevOps的共生关系。
最后是总结：
作为InnerSource Commons的member，参加Summit已经是第三次了。
总的感觉是内部开源（InnerSource）正当时，越来越多的主流大厂在采用这种方式，某些厂实践的深度和广度都令人感叹。
