用于衡量项目健康状况的开源工具包

关于开源项目，我一直有一个挥之不去的问题：如何确定一个项目的成功/失败？“成功”或“失败”是由代码提交和直觉来决定的吗？还是有其他方法？

我想解决开源软件项目评估中的这种模糊性和基于推测的问题，但我发现关于软件分析和相关理论的文献大多来自学术界，并且侧重于诸如代码行数和每千行代码的错误数之类的事情。好消息是，过去 20 年开源项目的爆发式增长提供了大量信息，可以挖掘这些信息来帮助分析项目的健康状况。

红帽的产品产品组合都建立在开源项目之上——它们都源自一个或多个上游、基于社区的开源项目。红帽的产品经理需要对各自的上游开源项目的情况有很好的了解，以便能够基于社区的实力和项目中的协作来推动产品的持续发展。除了红帽自身的需求之外，使用成千上万个开源项目来驱动技术革命的产品和服务激增，这需要一个连贯的、可重复的和客观的工具/方法来确定项目的运行状况。

隆重推出 Prospector，这是我们在红帽内部构建的工具，旨在帮助衡量这一点，我们现在已将其贡献给 Linux 基金会，以帮助形成新的 CHAOSS 项目的基础。

在构建 Prospector 之前，我们研究了 Ohloh（现在的 Open Hub）的现有工作以及我之前引用的部分学术研究，以帮助建立我们想要衡量的一组指标。借助 Prospector，我们的目标是创建一个工具，其中包含有关项目的所有相关信息——其网站、代码存储库、错误存储库、邮件列表、IRC 频道、CVE 报告、事件博客等等。

我们希望指标基于公开可访问的数据源，没有付费墙、登录凭据要求（通用登录除外）或限制触发器。如果发生限制，则需要有一个手动的、免费的机制来获取信息。

Prospector 不是关于分析代码本身，因此存在一个刻意的设计模式，规定 Prospector 不会复制源代码存储库。

Prospector 使用 Django、Python、JavaScript 和 Postgres 构建，并托管在红帽 OpenShift 容器应用平台上，Prospector 的 1.0 版本于 2013 年在红帽内部上线。从那时起，我们不断发展 Prospector 及其数据源，并使用 JamIQ 和 Google Trends 等工具添加情感分析。

Prospector 以图形仪表板的形式呈现来自其核心数据源的所有信息。我们为代码提交、错误报告、错误修复、邮件列表参与和 IRC 频道对话设置了数据阈值。例如，以下是该工具如何查看源代码提交的。Prospector 将 35% 和 55% 设置为两个水印，以指示以下内容

• 如果一个项目的代码提交者中，具有相似电子邮件域 ID 的人数少于 35%，并且他们构成最大的域，则 Propector 将认为该项目是社区驱动的；
• 如果该数字介于 35% 和 55% 之间，则认为它是一个混合项目；并且
• 如果该数字高于 55%，则认为它是一个企业项目。

Prospector 不会对每个阈值的好坏做出价值判断。工具中的阈值用于帮助用户评估用户是否应基于更广泛的分类进行额外的分析。

这种工具的价值不在于它外出收集数据，而在于收集到的数据随后可供对项目感兴趣的人员以可能无法实现的方式进行解释。

借助 Prospector，人们可以查看项目的各种指标，然后将它们与其他项目并排比较。人们可以获得的见解类型非常有趣。我记得我做过一个比较，比较了 oVirt 项目和 Linux 内核。oVirt 项目是新的，当人们查看早期代码提交时，它是周期性的，提交在每周初缓慢，一周内逐渐增加，然后在周末趋于平静。这表明它是一个企业项目，开发人员在工作周期间很忙。当时间线延长到 12 个月以上时，每周周期变得平缓，贡献稳步上升。这是一个非常有用的指标，可以知道一个项目在最初的企业推动之后正在获得动力。这进一步肯定了社区贡献和协作的价值。

我们很高兴将 Prospector 贡献给 CHAOSS 项目，以便它可以继续发展。要了解有关 CHAOSS 以及 Prospector 将在该项目中扮演的角色的更多信息，请访问 https://chaoss.community/。