是否还记得前不久刷star被全网吐槽的开源项目，送礼物刷star，各种姿势刷star层出不穷，好好的一个开源项目玩儿成了kpi开源，为了显得社区活跃而得不偿失，显然违背了开源的初衷。那么作为开源社区我们又有哪些指标可以去探索的呢？
01 前言
开源社区的运营过程，是扩大开源项目用户群体和开发者群体的过程。如何确定开发者群体的变化、如何确定贡献者转化比率是我们一直希望从数字化运营中获取的关键的信息。本文设计了对于开源社区贡献者的分层定义，希望通过数据维度为社区的健康状况提供一个新的维度可供观测。
02 介绍 —— 漏斗模型
运营视角通常依据对开源项目的贡献程度，对代码托管平台( github.com 或 gitee.com )在项目上留下数字足迹的开发者进行划分，对不同的开发者实施不同的运营策略。由于操作系统开源社区的特殊性，在项目的实践过程中，发现从官网的开发者、操作系统下载安装的开发者、日常进行软件包更新的开发者在以上操作过程中不需要账号，无法进行身份的确认造成无法进行追踪，在运营过程中针对这部分开发者都只进行数据统计。所以社区的开发者目前限定指在代码托管平台和 代码仓库进行过交互的开发者，即已经进入代码仓库触达的开发者。
实际运营过程中，openEuler 社区将开发者分为三个层级：
01 代码贡献者（D2）
狭义贡献者，合入了 PR（Pull Request) 的开发者
02 贡献者 （D1）
广义贡献者，合入 PR（Pull Request)、提交 Issue 或者评论 issue 或者PR 的开发者
03 开发者 （D0）
触达贡献者，合入 PR（Pull Request)、提交 Issue 或者评论 issue 或者PR ，以及针对代码仓库进行过 Star、Watch、或 Fork 的开发者
根据以上分类，三个层级的开发者从 D0 到 D2 之间形成了包含关系，因此形成了漏斗模型。
03 展现 —— 直观
在运营后台为了更好的展现不同层级开发者的转换以及活跃情况等，可以参考如下展示方式：
1）标准漏斗图实现，展示每层开发者之间的转化率
2）按照时间分布展示时间序列上每个层级的开发者活跃人数
3）按照组织分布展示每个组织投入的人数
04 应用 —— 面向开发者运营
在社区中每个参与的开发者都是活生生的个体而不是平台或者 KPI 中的一个冰冷的数字，有一些开源社区运营的同学痴迷数字化的运营，忽略了开发者的个性。每个开发者都是运营人员的客户，需要用服务的心态去对待每个开发者的诉求，面向开发者运营而不是 KPI 运营。
根据漏斗模型建议采取差别的运营策略:
01 代码贡献者（D2）
关注开发者的社区成长路径和职业路径，培养成为项目的 Maintainer 或 Evangelist - 培养开发者对社区的忠诚度
02 贡献者 （D1）
关注开发者对项目功能的诉求，协助开发者将项目运用在实际生产中；解决开发者在项目技术路线和使用过程中和社区的沟通 - 提升开发者对社区的信任度
03 开发者 （D0）
属于项目的关注者，运营重点在于将项目的技术特点、落地案例等关键信息对 D0 开发者进行传播，吸引其对项目进行深度试用 - 抓住开发者对社区的关注度
同时也可以根据漏斗模型的数据结合其它运营数据观察到社区的变化：
开发者在开源项目中参与周期的变化，开源项目的开发者并不是稳定的，更像是“铁打的营盘流水的兵”- 新贡献者从何而来、核心贡献者流失何方，更是运营者对社区状况的变化
观察社区深层次的文化和利益冲突是否会导致开源社区内的角色发生变化，何种特质的开发者更容易成长为社区的中坚力量 - 关键开发者的识别，是运营者提升运营效率的关键。
05 总结
开源社区的运营需要完整的数据支持，如何在大量数据面前梳理出开发者这个关键模型，提升运营效率是大家一直在深入探索的。然而任何模型都是要符合开源项目本身的技术特点和生命周期，希望此模型对其它开源项目的运营有一定的参考意义。
对于开源社区指标我们一直保留敬畏之心和开放的态度不断探索，也不断跟上游CHAOSS社区探讨和挖掘新的指标和计算方式，欢迎大家一起探讨。
注：D0、D1、D2 为简写，全称应为：Developer Level Zero、Develop Level One、Developer Level Two
