我们这些支持开源项目社区的人经常被问到很多有关使用指标的问题。这些指标通常是为了通过用户量和知名度来衡量软件的重要性。我们一般都想知道有多少人使用该软件，有多少次安装，以及有多少人生活接触过它。

但简而言之，我们尚无法直接回答上述问题。

如果你想要寻找一个明确的解决方案，那很抱歉要让你失望了。有关使用指标的问题，没有人有完美的答案，至少没有准确的答案。

好消息是，有一些近似的和替代指标至少能够部分地满足你对软件使用情况了解的渴求。本文探讨了这些替代方案以及它们的优点和缺点。

下载量

当你浏览提供软件的网站时，你通常可以看到软件的下载次数。映入我脑海的一个例子是 Firefox ，它曾经有一个下载计数器。Firefox 的下载量是一个印象深刻的数字，给人的印象是 Firefox 是一个流行的浏览器，在一段时间内确实如此。

然而，个人行为会直接影响这一数字的准确性。举例而言，当一个人定期重置他们的设备时，每一次重建都会引发一次独立的下载。考虑到这一现实，需要设计一种方法从下载量中去除几十次（或许是几百次）的下载次数，因为那是一个人。

下载量不仅会高估使用量，还会低估使用量。例如，一个系统管理员可能会下载一个新版本的 Firefox 一次并将其拷贝到 U 盘上，然后安装到数百台设备上。

下载量指标是易于收集的，你可以在服务器上记录每一个下载请求。问题在于你不知道在这些软件下载以后会发生什么。下载它的人是否如预期的那样使用软件，还是遇到了问题而放弃了它。

对于开源项目而言，你可以考虑各种下载量指标，比如来自以下途径的下载指标：

• 项目官网
• 包管理器，比如 npm、PyPi 和 Maven
• 代码仓库，如 GitHub、GitLab、Gitee 等

你可能还对源代码的下载量感兴趣，因为下游项目更可能使用源代码形式（参见 ​​《如何衡量你的开源项目的影响》​​一文）。相应的下载指标包括：

• 从代码仓库克隆的数量，比如 GitHub、GitLab 和 Gitee
• 从官网下载的归档文件（tar、zip）的数量
• 通过像 npm、PyPi 和 Maven 这样的包管理器下载的源代码数量

源代码的下载指标比二进制代码的下载指标更不可靠（虽然尚无相关研究表明如此）。试想一下，一名开发人员想要你的最新版本的源代码，并将他们的构建管道配置为每次构建都克隆你的仓库。再想象一下，一个自动构建过程失败了，它试图重新构建而不断地克隆你的版本库。你还可以考虑这样一个下载量低于预期的场景——源代码仓库在某些地方缓存了，下载来源是由这些缓存所提供的。

​​相关阅读：跟踪你的开源社区的 5 个指标​​

总而言之，下载量指标是用于提供当前使用情况和探测趋势的很好的指征。我们无法明确地定义一次下载是如何转化为使用的。不过我们可以认为增加的下载量是更多潜在用户的标志。举例而言，如果你为你的软件做了广告并在活动期间得到了更高的下载量，可以合理地假定广告推动了更多人下载该软件。下载行为的来源与元数据还可以提供额外的与使用行为相关的内容。你的软件的哪些版本仍在使用中？什么操作系统或者特定语言的版本更加流行？这有助于社区决定将哪个平台的软件作为支持与测试的优先选项。

议题

作为一个开源项目，你可能有一个议题追踪器。当某个人提出一个议题时一般有两个目标，报告一个漏洞或者请求增加一项功能。提议者很可能已经使用过你的软件了。作为一名用户，他可能发现了一个漏洞或者发现了对一个新功能的需求。

很明显，大多数用户不会执行额外的步骤来提交议题。提议者是我们的忠实用户，我们对他们表示感谢。此外，通过提出议题，他们已经成为了非代码贡献者，他们也有希望成为代码贡献者。经验法则是大约每 10000 名用户中，可能有 100 名提议者，以及 1 名代码贡献者。当然取决于用户类型，上述比例可能有出入。

回到指标问题，你可以将提议者数量作为评估使用量的下界。相关的指标包括：

• 提议者数量
• 活跃提议者的数量（在过去 6 个月内提出议题的提议者）
• 同时有代码贡献的提议者的数量
• 尚未解决的议题的数量
• 对议题发布的评论数量

邮件列表、论坛和问答网站

很多开源项目都拥有用户邮件列表、论坛，并且出现在类似 Stack Overflow 的问答网站上。与提问者一样，在这些地方发帖的人可被视作用户的冰山一角。与邮件列表、论坛和问答网站上的社区活跃程度相关的指标也可用于反映用户数量的上升或下降。相关指标可以集中于以下地方的活动，包括：

• 用户邮件列表的订阅量
• 论坛用户的数量
• 问题的数量
• 答案的数量
• 发布信息的数量

上报功能

为了获得精确的用户数量，一个方案是让软件在使用时上报信息。

这是令人毛骨悚然的。想象一下，系统管理员的防火墙报告了一个非预期的到你的服务器的网络连接，你不仅无法再收到软件报告（被防火墙拦截了），恐怕连你的软件也可能在未来被禁止使用。

负责任的设置上报功能的方式为设置一项可选服务来检查更新并让用户知道使用最新版本。另一项可选功能可以集中在使用遥测上，你可以通过该功能询问用户是否允许匿名上报软件使用情况。如果经过深思熟虑的实施，这种方式可以允许用户通过他们使用软件的方式帮助优化软件。用户可以持有这样的意见：我一般不允许这种使用信息的分享；但对于一些软件，因为希望开发人员在长期内将软件优化得更好，我愿意这样做。

星标与复刻

星标与复刻是如 GitHub、GitLab、Gitee 等社交化编程平台的功能。这些平台上的用户可以给一个项目加星标。为什么他们要给项目加星标呢？GitHub 的文档作出了解释：你可以给一个仓库和主题加星标，以跟踪感兴趣的项目，和在你的新闻订阅中发现相关的内容。给一个项目加星标与将其加入书签的效果一样，并且还提供了一种向项目仓库的维护者展示赞赏的方式。星标的数量已经成为了项目流行程度的标志。当一个项目发布重大公告并获得相当的关注时，项目的星标数量会呈上升趋势。星标的数量指标并不反映软件的使用量。

在社交化编程平台上的复刻Fork是将项目仓库复制一份在自己名下。仓库的非维护者可以在他们自己的克隆仓库中做修改，并将修改通过拉取请求pull request（PR）的方式提交审核。复刻比星标更能反映软件社区的规模。开发者也可能为了保存一份代码副本而克隆一个项目，以便在原始仓库消失后他们仍能访问代码。因为复刻功能在代码贡献工作流中的应用，复刻量是衡量开发社区的良好指标。复刻量通常也不反映非开发人员的使用，因为非开发人员一般不创建复刻。

社交媒体

包括 Facebook、Instagram、LinkIn、Reddit、Twtter 等社交媒体平台提供了相同兴趣的人们聚集的平台。采用社交媒体策略，开源项目可以通过在平台上设置相应的聚集空间来吸引对项目感兴趣的人们。通过这些社交媒体途径，开源项目可以分享项目新闻、更新，指出贡献者和用户。这些社交媒体途径还可以用于认识那些本不会通过其他途径与项目互动的人。

我在犹豫是否建议关注以下指标，因为它与软件的真实使用量没有清晰的联系，并通常需要分析其中的积极、消极和中性的情绪。人们可能因为很多不同的原因对你的项目感到激动而关注它，但并不实际使用它。然而与之前已经讨论过的指标一样，能够在社交媒体上吸收人群本就是项目受关注的整体指标。不同社交媒体平台的指标包括：

• 关注者与订阅者的数量
• 消息的数量
• 活跃的消息作者的数量
• 喜欢、分享、回复以及其他交互的数量

网站分析与文档

网站流量也是一个有用的指标。这一指标主要受到你的服务范围以及市场营销活动影响，而不是用户量。然而，我们还有一张王牌：我们的用户文档、教程、手册以及 API 文档。我们可以发现我们的网站以及文档中的什么主题更引人注意。文档的访问者数量应当大致随着软件的使用者数量增长而增长。因此我们可以通过网站的访问量探知对项目的普遍兴趣，并进一步通过观察文档的访问者来观察用户风向。这些指标包括：

• 网站访问者数量
• 文档访问者的数量
• 访问者在你的网站与文档上所花的时间

活动

活动的指标可以在你主持与项目相关的活动时使用。这是建立社区的很好的方式。有多少人提交摘要想要在你的活动中发言？有多少人出席你的活动？不论是在线下活动还是线上活动这可能都很有趣。当然，你如何推广你的活动在很大程度上决定有多少人到场。同时你可以将自己的活动与人们出行的大型活动放在一起以方便人们参加你的活动。只要你使用一贯的活动策略，你可以通过演讲者提交的材料与参会者注册的增加来表征软件受欢迎程度与用户群的增加。

你并不需要举办你自己的活动来收集有用的指标。如果你在开源活动中主持有关你项目的讨论，你可以衡量有多少人出席主要关注你的项目的会议。像 ​​FOSDEM​​ 这样的活动，一些讨论特别聚焦于开源项目的更新与发布，会议室中都挤满了人（像 FOSDEM 的所有会议一样）。

你可以考虑如下指标:

• 以你的项目为中心的活动的出席人数
• 提交到以你的项目为中心的活动的演讲数量
• 以你的项目为中心的演讲的出席人数

关于估算开源软件使用的结论

正如我们已经如上展现的，有很多指标可以反映软件使用的趋势，没有一个指标是完美的。在大多数情况下，这些指标可能被个人行为、系统设计和噪音所严重影响。因此，考虑到每一个指标的相对不确定性，我们建议你不要孤立地使用任何一个指标。但是如果你从不同的来源收集了一系列的指标，你应当能够探测到用户行为与软件使用的趋势。如果你有办法在多个具有共性的开源项目中比较同一组指标，例如类似的功能、强大的相互依赖性、在同一基础设施上托管，以及其他特征，你就可以提升你对用户行为基线的感知。

需要注意的是，在这篇概述中，我们选择突出能够评估直接使用情况的指标。而大多数软件都依赖于其他各种软件包，如果我们不提及作为软件依赖链的一部分而被间接使用的严重影响，这就是我们的疏忽。因此，我们建议将上下游依赖的合计数量作为你的分析中的另一层内容。

最后，作为数据与指标的使用者，我们鼓励你认识到你的利益相关方的权利与责任。你发布的任何指标都有可能影响用户行为。最好的做法是经常一同分享你的背景信息——基础、来源、估算方法和其他关键上下文信息，这有助于其他人解释你的结果。

感谢 ​​CHAOSS​​ 社区在爱尔兰都柏林举行的 CHAOSScon EU 2022 上的富有洞察力的对话，上述对话激发这篇博文的想法。我们还要感谢 CHAOSS 社区的成员审阅并帮助优化本文。