开源社区与运营 – 2021 上海计算机教育年会演讲稿

大家好,我是马全一,目前在华为技术有限公司工作,任开源社区运营总监,主要负责 openEuler 操作系统的开源社区运营,同时也负责 openGauss 、openLooKen 两个开源项目的运营指导。2000 年参加工作后一直从事技术开发和技术管理等工作;2013 年开始在国内运营 Docker 社区,推广容器技术、Kubernetes 等云原生技术;2015 年加入华为负责 CNCF 等海外基金会的一些工作,维护华为和谷歌、红帽等云原生领域核心企业的开发者关系,同时也参与了华为云容器相关产品的设计和开发;2017 年底离开华为加入腾讯,负责腾讯云容器产品的设计,开源了 TKEStack 项目;2020 年初又回到华为负责 openEuler 操作系统开源社区相关的运营工作。因为工作的原因,这两年也致力于同一些高校操作系统课程的老师合作进行教学改革的探索。


今天和大家主要聊的话题是什么是开源社区以及开源社区和高校的关系等几个方面。在这两年的工作里面,我发现大家对开源、对社区这两个词都有一定的误解,所以今天也是借这机会跟各位老师一起探讨这个非常有意义的话题。

最近这两年 “开源” 这个词逐渐进入到大家的视野,尤其是最近政府把开源写入了十四五的规划中,大家更加迫切的去思考这个词。十四五规划在 第一节 加强关键数字技术创新应用 中写了如下话:

聚焦高端芯片、操作系统、人工智能关键算法、传感器等关键领域,加快推进基础理论、基础算法、装备材料等研发突破与迭代应用。加强通用处理器、云计算系统和软件核心技术一体化研发。加快布局量子计算、量子通信、神经芯片、DNA存储等前沿技术,加强信息科学与生命科学、材料等基础学科的交叉创新,支持数字技术开源社区等创新联合体发展,完善开源知识产权和法律体系,鼓励企业开放软件源代码、硬件设计和应用服务。

这周我也在 工业和信息化部关于印发“十四五”软件和信息技术服务业发展规划的通知 看到了反复出现 ”开源“ 这个词,在整个通知中提到 ”开源“ 有 40 多次。相信教育部等相关部委也会根据十四五规划的精神发布者自己的规划,可以预计 ”开源“ 一定会出现在各种文件中。在国家的文件中,我们可以看到 ”开源“ 是作为一种软件开发的行为出现,是一种软件开发的模式,从封闭的模式到开开放的模式。

当然我们也经常看到国外的一些文章介绍开源,国内甚至出现了一些人称自己是 “开源布道师” 甚至是 “斗士”。从这些人的口中讲出来的开源,更像是一种文化现象,是一种软件开发的指导思想。这让我想起来这些年在软件开发行业经常讲 “DevOps” 这个词,现在大多数软件公司的软件开发和运维都尽量遵循 “DevOps” 。但是 “DevOps” 是没有一个固定规则的,我们看到的一些讲 “DevOps” 的文章也更多是一种最佳实践的总结,所以这些总结都是根据公司的业务发展、技术演进逐渐演化而来的,用一个更加学术的点的词形容 “DevOps” 是形而上学的从非官方角度听到的国内外开源各种内容,和 “DevOps” 更见像一些,也是一种形而上学的指导。

那 ”开源“ 到底是什么呢,其实也根本没有一个官方的定义。最近我也有幸参与了信通院、工信部等部门关于 ”开源“ 的相关标准制定,在各种讨论中来自于各个公司和社区的专家也有各种争论,我看大家一时也不会达成一种共识。当 ”开源“ 对于软件开发影响越来越大,当”软件吞噬世界,开源吞噬软件“这样的论点层出不穷时,就会引来一些主管机构的忧虑,当然就有必要制定标准。制定标准的目的在我看不仅是了发展开源,更多的是管理”开源“这种行为。当然也参照国外的做法,成立了政府领导的非盈利组织开源基金会,这是一个进步,当然也是一个困扰,国内早就有不少非盈利组织承担某些政府职能造成的负面新闻。

从我个人来看更觉得 ”开源“ 是一种文化,是一种文化来指导工程师的软件工作,就像 “DevOps” 指导大家的开发过程更加敏捷和高效一样。如果参与者没有 ”开源“ 的精神,那 ”开源“ 就只是一种动作,把代码开放出来让人访问而已,可能这也是国内会有我从事的这个工作职位 ”开源运营“ 的原因。代码开放出来需要有人访问,需要有人去用,需要有人参与到开源项目中贡献,那怎么办呢?找个人来做这个运营的工作,把社区盘活吧。谁想到这个职位还挺热的,最近每周都会有不同的猎头加我的微信问我某某公司的开源项目是不是感兴趣。

所以 ”开源“ 是一种文化和行为的复合体,是无法没有一个具体标准的行为。所以我想现在看到的国内 ”开源“ 更多是一种行为,文化对于本来已经博大精深的中国文化来讲,融入也就需要漫长的时间,也许更多的是将来会是有一种 “中国特色” 的 “开源” 。当然这不是我们的独特性,在美国和欧盟也都是有更多的 “开源” 被政府、军方进行管理和指导。

提到社区,这又是一种纠结的词需要解释。首先大家提到社区就会想到我们居住的小区,实际在 Community 这个词的翻译成社区后首先用到了我们居住地形容,真正对于文化这个方向,社区这个词实际用的比较少,其实社区是没有物理、时间和空间限制的。

我在运营工作中最被经常被问的问题是如何加入 openEuler 社区?在当前我接触的人里面,大多互联网经历时注册论坛开始的,其实我上学的时候也会跑到水木清华上求各种下载资源的链接。所以在大多数人的眼里,加入社区就是要去个论坛中注册,如果没有注册过程那就不叫加入社区。一般解释到这里的时候,我脑中就会出现电影电视情节中普遍的现象,大学生穿着麻布 Hoodie ,拿着蜡烛口念咒语加入兄弟会的情节。

跟合作伙伴解释什么是开源、什么是社区还好,这正好是我的工作,如果大家都懂开源,我也就失业了,只能回去写代码搞产品设计了。但是公司也让我讲明白如何加入到 openEuler 社区,因为公司有一些其它的组织同时也在搞技术社区,方法就是弄了一个论坛,只要在论坛注册了就是加入了这个技术社区,不管多少方法总是可以搞几十万注册用户的,也就是几十万人加入了某技术社区。这给老板汇报的时候听起来多有气势和价值,所以我的职级徘徊不前是由原因的。当然还有某友商搞的 AI 开源框架,技术做的确实不错,但说起来社区都敢讲百万了,更让我无地自容,愧对公司给我的薪水了。

为了应对公司的纠结,openEuler 以签署 CLA 作为加入社区的条件。CLA 是 Contributor License Agreement 的简称,中文称为贡献者许可协议,其实这是一些大型项目为了在法律诉讼中免责而让开发者签署的一个文件,跟社区其实没什么因果关系。因为 openEuler 设计的 CLA 签署环节中,企业签署需要加盖公章,一般公司都会有个相对比较正式的流程,有法务审核,如果签署的话,是对 openEuler 社区的认可,所以作为该公司加入 openEuler 社区这个说法来看,于情是可以讲的过去。所以公司动用各种部门的力量,在短短两年的时间里面签署了 300 多家公司,而且在当前这个政治形势下,还有不少欧美公司签署,确实是国内执行力最强的公司。只是于理来讲,这和加入社区没有什么关系。

对于社区的真正含义,只要是大家对共同的事务感兴趣就可以说是社区的一份子了。即使我是使用 openEuler 操作系统的用户,没有跟社区有什么交集,都可以说是社区的成员。所以这里关键点是对共同的事务感兴趣,这里的事务可以是实体的也可以是非实体的。所以从形式看,我们可以用另一个词来形容,Club 。当然这个 Club 不是夜店的意思,而是指对某件事情感兴趣的人聚集在一起而形成的团体。我和几个做云原生相关开发的开发者朋友,因为大家都对某种酒类感兴趣,所以在去年疫情的时候组建了一个 ”云原生喝酒 SIG “ ,这里有人喜欢白酒、有人喜欢啤酒,我更喜欢精酿啤酒。其实这就是一个 Club 的形式,我们也可以看作是一个社区,我们经常半夜聚集在一起,通过腾讯会议大家各自拿出藏酒,边喝边讨论技术问题或者各种八卦消息。在我看这是一种非常让人舒服的社区形式,没有必要大家一起签个文件什么的,最近这个社区酒后已经膨胀到要去注册一个 ”云原生喝酒基金会“ 来正式运作几个开源项目了。

所以社区是一群人因为共同的兴趣和爱好,不论时间、空间、年龄、性别、国际、种族等等聚集在一起形成的一种聚集形态。当然可以给这种形态设计一个门槛,签署一些合同或者文件,或者其它的任何形式的仪式。

当我们把开源和社区两个词叠加在一起,就得到了一个组合。华为内部有个黑话可以解释这种组合,这个词就是“正交” 。对于 openEuler 社区来讲,这个共同感兴趣的实体就是 openEuler 开源操作系统,这个社区就是属于下载安装使用的那些开发者,在 gitee 上提交代码的开发者,参加社区会议的开发者,还有那些看到 openEuler 各种宣传但因为拖延症晚期还没有去尝试更深入了解的人。我的工作就是让这些人能够在社区产生更深层次的活动,产生新的想法和 Idea 并且鼓励大家把它变成现实。听起来这份工作是让人心悦神奕的,其实在工作中也是磕磕绊绊一地鸡毛。

我在公司内外最经常讲的话是 “每个人都是趋利” 的,对于我自己也是这样。所以这样一个面向服务器的操作系统,大多数用在数据中心安装的操作系统,实在是无法激起那些已经每天 996 ,007 的开发者去尝试使用的。不管我们提供多少听起来让人热血沸腾的技术特性,对于开发者来说并不能影响他们眼前的工作,也无从有动力做这个尝试。操作系统可以说是这个行业最古老的存在,技术代差以数十年记,在当前互联网和智能设备普及的今天,是拿不出来一个什么特性吸引普通开发者去尝试的。不光是华为,腾讯阿里这些友商的竞品也跟我们面临了同样的问题。

但是华为有自己的战略决心,我们会把精力投入到下一代开发者的培养上,这是其它公司的在这种重投入,长周期和回报低的项目上最终会被甩在华为身后的原因。这是大家这两年在华为参与、主导的跟各个高校合作上,除了之前的各种合作方向之外,操作系统也逐渐增加比重的原因。但是我们看到的是高校的计算机教育上,从事基础软件不光是操作系统,包括数据库的教授和老师是少之又少的。当然这也是 “趋利” 的结果。但是华为有信心更有耐心,会基础软件这个方向持续投入,为整个行业培养培养未来的基石人才。

我们这两年也在尝试和高校从事教学改革之外的合作方式,譬如我们正在和大连理工大学软件学院在开源合规、操作系统、Rust 编程语言等方向展开更多的合作。由华为的技术专家和大学教授一起组建开源实验室,辅导学生在各种前沿的技术方向上投入研究。当然这种研究的基础是必须是开源,必须是在 openEuler是社区进行。我们采用这样开放的研究方式,希望能够尝试把开源社区构建成一个开放的科研平台,聚集不同学校感兴趣的老师一起深入探索。我们希望把开源的文化精神范围扩大,扩大到学术研究的方式上。这件事情给我带来的愉悦感,远远大于给各种企业讲解如何加入开源社区来的更多。

openEuler 开源社区和中国科学院软件研究所深入合作了 2 年,我们共同执行的 暑期 2020 、暑期 2021 是这两年国内开源社区最受瞩目的项目,通过这两年的暑期活动,有近千名高校学生有机会通过开源社区和业界顶尖的工程师合作、学习。最近我们又设计了新的 openEuler 开始社区实习项目,让这种方式从暑期的时间延续到在校的其它时间。学生加入到实习项目后,可以在开源社区领取实习的项目,和华为以及其它合作伙伴的工程师一起学习工作,完成项目后会有相应的积分,获取一定积分就可以得到中国科学院软件研究所开具的实习证明,同时也有实习奖金。我们希望这种方式的实习工作能够得到学校的认可,能够抵学生在校期间的实习学分,让学生有更多的动力参与到开源社区,了解开源社区。期望通过开源,通过社区让学生有机会对自己所学的专业、课程等东西更加深入,能够热爱自己的专业,成为未来软件发展的中坚力量。

我们一直致力在高校和开源社区间建立起一个有效的链接,通过开源的精神和形式,真正的把产业、教学和科研连接在一起,形成一个正向的循环,而不是把高校作为企业研发人力的补充。开源是精神文化,也是形式和平台,让我们一起利用好当前的这个机遇,共同获得成功。

在 openEuler 开源社区的运营实践中,我们针对普通开发者的运营工作更多的是依靠商业牵引,所以在华为的工作体系中有商业体系对开源社区项目的商业拓展进行支持,这是大多数公司对于开源项目发展给予不了的支持,所以 openEuler 的商业拓展结果强于高校开发者生态的发展速度。这对高校的开发者也是一种牵引,希望商业上的成功能够吸引高校的老师和学生投入到这个领域,但是这种变化的速度是比较缓慢的。如果我们希望社区真正意义上的成功,需要给开源社区一个充分的成长空间。之前我有运营过国内的 Docker 社区,而后被 Kubernetes 社区超越。从它诞生到极盛花了一年半的时间,这是至今为止开源社区成长速度最快的。当然这里有 Docker 技术和产品本身的特性,而且当处在 IaaS 发展尽头如何向 PaaS 转身,加上 Solomon 、Brandon 等一众人物的加持,才有了容器技术发展的今天,也才有而后 Kubernetes 出现一统江湖,当然 CNCF、OCI 等一众基金会的成立也是为了削弱 Docker 的发展。从这里我们看到,一个开源项目的成功也离不开“天时”、“地利” 和 “人和” 三点。我从腾讯回到华为参与 openEuler 开源项目的运营也正是看到 openEuler 在当时是具有这三点的。

何为 “天时” ?这几年正直中美贸易战愈演愈烈之时,华为遭受各种方向的制裁,从国家政策到公司内外都看到我们在基础软件领域的薄弱,无法支撑自主的发展。这时不管是政府的政策还是公司内的战略都会向基础软件倾斜,才会有华为持续的大规模投资支撑 openEuler 操作系统发展。没有这些战略资源的支持,openEuler 是不可能发展到今天的程度。这些也是商业运营能够快速发展的根本原因。加入 openEuler 社区的 300 多家企业也是看到了这种大势,加入了也不会损失什么,这个车不可能不搭。

何为 “地利” ?这 2 年 openEuler 并没有走国际社区的运作路线看,因为疫情出国是有些麻烦的。所以我们把优势的人力和优势的资源都集中在国内,利用华为已有的商业渠道网络、校园合作网络去发展社区的商业合作伙伴,发展高校师生参与到社区。虽然对比 CentOS 、Debian 和 Ubuntu 在时间上 openEuler 已经落后很多,但是在国内这个有限的地利范围内,我们集中优势努力的去弥补时间上差距。在有限的地利空间内,在战略资源优势集中的情况下,我们可以创造局部的优势,成为成功者。

何为 “人和” ?在运作 openEuler 操作系统的最初,华为就坚持一个商业策略,华为自己不做 openEuler 的商业发行版,这是和国内其它操作系统商业发行版厂商合作的基础。因为华为一直坚守这个承诺,所以在 openEuler 社区才建立起最核心的一圈伙伴和开发者。这也是社区发展的基石,大家以 openEuler 作为上游开源发行版,建立起一个可以循环的商业场景。没有这些人坚守在社区,也没有机会扩大发展。

如果我们坚持运营一个开源社区,顺应 “天时、地利、人和” 之势才有获得成功的可能,另一个方面要给开源社区一个时间,万物发展都有它顺应的规律。之前我谈到 Docker 社区的发展需要了一年半时间,openEuler 从各方面来讲绝对没有当时 Docker 优势,所以经过两年我们也不能讲自己是成功的开源社区,所以也是希望在座的各位能真心的支持 openEuler 开源社区,希望媒体给社区、给开源一些空间,避免过度的宣传造成 “捧杀” 。

说到开源和社区,现在我经常被问到如何建立一个社区,如何运作一个社区。尤其是一些原先和开源搭不上边的机构和组织。尤其是现在搞个社区经常是一个机构牵头,然后说我成立某某社区,然后挂靠在一些机构和学会,然后就利用各种行政手段让一些头部的公司来加入。前面这个阶段操作的如火纯青,因为以前搞各种协会套路都很熟悉了。而后就会问一个问题,我怎么运营这个社区,怎么搞开源,面对这种机构的教了我其实内心是很无语的。

首先当我强调社区属于所有参与的人,不属于某个人、某个机构或者建立的人时,我们遇到第一个麻烦的问题。那么开源社区属于谁呢,当然如果从法律角度来说,还有签署 CLA 的各种问题。但是核心的来讲,社区是属于所有参与者的。这个问题其实不光是外部交流起来困难,在华为内部也是如此。我们要清楚的意识到参与开源社区的所有人都是平等的,虽然有些人在社区里面有些 Title ,但是都不代表他们具有权力,这些 Title 代表了他们服务社区的义务。最近有个 Rust 基金会 Moderation Team 辞职的消息,可以看到国外成熟社区的运作模式,任何一个 Team 都是有自己的职责和工作,Team 之间是相互制衡的。那么一个主管机构建立了一个社区,然后听到说这个社区应该是属于所有人的,大家可以想象交流时的场景了。

其次开源社区是一定要有开源项目的,没有开源项目大家就没有交流的标的物了。大家都没有共同感兴趣的话题,这社区还聚体在一起做什么呢?当然也可以像我们可以搞一个云原生喝酒社区。那么有多少开源项目能够建立起一个社区呢?我随手写几行代码开源就能搞一个社区么,这明显是不可能的。这里涉及到如何设计一个开源项目,这是个技术问题,也是产品问题。之前我有一些演讲谈到开源项目本身当作是一个产品来设计,今天可能没有更多的机会去讲细节,希望下次能有机会来交流。

最终,我们要讲为什么要运营一个开源社区。从华为的角度运作 openEuler 操作系统是有明确的商业诉求,就是为了华为的鲲鹏服务器建设一个具有完整生态的操作系统,保证鲲鹏服务器的使用是有操作系统的支持。但是很多政府机构,行业机构建立开源社区是为什么?我其实并不是很能理解。但是我最担心的是,将来你要建设一个社区的时候,还需与去一些政府部门的批准或者在政府部门的领导下。像现在开发一个游戏现在还需与申请版号,你将来搞个社区可能还需要找什么部门去备案,只有市场化的充分竞争才能激起更多的创新

Contributor License Agreement 浅析

什么是CLA,CLA的主要作用

在开源项目中通常存在三个角色围绕在整个项目的生命周期,在他们之间使用不同的协议约束之间的关系。

  • 所有者 开源项目所有者的角色比较复杂,有可能是一个独立开发者个体,也可能是多个开发者组成的小团体或是一家商业公司。他们共同的特点是对这个开源项目具有控制权,拥有代码写入的权限和修改许可证的权利。
  • 贡献者 是指所有者之外的向开源项目贡献代码的开发者。有些开发者向开源项目贡献代码是出于个人意愿或者兴趣,我们可以称呼他们为独立贡献者,这些具有贡献精神的独立开发者是值得大家敬佩的,也是各种开源项目去努力吸引的;也有很多开发者是受雇于公司为开源项目贡献代码,大多数情况是因为工作中使用了某些开源项目,出于工作的需要贡献代码进行 Bug 的修复和新增功能,也有一些公司是有全职的开源开发者,专职在项目中贡献代码,这是一份让人非常羡慕的工作。
  • 用户 开源项目的用户是非常复杂的角色。用户可能是指使用在其它开源项目中使用这个开源项目的开发者,或是在商业项目开发中使用这个开源项目的开发者,也有可能是指使用这个开源项目开发的软件的用户,角色的切换随着场景在变化。

Open Source License ,在中文中我们通常讲为开源许可证,是约束开源项目和用户之间的行为。开发者、用户或者是下游开源或商业项目是都有可能受开源项目的许可证约束,而且许可证的种类繁多,内容纷繁复杂,如果稍有不慎就会陷入法律纠纷的麻烦中。所以在目前开源合规方面的很多都是针对许可证合规的研究。

CLA 是 Contributor License Agreement 的缩写,一般翻译为贡献者许可协议,开发者向开源项目贡献的时候通常被要求需要签署 CLA 协议(或类似协议)。CLA 是约束开源项目和贡献者之间的关系,通常是要求贡献者在代码和专利做出声明或者承诺。CLA 的协议内容一般都不长,通常包含两个部分:

<1> 代码相关部分

◆ 签署 CLA 是要求贡献者声明对贡献内容(不仅限于代码,文档等其它内容一样有效)拥有所有权,或者是贡献者得到了相关的授权可以贡献这些内容。

◆ 贡献者卷提交的内容是在该开源项目选定的开源协议下进行,贡献的内容也遵循该项目的开源协议。

<2> 专利相关部分

◆ 签署 CLA 是要求贡献者声明如果贡献中包含了专利,该贡献者拥有该专利的所有权,或者得到相应的授权可以贡献该专利。

◆ 签署 CLA 等于贡献者授权开源项目以及开源项目的用户能够使用这个专利

CLA 对于开源项目的贡献者和用户也是一种保护,能够帮助开源项目避免不必要的诉讼和骚扰。

  • 贡献者签署 CLA 后是对贡献者的一种保护,签署 CLA 并不能改变捐献的代码和专利的所有权,只是授权的一种行为。
  • 因为开源项目使用了 CLA ,每一个贡献都在 CLA 的保护下,在出现侵权的诉讼时,用户或开源项目可以引用 CLA 作为自己免责的证据。

所以,针对对 CLA 进行一个简要的总结:

  • Contributor License Agreement 是一个轻量级的许可协议,签署人是代码(包含文档等其它内容)和专利的拥有者(或是被授权贡献),授权这些贡献在项目的开源许可证下进行再分发。
CLA 和 DCO 之间的区别

DCO 的全称是 Developer Certificate of Origin ,是贡献者声明贡献内容所有权的轻量级协议,这里可以把 DCO 看做是更轻量级的 CLA 。CLA 和 DCO 的区别:

  • CLA 签署一般是在贡献前签署,签署一次后后续贡献就不用再签署;DCO 是需要在每次提交代码时签署。如果使用 git 作为版本管理工具,在签署时添加 -s 参数可自动完成签署,签署后会在 Git Message 的尾部添加 Signed-off-by: Random J Developer <random@developer.example.org> 的内容,姓名和密码来自于 Git 的 Config 文件。
  • CLA 通常包括一个管理系统,主要是为签署 CLA 的企业管理向开源项目贡献的员工。在管理系统中通常是通过贡献人的邮件地址或者 ID (版本管理服务的 ID,类似 Github.com ) 识别是否企业员工,通过集成到 PR (Pull Request) 来控制代码合入;企业员工更换工作内容或者离职后,企业可以通过管理系统取消其代表企业的贡献权限。openEuler 操作系统开源社区采用的 CLA 系统就是社区根据实际情况自研的,可以在 https://github.com/opensourceways/app-cla-server 获取到代码。

CLA 的签署过程可以看做是显示签署,CLA 的内容可以进行修改,通常大型企业主导的开源项目会使用 CLA 的模式,这样更容易地控制法律文本内容,降低诉讼产生的风险;目前 DCO 的内容主要是来自 https://developercertificate.org 中,在 Github 中使用 DCO 的应用检查是否含有 Signed-off-by 时默认认可 DCO 的内容,是隐式签署,企业也无法控制 DCO 的文本内容。

开源社区的一些正面和负面的看法

目前 Google 、Microsoft 、华为等大型企业的开源项目都使用了 CLA ,减少了针对开源项目的诉讼风险,利于开源项目的发展。但是社区对 CLA 也存在一些负面的看法:

  • 签署 CLA 等于放弃了一些法律权利,但是羞涩的法律文本对于开发者来说都是不友好的,即使认真地阅读了 CLA 内容,也很难确定到底是要放弃什么样的权利。很多开发者在第一次贡献前,就可能因为要签署 CLA 而放弃了。
  • 还有一些开发者认为 CLA 更多是为企业贡献者服务,对于个人开发者并不友好,并没有考虑到他们的感受和贡献的意愿;甚至有一些开发者认为这些签署 CLA 的项目并不是把开发者放到第一位考虑,而是先努力降低自己的风险。
  • 最近几年几个著名的开源项目更改 License 协议,也带来了开发者对签署 CLA 的抱怨。有很多开发者认为开源项目没有权利更改 License 协议,或者是滥用了签署 CLA 赋予的权利。

总之,对于开源项目的所有者或背后实际控制的公司,都倾向于使用 CLA 的方式代替 DCO 来获取贡献者的授权,相信未来越来越多的开发者在参与开源社区贡献时,需要签署CLA。

附录

• DCO 的文本内容:

◆ Developer Certificate of Origin Version 1.1

◆ Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

◆ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

◆ Developer’s Certificate of Origin 1.1

◆ By making a contribution to this project, I certify that:

◆ (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

◆ (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

◆ (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

◆ (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

开源社区运营指标的设计探索

前言
开源社区的运营过程,是扩大开源项目用户群体和开发者群体的过程。如何确定开发者群体的变化、如何确定贡献者转化比率是我们一直希望从数字化运营中获取的关键的信息。本文根据 openEuler 运营的实战经验,设计了对于开源社区贡献者的分层定义,希望通过数据维度为社区的健康状况提供一个新的维度可供观测。
介绍 – 漏斗模型

运营视角通常依据对开源项目的贡献程度,对代码托管平台 ( github.com 或 gitee.com )在项目上留下数字足迹的开发者进行划分,对不同的开发者实施不同的运营策略。由于操作系统开源社区的特殊性,在 openEuler 项目的实践过程中,发现从 openEuler 官网的开发者、操作系统下载安装的开发者、日常进行软件包更新的开发者在以上操作过程中不需要账号,无法进行身份的确认造成无法进行追踪,在运营过程中针对这部分开发者都只进行数据统计。所以 openEuler 社区的开发者目前限定指在代码托管平台和 openEuler 代码仓库进行过交互的开发者,即已经进入代码仓库触达的开发者。

实际运营过程中,openEuler 社区将开发者分为三个层级:

  1. 代码贡献者(D2):狭义贡献者,合入了 PR(Pull Request) 的开发者
  2. 贡献者 (D1):  广义贡献者,合入 PR(Pull Request)、提交 Issue 或者评论 issue 或者PR 的开发者
  3. 开发者 (D0):  触达贡献者,合入 PR(Pull Request)、提交 Issue 或者评论 issue 或者PR ,以及针对代码仓库进行过 Star、Watch、或 Fork 的开发者

根据以上分类,三个层级的开发者从 D0 到 D2 之间形成了包含关系,因此形成了漏斗模型

展现 – 直观

在运营后台为了更好的展现不同层级开发者的转换以及活跃情况等,可以参考如下展示方式:

  • 标准漏斗图实现,展示每层开发者之间的转化率
  • 按照时间分布展示时间序列上每个层级的开发者活跃人数
  • 按照组织分布展示每个组织投入的人数

 image

组织

应用 – 面向开发者运营

在社区中每个参与的开发者都是活生生的个体而不是平台或者 KPI 中的一个冰冷的数字,有一些开源社区运营的同学痴迷数字化的运营,忽略了开发者的个性。每个开发者都是运营人员的客户,需要用服务的心态去对待每个开发者的诉求,面向开发者运营而不是 KPI 运营。

根据漏斗模型建议采取差别的运营策略:

  1. 代码贡献者(D2):关注开发者的社区成长路径和职业路径,培养成为项目的 Maintainer 或 Evangelist – 培养开发者对社区的忠诚度
  2. 贡献者 (D1):  关注开发者对项目功能的诉求,协助开发者将项目运用在实际生产中;解决开发者在项目技术路线和使用过程中和社区的沟通 – 提升开发者对社区的信任度
  3. 开发者 (D0):  属于项目的关注者,运营重点在于将项目的技术特点、落地案例等关键信息对 D0 开发者进行传播,吸引其对项目进行深度试用 – 抓住开发者对社区的关注度

同时也可以根据漏斗模型的数据结合其它运营数据观察到社区的变化

  1. 开发者在开源项目中参与周期的变化,开源项目的开发者并不是稳定的,更像是“铁打的营盘流水的兵”- 新贡献者从何而来、核心贡献者流失何方,更是运营者对社区状况的变化
  2. 观察社区深层次的文化和利益冲突是否会导致开源社区内的角色发生变化,何种特质的开发者更容易成长为社区的中坚力量 – 关键开发者的识别,是运营者提升运营效率的关键
总结

开源社区的运营需要完整的数据支持,如何在大量数据面前梳理出开发者这个关键模型,提升运营效率是 openEuler 一直在深入探索的。然而任何模型都是要符合开源项目本身的技术特点和生命周期,希望此模型对其它开源项目的运营有一定的参考意义。

注:
  1. D0D1D2 为简写,全称应为:Developer Level ZeroDevelop Level OneDeveloper Level Two