翻译：适兕 | 编辑：王琳娜

特别声明

本文拥有创作共用授权之相同方式共享授权4.0版国际许可协议（Creative Commons Attribution ShareAlike 4.0 International License）授权许可。 开源之道独立精心翻译分享，欢迎同道中人商讨。

引言

开放源代码办公室经理必须为自己所付出的努力进行投资回报率的计算。本篇指南旨在概述企业经理们评估他们开源项目、办公室、以及贡献的常见做法。

学习如何来衡量各项指标，如何定义开源项目的成功，以及如何充分利用各种信息来改进开源项目办公室的目标，说明有效性、并获得更多的支持。

01—如何定义成功

明智的公司对于参与开源开发的价值是有深刻理解的，当然基于此，还会设定关于如何利用和参与开源的目标。但是，天下没有”包治百病的良药”，对于开源项目来说每个项目还有一些细微的差别。设置目标、跟踪各种指标，这些都会随着你投入开源的程度不同而不同：如雇佣的开发人员、通过开放的创新带来新的想法和技术，进而达到快速上市、低成本的开发、或是其它原因。

对于贵司独一无二的战略来说，设置目标是首要的事情，而且要谨记：去寻求高管团队的认同，以确保开源战略与整体业务战略保持一致。也就是说，无论其行业、产品或业务战略有何不同，开源项目负责人都有一些标准化的方法来评估项目的成功。它们通常有：

开发者在外部开源项目中的参与度和影响力

贵司在开源社区的声誉

贵司在雇佣开发者和留住人才方面的能力评估

贵司自个的开源项目健康度，重大业务相关项目的开发者参与度

管理开源许可证合规性的成效如何

02—为何设置目标

在开始正式的开源项目跟踪之前，或者说在更为深入的探讨之前，让我们花上短暂的几分钟时间来讨论下如何设置一个可实现的目标，而且要时刻的对它进行评估。

没有人愿意运作一个失败的开源项目，所以要时刻关注它的发展状态，以便于进行及时的调整。所以首要的就是跟踪项目的进展，这样可以确保贵司所投资的开源项目（无论是内部还是外部）保持健康发展，如社区的回应、公司的形象、以及是否有助于满足开源项目的其它更为广泛的目标。经常性的、有规律的跟踪也有助于校准开源项目的基准，有异常情况可以及时获得警告，以便在项目偏离既定方向、违反法律合规要求的时候，甚至在必要的时候，可以优雅的关闭项目。

事无巨细（而且也是战略性的）的衡量同样可以在为高层的管理者做报告时，提供良好的素材，定期报告有助于确保项目与自身目标和整体业务战略保持一致，并能够帮助项目经理获得行政领导对项目的内部支持（特别是在项目达到甚至超过目标的时候！）

例如，Facebook的开源项目办公室会定期在内部公布其开源项目的月度状况，并向管理层发送执行报告。

“作报告这件事对于提高知名度是个不错的方法。尽管说Facebook是对开源有着蛮重视的程度的（作为一家公司来讲），换个思路，即使这样，在公司的内部去推广项目，并展现出该有的价值，总归是件值得的事情。” 

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

定期公开项目结果还有助于提高潜在的合作伙伴、用户和开发人员对于贵组织所开展的开源活动有一个充分的认识。

在开源社区中获取关于项目结果的评价——好的、坏的和难听的——可增强项目的透明度、问责制和可信性。

Facebook和Google在开源项目展示有着非常良好的标杆效果。

03—如何设置目标

接下来，我们就为自己的开源项目设置一个远大的目标，除此之外，还要考虑下如何实现这个目标，而且要有具体的时间规划。首先，在开始的时候就建立绩效基准是百利而无一害的，使用恰当的工具来收集数据，而且要确保数据的来源是纯粹和干净的，当然格式上是你（以及你的上司）可以理解的。很多的公司都为他们的开源项目创建了各种指标的可视化展示，以便能够统一的追踪所有数据并提供项目快照，从而达到快速评估进程的目的。(更多内容可以参考《开源项目管理工具指南》)

接下来，开源项目办公室的经理、相关者就要坐下来一起商量（以Facebook为例，这些相关的人包括工程领导、项目维护者等），然后一起决定在往后的3~6个月（小步快跑、实际见效）要做的事情。在这个周期结束后，就要回顾所完成的实际情况，并根据此完成情况来调整下一阶段的目标和策略。

“我倾向于根据社区的痛点来寻找衡量指标，并尝试改良这些指标以提升社区的质量。” 

– Sarah Novotny, Kubernetes 社区经理，来自 Google

除了绩效基准指标之外，在为项目设定目标时，还需要考虑以下几点：

战略调整: 所设定的目标是否与核心业务战略、产品目标以及其他内部业务目标保持一致？

控制级别: 项目经理是否可以直接控制结果？或是项目经理、工程人员、法律人员或其他职能人员共同控制？设定控制范围内可实现的目标。

项目的差异化: 不同的项目应该根据自己的实际情况而设定相应的目标，这要具体的取决于项目目的、社区组成、技术栈等等因素。举例来说，Facebook 一度意识到 JavaScript 的项目会经常性的频繁的创建分支，在多次的重复之后，事后获得的教训就是这些分支的指标毫无意义，对于衡量项目的健康度没有顶点帮助。

数量和质量: 并非所有目标都应与数字挂钩。改进项目流程的质量是非常重要的，甚至要远远比数量更为重要。因为有时候会发现，仅仅是达到了所规定的数字目标，并不就意味着项目质量没有问题。也有的时候，一个小的项目，数量上并没有什么让人惹眼的增长，但是因为有过硬的质量而充满光明的前途。

“你拥有半打数量的贡献者，以及一打不是维护者的活跃人士，但是拥有健康的讨论、PR也会得到及时的处理、重要的功能特性有着完整而清晰的表达。这本身就表示这是一个正在成长的健康的社区，但是，它可能并没有值得炫耀的star数量和fork的次数，但是那样又如何，这一切并不能阻止这是一个有着良好商机的优秀项目。所以我更加的倾向于考虑社区如何与其自身互动、如何发展和指导新的领导者、以及如何解决到现有的难题。”

 –  Sarah Novotny, Kubernetes 社区经理，来自 Google

04—目标实例

一旦谈到开源项目成功的量化问题，那么人们都会将注意力聚焦在项目的指标上，诸如：贡献者的数量、代码行数、项目数量等等。本章节的内容就是事无巨细的来评估项目的健康度的。但是，这里要提醒大家的是，数字并不能代表一切，尽管它很重要，除此之外还有很多其他的重要方法可以用来评估项目的成功与否的。不过，我们这里只谈能够实际量化的。

“我认为使用指标作为一种报告趋势的方法是好的。但把指标作为衡量成功的唯一方式将会给您带来麻烦。”

 –Joe Beda , 曾是 Google 发起 Kubernetes 项目的工程师之一，Heptio 的 CTO 兼联合创始人

Beda 所作出的解释是，Kubernetes 是 GitHub 上发展速度最快的开源项目之一，在过去三年里吸引了来自1,181家公司的2,760位开发人员，有超过 80,000 次提交。但项目伊始就以技术和技术的使用作为衡量成功的标准，并非是依靠“所谓的开源量化指标”。

以下我们要介绍的是作为开源项目办公室常见的目标，以及项目经理为了追踪项目的整体进程所采取的办法。其中有一些目标本身无法评估，但这些目标与流程改进、效率提升以及质量改善息息相关。其他目标可以通过调查或其他评估方法来衡量，如定期、积极地征求口头或书面的反馈意见。（请积极的与你的团队进行有效沟通！）

目标1：确保高效且合法合规的开源代码采用

这部分通常是一个企业开始参与开源的第一步，当他们意识到使用大量的开源软件，无论是其基础设施，还是在他们的产品和服务中，又或者是二者都存在。那么开源项目办公室就会帮助整个公司制定中心化的策略，以及围绕使用开源、追踪使用的具体情况的决策制定，并确保组织不会违反其在各种开源许可下的法律义务。开源项目办公室还可以跟踪它们如何帮助开发人员解决他们可能遇到的任何法律问题。

衡量这个首要目标的一些最常见方法是致力于确保政策和进程按计划的方式运行，同时确保组织活动保持合法合规：

目前项目采用的开源代码是多少？

这些所采用的代码是否被很好的跟踪？

是否确保使用开源代码的政策已经准确的传递到公司基层，最重要的开发人员是有了解的

引入代码的流程和工具清楚明确，且开发人员遵行这些流程与工具。

哪些产品和服务使用了第三方代码？

您有多少合规操作？这些问题的解决速度有多快？ (贵司是否有合规的项目流程？请参阅我们来自《开源合规项目》的法律资源以获取有关此主题的更多信息。

目标 2： 提高开发者的生产力

一旦开始跟踪和管理开源项目的状况，首要确保的事情就是能够让开发者以最轻松的形式参与到开源项目中来。假如说工程师们想要为项目提交一个漏洞修复或是增加一个新的特性，整个过程就像是剥洋葱般的繁琐，那么这就是在彼此浪费生命，可能更糟糕的是这个新提交的功能恰是贵司所需要的。

开发者通过直接为上游提交贡献，可以节省大量的时间，如果是选择自行切出分支去维护的话，时间稍久就会产生大量的技术债务。

“我们是经常将自家的团队比作是为那些正在参与马拉松长跑比赛的运动员提供补给，尽管我们可能本身不是参赛者。我们会鼓励开发人员按照我们既定的方向前进，因为我们知道，从长远的角度来看，对于实现目标是有益处的。我们尽最大可能的为他们提供服务，而不是去为他们增加障碍。”

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

与此目标相关的指标，致力于让开发者们对开源项目的贡献能够以最轻松和舒适的方式进行，当然同时也要增加一些贵司向上游贡献的代码总量。当消除了那些让开发效率低下的障碍时，进而使审批流程清晰快捷，那么我们就可以期待更多的贡献和效率。

以下所列的可跟踪的清单供参考：

作为战略性团队识别外部项目的提交数量

做出贡献的开发者数量。如果可以的话，收集到他们是谁？以及为那个具体的项目做了贡献？

以公司雇员身份（在职和实习）出现的项目维护者数量

项目贡献健康度

贵司在开源社区中的声望分析

开发人员是否了解贡献政策？（贡献政策已经制定？）

开发者是否遵行贡献流程？（即开发者必须签署 CLA 之类。）

是否有开发者寻求帮助，社区现有成员是否能够及时的提供帮助？

软件版本发布之间的时间差 —— 是延期还是提前发布？

向上游做贡献的工程成本和维护分支代码的工程成本之间的差异对比(开源之道注：这条太关键了，可以有效的防止搭便车者。)

目标 3： 创建开源项目，并使其野蛮成长

此目标对于很多大型、倡导工程师文化的公司来说是他们开源项目办公室的首要目标，比如Facebook，Google、微软、Twitter、等等不一而足。他们均已创建了数以百计（甚至上千）个开源项目，目标就是解决较难的技术问题。目的就是吸引外部的用户和贡献者，使得能够为项目带来全新的想法、进而更快的推动技术的发展。（这个观点来自加州大学伯克利分校的 Henry Chesbrough 教授，可以在其著名的开放式创新一书中找到详细诠释。）

“ 你究竟是如何让这个世界上最聪明的人在贵司上班的？ 道理很简单，将你的项目开源，他们就会来做贡献的！”

– Chris Aniszczyk,云原生计算基金会COO (原Twitter的开源主管）

正如上面提到，这个目标是收到各位重视的，所以跟踪它的数据点来衡量项目健康度是蛮多的，以下是一些建议性的参考：

是否有创建新项目时明确的政策，以及开发人员是否了解这些政策？

是否有创建新项目时，有可以使用的清晰且简捷的流程，以及开发人员是否遵行这些流程？

外部人员为贵司的项目做贡献时有多便捷？

项目维护人员是愿意接纳他人，并乐意提供帮助的

项目得到很好的维护和支持

代码拥有良好的文档

如果参与贡献，有着清晰明了的说明

其他定量指标，如新贡献者的数量、创建问题的数量、解决问题所需时间等（请参阅下一章节），以下列出的是较直观的：

项目所获得的外部贡献比重，以及社区的多样性

贵司项目的受欢迎程度：GitHub关注数、社交媒体粉丝数等等

采用贵项目的成型产品或部署了的用户数量

贵司所发起项目的数量、范围、质量等，比如说，移动端、数字基础设施等等相关的项目描述

项目以及其相关产品的表现

发布的时间间隔

就Facebook的开源来说，我们大概有一半的时间是花在了决定开展更多的旗舰级项目上来着，并制定了一个较严格的流程。但是无法为大家列举出具体的数据来，它只是意味着每个开源项目的创建都要经历这个review的过程。” 

–Christine Abernathy,Facebook.

目标 4： 雇佣和留住开发者

作为一家企业来讲，不论是参与到已有的开源项目中，还是发起自身的开源的项目，均是吸引开发者的绝佳路径，而且从开源社区吸引过来的开发者可以快速的上手，只需要很小的成本就可以让他们成长。这些开发者们已经参与到贵司的项目中，那么一旦贵司招聘了他们，他们早已对相应项目的流程、工具、以及相应的技术了然于胸，（具体如何招聘开源开发者，请参阅本指南另外专门的篇幅。）

但是作为开源项目办公室的一名经理，你可能没有机会担当直接招聘开发者的角色，而且还有一种情况就是贵司参与开源的影响力是否能招聘到相应的人才也不是太明朗。Facebook 就遇到了这样的情况，Facebook 为了解决这样尴尬的局面，为了促使项目工作与招聘之间建立更为直接的联系，于是做了一个询问新员工三个基本问题的调查：

你是否对于公司的开源项目很在意？

在意的程度是如何影响你加入公司的决定的？

在开源方面的经验是否适用于现在所从事的工作？

Facebook 通过调查来”把脉“ 开源文化的健康程度，它同时说明了人们如何看待我们开源项目的整体效应，尤其是有具体的数字衡量时，情况会明朗很多。” 

–Christine Abernathy,Facebook 开源开发者布道师。

这里还有一些招聘开发者时的一些建议：

有哪些开源项目是公司员工们使用而且参与贡献的

新进的员工是如何获得公司的信息的

通过开源项目吸引来的开发者数量

已经招聘到了多少位项目维护者（或者是正在培养中)

新员工上手需要多长时间

开源开发人员如何在他们的职业生涯中大显身手

开发者的贡献被作为工作绩效的一部分来评估

开发者的贡献是被公司认可并奖励的

开发者同样在参与共享的过程中也会获得其他社区成员的帮助和支持

目标 5：推崇开源文化

开源项目该如何做才能培养出优秀的工程人才，在很大程度上取决于公司内部开源文化和开源实践的培育。事实已经证明，开源的组织是开发人员乐意工作和创新的绝佳形式，另外，作为开源项目办公室的负责人，一部分工作还要担当起开源文化的宣传者，同时还要负责监管开源协作的政策和具体实践。

对于衡量项目的有效性来讲，在组织内部如何跟踪开源文化的进展是非常重要的。以下是常见的衡量采用开源文化的方法：

管理层以及包括工程、营销和公共关系等所有部门中的个人贡献者对于开源战略与开源项目的理解和支持

在开源社区的品牌与知名度 -  它们如何看待贵组织

参与度 - 以积极的正面的方式参与到开源社区

培训和导师制 —— 要和开发者战斗在一线，改进他们的开源贡献意识以及项目本身，积极的寻找机会去做出贡献，而且要学习社区的工具和流程，一定要确保贡献者们能够获得同行和管理者的积极支持。

采用的常见的工具集合

代码的质量要过关，能够获得社区内/外部的接受

要去代表整个项目去积极的进行宣传 - 如参加一些研讨会，最好能够申请到演讲机会，要去撰写技术文章、教程等等。

赞助一些开源组织或线下的活动，如基金会、开源组织、或者是黑客松会议等。

目标 6： 使开源社区利益与产品利益保持一致

在开源项目中，社区布道虽是一个新进的岗位，但是正在变得日益流行。那么作为布道师，就会经常扮演沟通联络项目开发者和社区项目的使用者之间协调的角色 —— 不仅代表来自外部用户构建开源代码的声音，还要承担起将信息反馈给贵司产品管理团队的责任。

这是非常重要的角色，它需要确保贵司的产品和服务能够从开源社区中获益，因此，开源项目要和贵司更为广泛的业务战略和目标保持一致。这里给出几条衡量你的布道效果的指标：

有多少位参与贡献的成员是来自公司的外部？

有多少位来自公司外部的贡献者是全职做的？

有多少来自外部贡献的代码已经合并到贵司的产品中了？

从开源的贡献者中雇佣了几位？

07—衡量的具体项

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

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

      – 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 里，让社区成员去填写，要对这个数据保持密切关注，并确保它所列出的内容是随着时间的增长而增加的。如果发生了相反的事情，也就是说这个列表停止或者下下降，那么这也就意味着项目正在变得过时，是该考虑如何让项目优雅的关闭的时候了。

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

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

08—其他可以跟着的指标

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

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

流行程度和普及水平

项目官方站点的访问量

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 上下载、传播，如果可以请积极的参与这些指南。