衡量开源社区的健康状况是一个日益重要的话题。从开源社区形成的那一刻起，研究人员、维护人员和组织都在试图了解社区是否健康以及是什么使其健康。
“如果你不衡量它，你就无法改进它”
—彼得·德鲁克
开源软件社区健康分析 (CHAOSS) 项目 (CHAOSS) 项目 提供了一种理解社区健康的正式方法。该项目于 2017 年启动，将四个利益相关者（开源社区、学术界、组织和工具制造商）聚集在 Linux 基金会的保护伞下。GrimoireLab 是本文的重点，是 CHAOSS 的共同创始项目之一。
在攻读博士学位期间，我参与开源已超过 14 年，并在研究组织参与开源的同时帮助启动了 CHAOSS 项目。获得博士学位后，我加入了 Bitergia，这是一家通过贡献其开源工具集 GrimoireLab 而共同创立 CHAOSS 的工具制造商。在我的新工作中，我学到了一些见解，我认为这些见解与任何想要开发用于分析开源项目的工具的人都相关。GrimoireLab 有一个有趣的故事，因为它包含了 英雄之旅的所有要素，我将在三幕中分享，并分享一路上学到的一些教训。
第一幕：出发
英雄之旅的第一幕描述了尚未成为英雄的人及其环境，并介绍了冒险的召唤。
GrimoireLab 起源于 16 年前的学术界，当时西班牙胡安卡洛斯国王大学的 LibreSoft 团队 构建了用于分析软件开发项目的工具。为了科学严谨性和允许其工作的可重复性，所有软件均以开源许可证发布。
在与组织合作分析他们的软件开发项目并与该领域的专家验证工具的过程中，GrimoireLab 的第一个工具迭代受到了组织的极大兴趣。分析软件项目的商业价值显而易见，Bitergia 成立旨在提供软件开发分析，提升开源 GrimoireLab 及其工具集的价值。
简而言之，GrimoireLab 诞生于分析和理解开源项目和社区的愿望。冒险的召唤来自承诺宝藏的组织。当 Bitergia 将 GrimoireLab 从舒适的学术环境带入未知的商业世界时，GrimoireLab 跨越了英雄之旅的门槛。
第二幕：启蒙
英雄之旅的第二幕介绍了考验、盟友和敌人，英雄通过克服一个又一个挑战来成长。英雄接近最深处的洞穴，迎接最终的挑战，甚至可能死去并重生。这就是 GrimoireLab 的命运。
GrimoireLab 从 16 年的开源项目分析中学到的教训为 GrimoireLab 后来的设计奠定了基础。并非所有学到的教训都容易分享，有些仍然带有失败的臭味。
选择数据库技术
今天的 GrimoireLab 的前身是使用关系数据库构建的，用于存储和检索开源社区数据。为什么要选择关系数据库？也许大学专注于关系数据库的教学。也许在关系数据库上构建应用程序是时代精神。我不知道这是一个有意的决定，还是只是碰巧这样，但它存在问题。
一个主要问题是关系模式，它只允许预定的数据并对其强制执行规则。不同的数据源，如邮件列表存档、Git 日志历史记录或问题跟踪器 API，具有不同的数据点，这些数据点对于收集和分析很有意义。
第二个问题是一些数据字段可以跨数据源映射和共享（例如，日期、作者），而另一些数据字段是唯一的，需要调整关系数据模式（例如，提交哈希），这反过来又需要更改与数据库交互的数据收集和数据分析组件。此外，开源协作平台不断发展并更改其数据 API，这需要更改数据库模式。
因此，GrimoireLab 不得不重新设计其工具以放弃关系数据库及其缺点，这些缺点阻碍了开源社区分析。在英雄之旅中，最初使用关系数据库构建的 GrimoireLab 工具未能通过考验，不得不死去。从地狱，一个新的 GrimoireLab 平台设计重生了。
在设计当前的 GrimoireLab 平台时，工程师选择了 Elasticsearch 作为数据库。GrimoireLab 现在将 JSON 文件加载到 Elasticsearch 中，并从这个灵活的数据存储中查询数据。JSON 文件对于收集社区数据的不同数据源来说可以是唯一的，这允许灵活地添加其他数据源并提供不同的数据。
选择 Elasticsearch 的一个令人信服的原因是其数据可视化平台 Kibana，这使得 GrimoireLab 工程师可以专注于数据并重用用于可视化数据的代码。
经验教训：使用可以处理数据更改的灵活数据库模式。
管理社区成员身份和隶属关系
GrimoireLab 面临的挑战之一是开源社区使用各种不同的协作平台。GitHub 和 GitLab 是流行的平台，它们托管源代码存储库、问题跟踪器和相关的工具，这些工具简化了协作软件开发。电子邮件列表、即时消息和论坛是用于通信和协作的平台。
当我们想要分析开源社区健康状况时，我们对所有这些平台中的社区互动感兴趣。为了全面了解社区，我们希望集成来自这些不同数据源的数据以进行分析。
集成来自多个数据源的数据的一个挑战是建立贡献者的身份。社区成员在为不同的社区做出贡献时可能会使用不同的别名或电子邮件地址。例如，我曾使用我的个人、大学和工作电子邮件地址来写邮件列表，并且我曾以“Georg Link”、“Georg J.P. Link”、“G. Link”和“GeorgLink”的身份做出贡献。这可能不是出于自愿，因为当社区成员首选的用户名不可用时，他们可能不得不选择不同的用户名。但是，为了全面了解社区成员在开源社区中的贡献，有必要将所有这些不同的身份组合成一个。
相关的挑战是建立社区成员的隶属关系。在今天的生态系统中，许多对开源社区的贡献都是代表组织或雇主做出的。公司越来越依赖开源软件并为其做出贡献。分析开源社区健康状况的一个关键组成部分是了解哪些组织通过其员工的参与间接参与其中。有时，社区成员的隶属关系显而易见，例如当他们使用带有组织域的工作电子邮件时。有时，此信息无法直接从数据源获得，因此必须手动输入。
GrimoireLab 在 SortingHat 中找到盟友后克服了这些挑战，SortingHat 可以识别人员及其隶属关系。作为 GrimoireLab 的身份提供者，SortingHat 使用有关做出贡献的人员的信息丰富了收集到的数据。
经验教训：管理人员的身份和隶属关系是在开源中进行高质量分析的关键要素。
可视化社区健康数据
在英雄之旅中，英雄可能会被诱入“捷径”，从而导致危险和挫折。这就是 GrimoireLab 硬编码可视化的案例。它的前身通过硬编码的“快速而肮脏”的可视化呈现数据。对数据结构或演示文稿的更改需要更改源代码。
选择此捷径是因为用户也是开发人员，因此他们可以根据需要调整可视化效果。但是，当 Bitergia 开始向客户提供社区健康分析时，这造成了挫折。新用户想要探索他们的数据，但无法修改源代码。
我们的英雄 GrimoireLab 在遇到一个可以使用通用数据探索和可视化工具生成可视化的盟友时，找到了摆脱困境的方法。
GrimoireLab 平台现在使用 Kibana 作为可视化的默认工具。用户可以自由查询数据并创建自定义可视化效果。这需要了解底层数据结构和含义。从工具的角度来看，数据结构的更改不需要更改通用数据探索和可视化工具。
提供通用数据探索和可视化工具的一个注意事项是用户重视快速获胜。应立即可视化数据，以便向用户至少显示社区的概览。因此，GrimoireLab Sigils 允许共享可视化效果和仪表板。
经验教训：如果数据的格式和类型可能会更改，请不要硬编码可视化效果。
向其他工具提供数据
对于拥有可靠盟友帮助解决问题的英雄来说，有些考验很简单。英雄不需要了解考验是如何克服的，也不需要觉得自己在克服考验中发挥了任何作用。但是，如果没有英雄，盟友就无法克服考验，甚至可能不知道考验。
GrimoireLab 用户对他们想要查看的数据以及他们想要查看数据的方式有不同的偏好。有些人可能很高兴查询数据库，有些人可能很高兴快速浏览仪表板，有些人可能很高兴在通用工具中以可视化方式探索数据，有些人可能只能通过报告或来自他人的公告访问数据。
后一组可以使用数据快照。但是，与公司股价一样，社区健康指标也会发生变化。因此，用户可能希望在其网站或其他位置包含“实时”指标和可视化效果，因此 GrimoireLab 为不同的用户类型提供了两种选择。
GrimoireLab 中的第一个选项是使用 Kibana 使用 HTML 的内联框架嵌入可视化效果和仪表板。用户在 Kibana 中设计可视化效果并嵌入可视化效果，该可视化效果从 Kibana 加载最新信息。这需要 Kibana 可公开访问。此选项适用于需要快速共享社区健康指标但不希望花费精力自定义可视化效果的用户。
经验教训：提供一种轻松共享“实时”指标的方法。
第二个选项是供用户通过直接查询 Elasticsearch API 来构建自定义集成。用户可以查询数据库以获取所需数据，然后构建自定义可视化效果。此选项适用于想要将其数据集成到其他平台并完全控制可视化效果和用户体验的用户。集成商可以使用 Kibana 来探索数据、形成特定查询，然后将查询从 Kibana 复制到他们自己的集成工作中。
经验教训：提供一种轻松探索数据和构建自定义查询的方法，以获取其他工具可能需要的数据。
从原始数据计算指标
随着英雄在每次考验中成长，旅程继续进行更具挑战性的考验，保持故事的吸引力。GrimoireLab 克服了收集数据、有效存储数据和可视化数据的考验。下一个考验是从原始数据中生成有意义的指标。
为了演示，让我们看一下 CHAOSS 指标。一些指标可以从直接从数据源获得的数据构建。例如，代码更改是 Git 日志中提交的计数。其他指标不是直接可用的，但首先需要对数据进行操作。例如，问题响应时间需要计算问题打开时间和首次提交响应时间之间的时间差。
我预计随着 CHAOSS 继续定义指标，它们将变得更加复杂。复杂指标可能基于其他指标。像 GrimoireLab 这样的软件开发分析工具必须能够计算这些复杂指标。
GrimoireLab 的 GrimoireELK 在对传入的原始数据进行任何处理之前先将其存储起来。然后丰富数据，并将该过程的结果作为丰富数据单独存储。然后执行研究，在其中以不同的方式组合来自不同数据源的丰富数据和原始数据，并针对特定目的进行计算。例如，GrimoireLab 的默认研究之一是识别临时贡献者、定期贡献者和核心贡献者，并能够分析这些群体的贡献。
经验教训：丰富数据可能需要多个步骤，其中简单指标用于更复杂的指标，而复杂指标由多个指标组合而成。
第三幕：回归
英雄之旅的第三幕在克服考验、获得奖励并且英雄返回家园后开始。回归可能以某种复活或重生的形式开始，以获得惊险的动作。最后，英雄获得了作为两个世界的主人自由生活的自由。GrimoireLab 重生了。从其祖先的灰烬中，学到的教训在今天我们拥有的完全复活（即重新设计）的 GrimoireLab 平台中得到实施。
GrimoireLab 以认可的形式获得了奖励。作为 Linux 基金会 CHAOSS 项目的创始项目，GrimoireLab 晋升为更大的生态系统的一部分。尽管它始于一家位于西班牙的小公司，但 GrimoireLab 现在是 Linux 基金会创建的快速增长的商业开源生态系统的一部分，该生态系统拥有 五个工作组和数十名贡献者。
从 GNU 通用公共许可证 中流出，GrimoireLab 有权选择自己的命运。最重要的是，它的用户也是如此。
2 条评论