衡量开源软件使用情况的 8 个想法

我们这些支持开源项目社区的人经常被问及使用情况指标——非常频繁。 这些指标的目标通常是证明软件的重要性，其依据是用户群和知名度。 我们通常想知道：有多少人使用该软件，有多少安装量，以及有多少人的生活受到了影响。

长话短说：我们无法直接回答这些问题。

如果您希望得到明确的解决方案，我很抱歉让您失望了。 没有人能完美回答关于使用情况指标的问题。 至少，没有精确的答案。

好消息是，存在一些近似值和替代指标，可以满足您对软件使用情况的求知欲，至少可以部分满足。 本文探讨了这些替代方案，包括它们的优点和缺点。

下载

当您访问提供软件的网站时，通常可以看到该软件被下载了多少次。 我想到的一个例子是 Firefox，它过去有一个下载计数器。 这是一个令人印象深刻的数字，给人一种 Firefox 是一个流行的浏览器的印象——有一段时间确实如此。

但是，个人行为会直接影响这个数字的准确性。 例如，当一个人定期擦除他们的机器时，每次重建都会产生单独的下载。 为了解决这个现实，需要有一种方法从这个数字中减去几十个（可能数百个）下载，因为只有那一个人。

下载不仅会高估使用量，还会低估使用量。 例如，系统管理员可能会将新版本的 Firefox 下载一次到闪存驱动器，然后将其安装在数百台设备上。

下载指标很容易收集，因为您可以在服务器上记录每个下载请求。 问题是您不知道软件下载后会发生什么。 该人是否能够按照预期使用该软件？ 还是该人遇到了问题并放弃了该软件？

对于开源项目，您可以考虑各种下载指标，例如从以下位置下载的二进制文件数量

• 项目网站
• 包管理器，如 npm、PyPi 和 Maven
• 代码存储库，如 GitHub、GitLab 和 Gitee

您可能还对源代码的下载感兴趣，因为下游项目很可能会使用这种格式（另请阅读如何衡量开源项目的影响力）。 相关的下载指标包括

• 从代码存储库（如 GitHub、GitLab 和 Gitee）克隆（源代码下载）的数量
• 从网站下载的存档（tar、zip）的数量
• 通过包管理器（如 npm、PyPi 和 Maven）下载的源代码数量

源代码的下载指标比二进制文件下载的可靠性更低（尽管没有研究证明这一点）。 试想一下，一位开发人员想要使用最新版本的源代码，并已将他们的构建管道配置为始终为每个构建克隆您的存储库。 现在想象一下，一个自动化构建过程失败并重试构建，不断克隆您的存储库。 您还可以想象一种情况，即指标低于预期——例如，存储库被缓存在某个地方，并且下载由缓存提供服务。

[ 相关阅读 在开源社区中追踪的 5 个指标 ]

总之，下载指标是检测趋势和提供当前使用情况背景信息的好方法。 我们无法具体定义下载如何转化为使用。 但我们可以说，下载量的增加表明了潜在用户的增加。 例如，如果您宣传您的软件并看到在宣传活动期间下载量更高，那么可以合理地假设该广告促使更多人下载该软件。 下载的来源和元数据也可以为使用模式提供额外的背景信息。 您的软件的哪些版本仍在被使用？ 哪些操作系统或特定于语言的版本更受欢迎？ 这有助于社区优先考虑要支持和测试的平台。

问题

作为一个开源项目，您可能有一个问题跟踪器。 当有人提出问题时，两个常见的目的是报告错误或请求功能。 问题作者可能已经使用了您的软件。 作为用户，他们会发现一个错误或确定需要一个新功能。

显然，大多数用户不会采取额外的步骤来提交问题。 问题作者是忠实的用户，我们感谢他们。 此外，通过提出问题，他们已经成为非代码贡献者。 他们可能会成为代码贡献者。 一条经验法则是，对于每 10,000 名用户，您可能会得到 100 名提出问题的人和 1 名贡献代码的人。 根据用户的类型，这些比例可能会有所不同。

关于指标，您可以将问题作者的数量作为使用量的下限估计。 相关指标可以包括

• 问题作者的数量
• 活跃问题作者的数量（在过去 6 个月内提出了一个问题）
• 也贡献代码的问题作者的数量
• 提出的问题的数量
• 编写的问题评论的数量

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

许多开源项目都有用户邮件列表、论坛，并在问答网站（如 Stack Overflow）上存在。 与问题作者类似，在那里发帖的人可以被认为是用户冰山一角。 关于社区在这些邮件列表、论坛和问答网站中的活跃程度的指标也可以用作用户群增加或减少的代理。 相关指标可以侧重于这些地方的活动，包括

• 用户邮件列表订阅者的数量
• 论坛用户的数量
• 提出的问题的数量
• 提供的答案的数量
• 创建的消息的数量

自动回呼功能

为了获得准确的用户数量，一个想法是让您的软件在使用时报告回来。

这可能会让人感到毛骨悚然。 想象一下，一位系统管理员的防火墙报告了与您的服务器的意外连接。 不仅报告可能永远无法到达您（它被阻止了），而且您的软件可能会被禁止将来使用。

拥有自动回呼功能的负责任的方式是提供可选服务以查找更新并让用户知道使用最新版本。 另一个可选功能可以侧重于使用遥测技术，您可以询问用户您的软件是否可以匿名报告软件的使用方式。 当以周到的方式实施时，这种方法可以让用户通过他们的使用方式来帮助改进软件。 用户可能会有这样的观点：“我通常不允许共享这种使用信息，但对于某些软件，我确实允许，因为我希望开发人员从长远来看会为我做得更好。”

Star 和 Fork

Star 和 Fork 是 GitHub、GitLab 和 Gitee 等社交编码平台上的功能。 这些平台上的用户可以 Star 一个项目。 他们为什么要 Star 项目？ GitHub 的文档解释说：“您可以 Star 存储库和主题，以跟踪您觉得有趣的项目并在您的新闻提要中发现相关内容。” Star 相当于添加书签，也提供了一种向存储库维护者表示感谢的方式。 Star 已被用作衡量项目受欢迎程度的指标。 当一个项目有一个吸引大量关注的重要公告时，Star 数量往往会增加。 Star 指标并不表明软件的使用情况。

这些社交编码平台上的 Fork 是存储库的克隆。 非维护者可以在他们的 Fork 中进行更改，并通过拉取请求提交以供审查。 Fork 更能反映社区规模，而不是 Star。 开发人员也可能会 Fork 一个项目，以保存一个他们即使在原始存储库消失后也可以访问的副本。 由于 Fork 在贡献工作流程中的使用，该指标是开发人员社区的良好指标。 Fork 通常不表示非开发人员的使用情况，因为非开发人员通常不创建 Fork。

社交媒体

社交媒体平台为具有共同兴趣的人们提供了聚集地，包括 Facebook、Instagram、LinkedIn、Reddit、Twitter 等。 通过使用社交媒体策略，开源项目可以通过在这些平台上设置各自的聚集地来吸引对他们的项目感兴趣和有亲和力的人。 通过这些社交媒体渠道，开源项目可以分享新闻和更新，并突出贡献者和用户。 它们也可以用来结识那些原本不会与您的项目互动的人。

我们不愿提出以下指标，因为它们与您的软件的实际使用情况没有明确的联系，并且通常需要分析正面、负面和中性的情绪。 人们可能会因为许多不同的原因对您的项目感到兴奋，并且想要关注它而无需实际使用它。 但是，与已经讨论过的其他指标一样，表明您能够在社交媒体空间中吸引人群是整体上对您的项目感兴趣的指标。 不同社交媒体平台的指标可能包括

• 关注者或订阅者的数量
• 消息的数量
• 活跃消息作者的数量
• 点赞、分享、反应和其他互动的数量

网站分析和文档

网站流量也是一个有用的指标。这个指标受你的推广和营销活动的影响比用户数量更大。 然而，我们有一个王牌：我们的用户文档、教程、手册和 API 文档。我们可以看到我们网站上哪些主题引起了关注，包括文档。文档的访问者数量可能会随着软件独立用户数量的增加而增加。 因此，我们可以通过网站的访问者来检测对该项目的一般兴趣，更具体地说，可以通过观察文档的访问者来观察用户趋势。 指标可能包括

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

活动

如果你围绕你的项目举办活动，则可以使用活动指标。 这是建立社区的好方法。有多少人提交摘要在你的活动上发言？ 有多少人参加你的活动？ 这对于面对面和虚拟活动都很有趣。 当然，你如何宣传你的活动会强烈影响有多少人参加。 此外，你可以将你的活动与一个更大的活动共同举办，人们无论如何都会旅行，因此他们就在城里，可以轻松参加你的活动。 只要你使用一致的活动策略，你就可以认为演讲者提交数量和与会者注册数量的上升表明受欢迎程度和用户群的增加。

你不需要举办自己的活动来收集有见地的指标。 如果你在开源活动中举办关于你的项目的演讲，你可以衡量有多少人参加了你专注于你的项目的会议。 在像 FOSDEM 这样的活动中，一些演讲专门关注开源项目的更新或公告，房间里挤满了人（就像 FOSDEM 上的几乎所有会议一样）。

你可以考虑的指标

• 以你的项目为中心的活动的与会者人数
• 提交到以你的项目为中心的活动的演讲数量
• 以你的项目为中心的演讲的与会者人数

关于近似开源软件使用情况的结论

正如我们所说明的，有许多指标可以表明你的软件的使用趋势，但所有指标都不是完美的。 在大多数情况下，这些指标可能受到个人行为、系统设计和噪音的严重影响。 因此，考虑到每个指标的相对不确定性，我们建议你永远不要单独使用任何这些指标。 但是，如果你从各种来源收集一组指标，你应该能够检测到行为和使用方面的趋势。 如果你有办法比较多个具有共性的开源项目的同一组指标——例如类似的功能、强大的相互依赖性、托管在同一基金会下以及其他特征——你可以提高你对行为基线的认识。

请注意，在本概述中，我们还选择突出显示评估直接使用情况的指标。 由于大多数软件都依赖于各种其他软件包，如果我们不提及使用情况和行为也可能受到作为依赖链的一部分的间接使用的严重影响，那将是一种疏忽。 因此，我们建议将上游和下游依赖项的计数作为分析中的另一层上下文。

最后，作为数据和指标的掌握者，我们鼓励你认识到你对利益相关者拥有的权力和责任。 你发布的任何指标都有可能影响行为。 最佳实践是始终分享你的背景信息——基础、来源、估计和其他关键的背景信息——这将有助于其他人解释你的结果。

感谢 CHAOSS 社区在 2022 年于爱尔兰都柏林举行的 CHAOSScon EU 上的富有洞察力的对话，这激发了这篇博客文章的想法，并感谢审查并帮助改进本文的 CHAOSS 社区成员。