衡量开源社区的健康状况是一个日益重要的话题。从开源社区形成的那一刻起，研究人员、维护人员和组织机构就试图了解社区是否健康以及是什么使其健康。
“如果你不衡量它，你就无法改进它”
—彼得·德鲁克
开源软件社区健康分析 (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 条评论