如何在公司内部创建一个InnerSource社区

开源恰逢盛世,成为了主流,开放式的创新呈大势所趋,然而,企业、互联网公司对待开源的态度,更多的是在使用软件而已,可是面对开源的文化和开发方法又无法忽视,至于开发者本身,往往在上游和公司短期目标间纠结、挣扎。InnerSource应用而生,本文是理论的概括(译文),开源之道专题深度解读。

Sat Apr 1, 2017 | 4600 Words | 大约需要阅读 10 分钟 | |

近些年来,有一个经常被人们提起的和开源有关的名词——InnerSource,什么是InnerSource?简单来讲,就是在企业自己的内部采用开源的方法论和策略。也就是说,在协作和社区的建设方面向开源学习,但是代码是私有的,社区也只是对自己的内部员工开放。

作为社区战略和领导力咨询顾问,我拥有在很多家公司创建InnerSource社区的工作经历。所以想借此机会来和大家分享一下关于InnerSource的战略,或许能够帮助到打算使用InnerSource的你。

文化胜于代码

对于绝大多数公司来说,采用InnerSource的第一步一定是找个试点项目来启动,典型的做法就是找个愿意尝试的团队来专门做这件事。因此,InnerSource 对于公司现有的文化来说是全新的流程和方法论,这些新的文化的调整是能否成功实施InnerSource的关键,也是其中最大的挑战。

实现InnerSource有一个常见的误区,那就是在公司内部实现开源软件开发生命周期即可,这是十分可以理解的。比如说开源软件的生命周期中常见的:开放的代码仓库、沟通渠道、鼓励切出分支、代码审核、以及持续集成/持续部署,没错,这些绝对都是InnerSource必须的内容。但是,这并非是真正的实质性的要点。打个比方,这些东西比作为乐高积木,其中真正的诀窍是建立一个人们有权利和受到鼓励利用这些积木来构造不可思议的东西的环境。千万不要过多的关注这些“积木”。

因此,实现 InnerSource 很重要的一步就是构建文化、环境、以及采用与开放源码那样的做法,做出一系列激励措施。 一种文化,若是从头开始构建,相对会容易很多,若是让一种文化去适应另外一种,如 InnerSource 去适应传统企业组织,这是具有极大挑战的事情。

文化的改变绝非是几项规定就可以的,它是构建更广泛群体受到影响的社会公约的个人行动的合集,要做好这点,作为实行InnerSource的主要推动者,你需要从高层次来思考你的员工,诸如如何使他们的工作更加轻松,更有效率,更有价值,更具协作性?

当能够理解了现有文化的痛点,且成员能够理解 InnerSource 可以帮助他们解决这些痛点,那么施行的过程就会变得越来越顺利。

方法论

鉴于 InnerSource 是比较大的文化调整,其中包含一些经过验证的开源工作流程方法,这样就引出了一个非常有意思的问题:我们该如何管理 InnerSource 的流程?

我曾经看到过很多公司所经历的InnerSource,其中有成功的,也有失败的。有些使用的是自上而下的策略,公司向员工宣布要实施InnerSource,然后员工及团队就会被指定某些任务。也有公司实行的是自下而上的政策,会设立一个专门的InnerSource团队,非正式的尝试推动员工采用InnerSource流程。

我个人在这里明确表示,我不会采用上述任何一种,而是两者兼顾。对于任何的文化变革,都将需要一种自上而下的方法,用来强调和鼓励新的工作方式,从执行团队和公司领导者开始。公司的领导层应该去塑造一个环境,即员工可以自发的、自下而上的来进行InnerSource的实施,而不是去制定什么规则。

说句实在话,每个人都厌恶类似的文化变革。大家都经历过公司的高管引进新的工作方式,诸如敏捷、看板、结对编程等等之类的。常见的情况是强行塞给员工,这其实是一种本末倒置的错误:没有去激励自己的员工来塑造自身的文化,而是强迫他们的自由意志。

我要推荐的方法是,建立一个循序渐进的InnerSource策略,并定期回顾。

举例来说,每6个月就是新的周期的开始,在上个周期结束之前,领导小组将对员工进行调查,以了解内部资源计划运作状况,审查员工的反馈意见,并为新的周期制定核心目标。这样的话,员工就能够以结构化的方式,在帮助塑造如何实现这些目标发挥作用,并扮演最关键的角色。比如,可以让独立的团队或小组能够聚焦于沟通、同侪审查、QA、社区成长和参与,等等。在整个实施InnerSource过程中,其核心是促进领导小组的对话沟通,并给予更多的指导,以及帮助独立的成员做出有价值的贡献,并能够保持这样继续向前推进。

这就是开源的运转方式。如果一个人想要参与到项目中来,不一定非的是提交代码,也可以在项目的运营中发挥作用。能够将这点传授给InnerSource部门和员工是非常重要的——最有价值的公司是员工感觉到能够以积极的方式影响文化的公司。

异步和远程协作

InnerSource ,其中最为有趣并颇具挑战性的就是:它依赖于异步的广泛协作。换句话说,进行协作时不要求必须是处于同一时区或同一地点。

在现实中最为常见的例子就是,很多公司要求自己的员工都在同一个办公室工作,且大部分的业务都在一间会议室内进行的,或者是电话会议,又或者是电子邮件。这样的公司,雇佣了远程工作者的话,会非常的难以适应,哪怕是开会的时候在路上,或在家中,都是难以容忍的。

其实,开源的其中一个核心的工作方式就是几乎所有的参与都是异步的,所有的社区活动、开发过程(代码提交、缺陷管理、和代码审核)、QA、以及发布管理几乎都是在线来完成的,可能来自各个不同的时区。不成文的规则、个人冲刺、会议这些异步的组合是一种非常有效和高效的方法。

但是这些对于公司来说是难以贯彻执行的。根据我个人所经历的案例来讲,有些公司还是依据传统的,比如项目规划还是举行各种会议、代码审核还是大家围着一张桌子来进行、也没有异步沟通的渠道和基础设施。若要想做好InnerSource,就一定要把异步的工作做好,不仅在办公场所增强沟通的各种渠道,更要增加在线的协作。

这样做的另一个好处就是建立一个可以支持远程工作的环境,而远程工作是任何一个做技术工作的人都向往的。人们常说雇到靠谱的人很难,可以有没有想过正是因为必须迁移到你的城市才是最大的拦路虎?因此,对于InnerSource 的投入,若是能够做到雇佣远程人员(任何人都做到)会有更多的回报,而且事情还变得容易起来。当然,能够营造出让远程人员高效的工作环境更是非常重要的。

同侪审查和工作流程

对于要施行 InnerSource 的公司来说,其中最为有趣的莫过于同侪审查流程了。

对于熟悉开源界的同仁来说,在日常的协作有两件非常重要的关于参与的事情:

  1. 所有的贡献者都可以查看其他开发者的成果(不管是新的功能实现还是漏洞修复)。
  2. 这些同侪审查的过程和结果对于所有人都是开放的。

不要小瞧这两点,如此开放式的同侪审查可能对于新的开源接触者来说,是非常反感并难以接受的。如果公司过去工程师们是没有代码审查或者编码是私人的活动,那么突然改变为开放式的同侪审查,会产生社交尴尬和不安。

这些调整要认真而慎重的去对待,在很大程度上,我们应该去打造文化氛围,做到能够虚心的接受批评,并鼓励失败,应该珍惜同侪,帮助我们提升自己。在重申一遍,要传达给员工,这些都是短暂的变革带来的不适应,最初可能有些小的问题,但长远来看他们终究能够感受得到受益的。

读到这里,聪明的读者可能已经意识到:构建社区(无论公共的社区还是企业内部的InnerSource社区)的核心是去理解社区成员的心理!然后将这些心理模式转化为工作流程,从而帮助社区领导者去鼓励那些值得鼓励的行为。

例如,有两种行为经济学原理在同侪审查和工作流程中发挥关键作用:

  1. 宜家效应 :我们更加倾向于购买需要自己组合的物品。因此,我们对我们所做的事情投入更多的价值,且往往会夸大价值。
  2. 自治原则 :这对于人们的选择是至关重要的。如果我们不能感觉控制自己的命运,或做出自己的选择的话,就会感觉被困住、受到限制。

下面我们就来谈谈这两个原理对于同侪审查和工作流程的具体作用。鉴于宜家效应,我们认为人们应该会去PR或修复Bug是因为他们自己认为有价值。因此,我们在同侪审查过程中,应客观的评价贡献者的价值,独立且不带任何感情(审查差异的具体部分,需要至少两名审核者,鼓励具体的反馈等)。至于自治原则,我们应该确保员工尽可能地改进、定制和破解他们的工具链和工作流程,并定期接受反馈和持续投入,以让他们做的更好。

声誉,激励和参与

构建InnerSource文化另外一个关键的因素是该如何追踪大家的绩效,该如何奖励、鼓励等类似的行为。

其中,这包含了三个因素:

  1. 我们需要有一种方法来定量地表示该人的工作质量。这涉及到构建一个足够复杂到系统,用来评估个人的行为并为之赋予价值,或者干脆就是简单直接,就是观察人们是如何工作的,这里非常重要的一点就是,人们应该对自我有准备的定位。
  2. 根据他们的工作表现,我们需要提供不同的奖励和奖励来鼓励我们想要看到的行为。有两种较常见的奖励办法,外在 奖励,即物品,送一些诸如T恤、连帽卫衣、礼品卡、现金等等,内部 奖励,即精神上的,如尊重、认同、钦佩等等,二者都很重要,当然更要注意二者之间的平衡。根据自身所希望鼓励的行为,我建议整合启发行动和奖励激励措施,以验证我所说的。
  3. 根据员工的工作,分为不同的组织,并以不同的方式进行分工是很有帮助的。举例来说,新人若是能够有导师带领、获得支持、以及较大范围的被指引,成长是很迅速的。换句话说,那些最活跃和最完善的员工是可以拥有深刻的洞察力和指导意义的,他们在帮助塑造公司文化方面发挥着重要的作用。

以上便是我对施行和采用InnerSource的公司的文化调整的几点建议。欢迎拍砖。

关于作者

Image of author 1Jono Bacon 是卓越的社区经理、演说家、作家。他目前担任 GitHub 的社区总监,曾经担任过的职位有:在 Canonical 担任社区团队的经理、XPRIZE 基金会的社区经理。Bacon 是一名很有特点的作家,社区管理的布道师和实践者,并且是畅销书《社区的艺术》(O’Reilly)的作者。并且是社区领导力峰会(主要定位于社区管理者和领导者的年度会议)的创始人,也是社区领导力论坛的创始人。经常在各种大型的会议就社区管理、领导力、以及最佳实践发表主题演讲。Bacon 还为各种组织和公司提供社区管理的咨询顾问工作,无论社区是公司内部还是外部的,这其中包括有:德国银行、Intel、SAP、索尼移动、三星、开放计算项目、IBM、戴森、Mozilla、全国整理承包商协会、AlienVault等。除了是《社区的艺术》的作者之外,Bacon 还是多本书籍的合著者,如《Linux 桌面 Hacks》(O’Reilly)、《官方 Ubuntu 手册》(Prentice Hall)、《PHP 和 MySQL 实践》(Prentice Hall),同时还在超过12家不同的媒体上发布超过500篇的文章,此外,Bacon 还为杂志定期撰写文章。Bacon 也是著名流行的播客 LugRadio 的联合创始人,LugRadio 运营了4年,超过2百万的下载,以及15,000名忠实听众,并在英国和美国均做过5次的现场直播。同时也是播客 Shot Of Jaq 的联合创始人,以及播客 Bad Voltage 的联合创始人,Bad Voltage 是一个关于技术、开源、政治的蛮流行的播客。Bacon 还创建过很多的项目,如Ubuntu Accomplishments、Jokosher、Acire、Python Snippets、 Lernid 软件等。他和他的妻子 Erica、以及儿子 Jack 幸福的生活在加州的旧金山湾区。

本文由作者Jono Bacon 发表在Opensource.com上:How to create an internal innersource community。由开源之道翻译共享。本文在Creative Commons BY-SA 4.0许可证下发布。欢迎转载!