点击收听本期“大咖访谈”播客，与大咖面对面：
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 的模式展开讨论，独特保护开源雨林的内容。
欢送关注“开源雨林”公众号，获取最新、最全的音讯。