Linux基金会企业开源指南系列之四 - 度量开源项目的成功要素（下）

01

—

衡量的具体项

对于开源项目的跟踪指标和衡量成功的要素有很多种。项目的健康度虽然并非是唯一跟踪的，但是确实的非常重要。那么问题来了，围绕开源项目有着太多纬度的数据了，该如何下手？任何能够获取数据的地方，都可以收集并跟踪。同样每个公司所跟踪的指标，以及他们对数据的处理，都是大不相同的，这很大程度上取决于公司自身的项目目标，以及该公司在市场和开源社区中面临的独特挑战。

“我们收集我们可以获取到的数据，因为数据就在那里，但是我们并不拘泥于数据，我们要依靠这些确保努力是朝着目标前进的。”

– Gil Yehuda, 开源高级总监，来自 Oath (Yahoo + AOL)

对于某些社区经理来讲，（他们可能是比较疯狂的，或者完全迷信技术的自动化的），会跟踪所有能跟踪的内容。但是对于某些公司来讲，尤其是规模较大的，有太多的项目了，根本不可能做到跟踪所有的事情，而且也无法从中得出任何有意义的结果。那么究竟应该跟踪开源项目的成功要素哪些指标了呢？

本指南列出了我们认为是跟踪开源项目的最佳衡量元素。当然这些仅仅是为稍后的更为严格和细致的分析的初步阶段。请谨记，这些小的提示旨在帮助项目办公室的负责人，使得ta可以确保多个项目的健康度不止于跑偏。具体的项目本身要有自身独特的健康度衡量。GitHub 开源指南系列之衡量标注 有着针对项目维护者需要关注的内容有相当的介绍。

在 GitHub 上使用一些免费的或者是开源工具，亦或者是一些商业的工具，可以轻而易举的获得这些数字。定期的(月度、季度或年度)去复盘这些数字，对于每个独立的项目的进度基准都是有益处的，更进一步将所有的项目的数据整合起来，对于贵司来说就有了一个全局的数字。使用它们来向管理层做报告，以及帮助开发者改进项目。

“我们试着定期查看项目质量的好坏，并建议他们应该将哪些内容做得更好。但是我们不直接参与管理。我们只是给他们提供数据，然后在我们有能力或有必要的时候稍微推动一下他们的工作。”

- Christine Abernathy, Facebook 开源开发者布道师

贡献者数量（还有公司内外部的比例）

项目在起步阶段时，主要的贡献者均是来自公司内部的开发者，随着时间的推移和项目的进展，就慢慢的会有一些外部的开发者参与进来，他们或使用代码又或者是fork，都无关紧要，重要的是他们开始参与了。项目处于最佳健康度的情形是：能够一直保持一个多样化的社区，而且获得了该领域生态的其它公司的很大一部分贡献量。（要知道，Kubernetes 项目就有着 1000多家公司的参与贡献。）

项目之所以能够持续的吸引外部的贡献者，往往是在维护开源项目的工作上做对了，如在欢迎新的贡献者方面、来自社区的反馈的响应等等。（注意：这些技巧仍然适用于还没有发展外部贡献者的社区！）

PR 的提交数量、Open状态的数量、以及已经接受的数量(以及保持Open的时间长短)

当一名贡献者发现了 Bug ，或者提出了某个新的功能，而且他们自己可以有打补丁的能力，或者干脆自己就实现了。那么他们就会提交PR。跟踪这些 PR 的数量，以及针对 PR的讨论、合并都是很有意义的，而最终项目有多少贵司外部贡献者的代码提交量则会表明该项目是否有专断的倾向，这也会影响到未来的外部开发者的态度。

PR 保持 Open 状态时间的长短，在一定程度上意味着项目的维护者对于外部贡献者的欢迎度以及接纳程度。如果发生了 PR 长时间没有应答的情况，那么就可能将某些潜在的贡献者的好的想法拒之千里。

“当 Facebook 新开源了一个优秀项目的时候，也常常会在一段时间内没有任何 PR ，这完全属于正常现象，而且经常是2~3 个月都没有任何的 PR，它确实有点长，但是值得等待。”

– Christine Abernathy，Facebook 开源开发者布道师

要牢记这些指标项是和项目的规模有着很大关联的。 比如，Facebook 对于较小的项目就会尝试将 PR 的 Open 数量保持在10个以下。 但是对于一些较大的项目想要保持这样一个恒定的数量是颇为难的，因为维护者的数量往往和社区的成员贡献是不成正比的，审核这些 PR 是要花费很多时间的，越是大型的项目就有可能发生 PR 打开很久的情况。

Facebook 的开源项目办公室会经常性的检查这样的状态，会挑选出拥有打开 PR 数量最多的前5个项目，开源项目办公室人员会查找问题所在，并尝试和项目的维护者进行对话。开源项目办公室人员会问维护人员一些问题，从而帮助项目找到问题所在，而且会尽可能的帮助解决问题。在大多数情况下，这会是一个让维护人员重新聚焦注意力到问题所在的时候，也提醒维护者们保持社区的活跃度！但是偶尔也会从数字中挖出令人意想不到的问题。比如，若存在大量的打开的 PR 或者 PR 均是很旧的，那么说明维护该项目的人仅有那么一、两位，这也就是说项目开始亮红灯了，要想办法了，项目有死掉的危险。

Issue 的提交数量（还有其处理的周期）

有些用户没有时间来提交 PR、或者是没有权限提交、亦或者是技能不足，但是他们可能会将使用项目所遇到的问题、或者是新的功能描述，整理为 issue 提交到项目中来。那么 issue 的数量，以及这些问题是如何被解决的，它可以表明使用项目的用户的水平，以及项目维护者对问题相应的积极程度。

该数量当然会根据实际的情形有着不同的依赖。举例来说，对于那些仅使用 GitHub 平台来追踪 bug的项目来说，相比于那些提交新的功能需求的 issue，处理一些程序bug的issue是很短暂的。最主要的衡量就是 issue的处理周期，或延迟，或及时，无它。

每位贡献者的提交数 （公司内外部的均要统计）

公司外部的提交数和总数是有关联的，这是衡量项目是否通过开放获得创新的重要指标，所谓的开放也就是指从公司外部获得新的创意。一个健康的项目，随着时间的推移，外部的贡献者数量一般是稳步上升的。衡量每位贡献者的提交数可以有效的帮助贵司评估项目是否吸引了新的开发者，以及这些新的贡献者继续参与的可能性。

外部采用者的数量

每个开源项目都应该找到一条路径，去跟踪哪些公司或组织采用贵司的开源项目作为生产环境在使用，比如说在项目中专门列出一个 ADOPTERS.md 文件，又或者是干脆在 README.md 里，让社区成员去填写，要对这个数据保持密切关注，并确保它所列出的内容是随着时间的增长而增加的。如果发生了相反的事情，也就是说这个列表停止或者下下降，那么这也就意味着项目正在变得过时，是该考虑如何让项目优雅的关闭的时候了。

项目创建数量以及参与贡献的项目数量 (开源办公室范围内)

要去跟踪贵司所发布的每一个项目，而且还要跟踪贵司的开发者自身的贡献活跃度。在制定开源战略的流程中，你应该已经对所开源的项目是处于贵司业务的重要程度时心知肚明的，而且对此有着专用的预算来达成所有的目的。贵司想要从开源成功不仅仅是要跟踪你自身所参与的项目，而且要以全局的视野来看待整个开源的活动。 这其中不仅包括产品开发、业务运营所依赖的项目健康程度，而且还要确保贵司所使用和发布的开源许可协议都是合规的。

02

—

其他可以跟着的指标

以上即是一些最为基本的项目量化指标，它们对于开源项目的起步能够起到一定的作用，但是对于一名优秀的、成功的开源项目办公室的经理来讲，还有很多很重要的细节需要深入的挖掘。

以下所列出的，是开源项目办公室应该去，而且也是能够做到的，可以跟踪的指标，这具体要根据实际的情况而定。但是，一定要记住，数量本身不是目标 —— 它只是持续追踪它们的过程和寻找数据模型的过程，其可以反映出项目和进程哪里需要改进。请为每个项目进行衡量，并要去尝试对这些项目所获得的数据进行横向的对比，从而获得对于项目的产出与结果更为全面的洞见。

流行程度和普及水平

• 项目官方站点的访问量
• GitHub/GitLab 关注者的数量
• 社交媒体帐户（如Twitter，Facebook或LinkedIn）上的粉丝数量
• 新闻剪辑和媒体报道
• 组织和举办线下会议的次数（例如，通过meetup.com网站）

影响力

• 在战略项目中担任维护人员/领导者角色的员工数量
• 项目贡献者的多样性
• 补丁被拒绝的原因
• 采用的情况
• 下载量
• fork 创建的数量
• 外部公司的贡献量
• 采用的阶段 (PoC 或实际生产环境的部署具体量)
• 商业依赖性（产品）的数量和质量 —— 这可以通过查看为贵项目做贡献的公司或关注新闻、媒体来追踪

项目成本

• 成员：工程师、公共关系与市场营销、法律工作人员
• 技术设施和技术支撑
• 工具
• 研讨会参与和差旅
• 培训
• 会员资格与赞助事宜

作为一个组织来评估开源项目办公室、具体项目、以及贡献程度等，都要去选择针对它们具体的有意义的一面来进行。其中最为重要的莫过于谨记：设置战略、不断调整目标，并坚定不移的去实现它。至于如何去追踪、衡量，其实是自然而然的事情。

鸣谢

参与本指南的作者有:

• Christine Abernathy, Facebook 开源开发者布道师。
• Chris Aniszczyk, 云原生计算基金会 COO (原Twitter的开源主管）
• Joe Beda, 曾是Google发起Kubernetes项目的工程师之一，Heptio 的CTO 兼联合创始人
• Sarah Novotny, Kubernetes 社区经理，来自 Google
• Gil Yehuda,开源高级总监，来自 Oath (Yahoo + AOL)

这些资源是与TODO（公开对话，开放式开发）小组 – Linux基金会的专业开源程序网络小组合作创建的。 特别感谢那些贡献自己的时间和知识来制作这些综合指南的开源项目经理。 参与的公司包括Autodesk，Comcast，Dropbox，Facebook，Google，Intel，Microsoft，Netflix，Oath（Yahoo + AOL），Red Hat，Salesforce和Samsung。 要了解更多信息，请访问 todogroup.org。我们邀请您在GitHub上下载、传播，如果可以请积极的参与这些指南。