度量分析开源社区健康度，助力企业开源生态健康发展——华为开源管理中心王晔晖

点击收听本期“大咖访谈”播客，与大咖面对面：

https://m.ximalaya.com/sound/629600790?from=pc

开源雨林：请先简单的自我介绍

大家好，我是王晔晖，来自华为 2012 实验室开源管理中心，主要负责对外开源生态评估和相应的工程落地的工作。我在 LF CHAOSS 社区担任董事的角色，同时负责社区开源社区生态评估指标及模型的建立，以及相应软件平台的构建。CHAOSS 社区从 2017 年成立到现在近 6 年的时间里，有很多国内外的教授、学者，以及欧美大厂的 OSPO 专家参与到社区建设当中，与我们共同创建了 CHAOSS 指标评估体系。另外，我还是 OSS Compass 社区 技术委员会 co-chair，开源指南针 OSS Compass 是今年 2 月份刚成立的开源社区，专注于开源社区生态评估，提供公开的 SaaS 服务，只需输入 GitHub 或 Gitee 托管平台上的仓库名称或社区名称，即可全面展示该仓库或项目的健康状态，使用简单，高效便捷。

开源雨林：关于社区的治理机制，他们是如何决策的？当前业界有哪些分类？

我们看待一个开源社区及其治理方式时，首先关注的就是社区的决策机制，也就是在社区中谁掌握了最高话语权，同时也会考虑在这样的决策机制的前提下，这个社区对于接受外部贡献的开放程度是怎样的。

业界开源社区的决策机制并不是固定的，但会有规律可循。卫 sir 翻译的《大教堂与集市》这本书中，接受外部贡献的开放程度有两个比较经典的分类：大教堂模式与集市模式。当然这是两个极端，但我们相信从大教堂到集市，或者说从相对封闭到完全开放，中间一定是有过渡阶段的。例如 Linux kernel，从决策机制角度看，它是仁慈的独裁者模式，而从接受外部贡献的开放程度看，它又是集市的类别。

开源雨林：您所经历过的开源社区中，哪一个称得上是治理得比较好的，有哪些优点和事例可以分享？

如果从决策机制以及对外开源贡献的开放程度来讲，每种类型的社区都有一些成功案例，也就是说社区的成功模式并不是千篇一律的，一定是基于他背后所处的环境、产业机构等等，决定这个社区是否能够成功。例如我刚才提到的 Linux kernel，这个社区既是一个由一个人做最高决策权的社区，同时也是愿意接受很多外部贡献的社区。

另外像最近比较火的 Rust 社区，它的决策机制是相对于仁慈的独裁者的另一个极端—— Seeking consensus（寻求共识），大家一起去追寻，最终达成共识，而不是说去否认或者由某一个人做决策。同时，Rust 社区也是一个特别 Open 的社区，不管是以组织还是个人形式，它都非常欢迎加入。

Rust 社区从决策机制角度与 Linux krnel 是完全不一样的，最终也能够成功，说明了社区一定要基于自身背景及实际情况来决定应该采用什么样的治理方式，帮助社区提升获取成功的可能性。

开源雨林：华为有哪些值得分享的开源生态建设的实践案例

华为对外开源了很多社区，其中一些社区虽然以我司主导，但最终走向还是希望和更多的厂商以及开发者共建社区，例如已经贡献给开放原子开源基金会的 OpenHarmony、openEuler，以这种方式治理社区来保证社区能够朝更加繁荣、多样性的态势发展。

从决策机制来讲，Seeking consensus（寻求共识）与仁慈的独裁者二者间会有一些中间状态。例如我刚刚提到的 OpenHarmony、openEuler，它们背后都由公司或组织来主导，我相信将这些社区捐赠给基金会是很好的决策，能够吸纳国内更多的开源组织以及个人开发者，更加 Open 的加入到由华为初始创建的社区中共同共建，最终把社区构建的更好。

这种共同共建的模式非常经典，也被一些相对比较成功的社区进行过反复验证，例如由 Google 推出的 Kubernetes（K8s）。Google 在互联网或搜索引擎界都是大厂，Google 自身对于 K8s 的运营也是比较成功的，但还是将其捐献给了 CNCF，同时非常欢迎其他公司加入到社区中来，成为社区治理委员会的一员。K8s 社区的晋升途径非常明确，且不会以身份来论，不管你是个人开发者，还是来自大厂，只要社区贡献突出（尤其是技术决策角度），都可以得到晋升。

开源雨林：作为 CHAOSS 社区唯一一位华人董事，可否分享一下：在开源治理的实践中，CHAOSS 的理念有哪些可取之处？

CHAOSS 社区对外主要提供两种产品：一个是指标体系及评估模型，另一个是 Grimoirelab 及 Augur 两个软件平台。指标体系及评估模型是通过一些开源社区或 OSPO 的真实案例生成的对于开源生态或开源项目健康维度评估的指标或者模型，颗粒度可大可小。例如 PR 是否能够及时关闭，在某一时间段新进多少开发者等等，是针对指标和模型在理论层面上的一个定义。Grimoirelab 和 Augur 这两个软件平台是用来落地指标和模型的，实时应用在自动化工具里，帮助用户了解指标和模型背后的意义，并应用到自己或自己感兴趣的社区当中。

过去几年，有很多来自不同国家、不同背景的人参与到社区中，我们通过他们的一些背景，与大家一起创新地制定了很多的指标和模型。截至目前，已经有近 100 个指标了。但在长期参与社区的过程中，我们发现原先对于指标定义的颗粒度过小，不能够具体地描述某个社区的实际场景。所以在 2021 年，华为倡议成立了指标评估模型工作组，首次提出了评估模型的概念。经过近两年的发展，CHAOSS 社区把重心转移到了评估模型工作组方向，同时在 2022 年与 Linux foundation 的其他社区联合成立了 Associate Program，希望把 OSPO 相关的社区及诉求聚合在一起，通过模型的方式把它展现出来。我们也非常真诚地希望国内的开源爱好者能够参与到 CHAOSS 社区，一起创建出更加有意义的模型和指标。

开源雨林：如何看待 KPI 开源，或者说开源社区是否需要某种指标体系？

我认为所谓的评估体系或指标，其初衷都是为了能让社区有更好的发展，CHAOSS 社区和 OSS Compass 社区的初衷亦是如此。开源社区本是一个向善的过程。我相信，这些原本没有任何问题的指标因为成了所谓的 KPI 而导致在执行过程中发生变形，是任何人都不愿意看到的事情。

当我们在构建评估体系，尤其该评估体系将应用在由企业/组织所主导的开源社区时，对方会希望能通过完善的评估体系帮助社区进行良好的运转，那么这时候就需要模型和指标来指导他们的工作。不可避免地，这些模型和指标会落在具体某个执行人身上。当模型所展现出来的结果对社区是不好的、负向的，或者跟竞品社区比，还存在一定差距时，相应的执行人/负责人可能会感到有压力，但其实评估体系是由非常完善的架构构建起来的，所谓体系，是指它能涵盖开源社区生态发展的各个维度，而每个维度都由多个模型构成，所以我们不能通过某个模型来判断社区的健康与否，每个社区在不同阶段所面临的问题以及工作重心也是不一样的，不是在任何阶段都要花费成本及精力去关注所有模型。

开源雨林：你已经在 CHAOSS 社区，且做到了社区董事，为什么还要另外做 OSS Compass 呢？

华为参与 CHAOSS 社区已经有几年了，我和几位同事在社区里获取了很多有价值的东西，得到了很多成长。同时，我们从华为角度，将一些最佳实践贡献给了 CHAOSS，彼此之间的协作是非常好的。在社区的发展过程中，我们做了很多尝试，例如在中国成立 Local Community，希望更多中国的开源爱好者加入到 CHAOSS 社区，但 CHAOSS 的语言环境是英语，存在语言障碍这种天然屏障。当大家想使用或是参与 CHAOSS 社区时，会有很多障碍。这是我们决定建立 OSS Compass 的第一个初衷。

OSS Compass 有两个类型的产品，一个是理论层面输出的指标模型的定义，另一个是 Grimoirelab 和 Augur。Grimoirelab 和 Augur 承载着指标和模型的落地作用，但它们本身都是本地环境安装的工具，若想使用这个指标或模型，必须要有自己的硬件基础设施，要懂一些基本的编程语言或开发环境构建去搭载平台，再去做数据的抓取、清理、处理，以及最终的模型。这对于不同的用户来说成本是非常高的，对于 CHAOSS 模型和指标的推广也是不利的，这也是为什么我们在 OSS Compass 社区对外输出 SaaS 服务。

OSS Compass 提供公开的 SaaS 服务，用户只需输入自己感兴趣或自己管理的开源社区的代码托管平台的 URL，就能够立刻看到该社区通过使用 CHAOSS 的指标和模型展现出来的看板形式的洞察报告，以此帮助更多人熟悉和了解 CHAOSS 的社区的指标，在国内得到更多共识。这是第二个初衷。目前，CHAOSS 社区和 OSS Compass 社区已互为伙伴成员，互相独立，但协作紧密。

开源雨林：OSS Compass 后续的发展规划是怎样的？

我们的初衷是让更多用户使用 Compass 服务帮助他们进行决策。在开源使用阶段，假设有几家类似的开源软件，在选择时应该选哪一家？是可以通过 OSS Compass 作为输入帮助他们决策的。另外，OSPO 所管辖的社区或开源软件是否是可以被信赖的？在管理过程中，治理角度、运营角度、开发角度等遇到的各种问题是否可以通过 OSS Compass 进行提前预警？

OSS Compass 所有模型的构建都具有时间趋势的作用，且可以进行一些横向比较，帮助大家看到与对比社区的差距。同时，还可以通过一些历史数据，预测出接下来可能会出现的可能性危险。

不管是 CHAOSS、OSS Compass，还是我目前在华为所从事的工作，都是与开源生态评估相关的。所以，我非常希望大家能够把对开源生态健康的想法，或是一些真实案例分享出来，不管是通过 OSS Compass 还是 CHAOSS，我们都非常欢迎。也非常感谢开源雨林能提供这样一个机会，跟大家一起交流开源生态评估方面的一些事情。

开源雨林围绕开源通识、开源使用、开源贡献三大方面构建知识体系，愿把长期积累的经验系统化分享给企业，在团队、机制、项目三方面提供合作，推动各企业更高效地使用开源、贡献开源，提升全行业开源技术与应用水平。

开源雨林的内容已开源，并托管在 https://github.com/opensource-rainforest ，欢迎通过 Pull Request 的形式贡献内容，通过 Issue 的形式展开讨论，共同维护开源雨林的内容。

欢迎关注“开源雨林”公众号，获取最新、最全的消息。