Des leçons difficiles tirées de la mesure de la santé de la communauté avec un logiciel open source

Mesurer la santé d’une communauté open source est un sujet de plus en plus important. À partir du moment où une communauté open source se forme, les chercheurs, les responsables et les organisations essaient de comprendre si la communauté est saine et ce qui la rend saine.

« Si vous ne le mesurez pas, vous ne pouvez pas l’améliorer »
-Peter Drucker

Le projet Community Health Analytics for Open Source Software (CHAOSS) offre une approche formelle pour comprendre la santé communautaire. Le projet a démarré en 2017, réunissant quatre parties prenantes (communautés open source, universités, organisations et fabricants d’outils) sous l’égide de la Linux Foundation. GrimoireLab, au centre de cet article, est l’un des projets co-fondateurs de CHAOSS.

Je suis impliqué dans l’open source depuis plus de 14 ans et j’ai aidé à démarrer le projet CHAOSS pendant mon doctorat tout en recherchant l’engagement organisationnel dans l’open source. Après avoir obtenu mon doctorat, j’ai rejoint Bitergia, l’outilleur qui a cofondé CHAOSS en apportant son ensemble d’outils open source, GrimoireLab. Dans mon nouveau travail, j’ai appris des idées qui, selon moi, sont pertinentes pour quiconque souhaite développer des outils pour analyser des projets open source. GrimoireLab a une histoire intéressante car elle contient tous les éléments du voyage d’un héros, que je partagerai en trois actes, ainsi que certaines des leçons apprises en cours de route.

Acte 1: Départ

Le premier acte du voyage d’un héros décrit le héros pas encore et l’environnement et introduit un appel à l’aventure.

GrimoireLab a commencé dans le monde universitaire il y a 16 ans, lorsque l’équipe LibreSoft de l’Université Rey Juan Carlos en Espagne a construit des outils pour analyser les projets de développement de logiciels. Pour la rigueur scientifique et pour permettre la reproductibilité de leur travail, tous les logiciels ont été publiés sous une licence open source.

En travaillant avec des organisations pour analyser leurs projets de développement logiciel et valider les outils avec des experts du domaine, la première itération d’outils de GrimoireLab a suscité un immense intérêt de la part des organisations. La valeur commerciale de l’analyse de projets logiciels était évidente et Bitergia a été fondée pour fournir des analyses de développement logiciel, faisant progresser la valeur du GrimoireLab open source et de son ensemble d’outils.

En bref, GrimoireLab est né de la volonté d’analyser et de comprendre des projets et des communautés open source. L’appel à l’aventure est venu d’organisations qui ont promis des trésors. GrimoireLab a franchi le seuil du voyage de son héros lorsque Bitergia a amené GrimoireLab du cadre académique confortable dans le monde des affaires inexploré.

Acte 2: Initiation

Le deuxième acte du voyage d’un héros introduit des épreuves, des alliés et des ennemis, et le héros grandit de caractère en surmontant un défi après l’autre. Le héros s’approche de la grotte la plus intérieure, relève le défi ultime et peut même mourir pour renaître. Ce fut le sort de GrimoireLab.

Les leçons que GrimoireLab a tirées de 16 ans d’analyse de projet open source ont jeté les bases de la dernière conception de GrimoireLab. Toutes les leçons apprises ne sont pas faciles à partager, et certaines portent encore la puanteur de la défaite.

Choisir une technologie de base de données

Le prédécesseur du GrimoireLab d’aujourd’hui a été construit avec une base de données relationnelle pour stocker et récupérer les données de la communauté open source. Pourquoi une base de données relationnelle a-t-elle été choisie? Peut-être que les universités ont concentré leur enseignement sur des bases de données relationnelles. C’était peut-être le zeitgeist pour construire des applications sur des bases de données relationnelles. Je ne sais pas si c’était une décision délibérée, ou si c’est arrivé comme ça, mais il y avait des problèmes avec ça.

Un schéma majeur était le schéma relationnel, qui ne permet que des données prédéterminées et applique des règles. Différentes sources de données, comme les archives des listes de diffusion, l’historique des journaux Git ou les API de suivi des problèmes, ont différents points de données qui sont intéressants à collecter et à analyser.

Un deuxième problème est que certains champs de données peuvent être mappés et partagés entre les sources de données (par exemple, les dates, l’auteur), tandis que d’autres sont uniques et nécessitent des ajustements au schéma de données relationnelles (par exemple, le hachage de validation), ce qui nécessite ensuite des modifications de la des composants de collecte et d’analyse de données qui interagissent avec la base de données. De plus, les plateformes de collaboration open source évoluent constamment et modifient leur API de données, ce qui nécessite des modifications du schéma de la base de données.

Par conséquent, GrimoireLab a dû repenser ses outils pour abandonner les bases de données relationnelles et leurs lacunes, ce qui a entravé l’analyse de la communauté open source. Au cours du voyage du héros, les outils originaux de GrimoireLab construits avec une base de données relationnelle ont échoué aux essais et ont dû mourir. De la pègre, une nouvelle conception de plate-forme GrimoireLab renaît.

Lors de la conception de la plate-forme GrimoireLab actuelle, les ingénieurs ont choisi Elasticsearch comme base de données. GrimoireLab charge désormais les fichiers JSON dans Elasticsearch et interroge les données de ce magasin de données flexible. Les fichiers JSON peuvent être uniques aux différentes sources de données où les données de la communauté sont collectées, ce qui permet la flexibilité d’ajouter des sources de données supplémentaires et de rendre différentes données disponibles.

Une raison impérieuse de choisir Elasticsearch était sa plate-forme de visualisation de données, Kibana, qui permet aux ingénieurs de GrimoireLab de se concentrer sur les données et de réutiliser le code pour les visualiser.

Leçon apprise: Utilisez un schéma de base de données flexible qui peut gérer les modifications apportées aux données.

Gérer les identités et les affiliations des membres de la communauté

L’un des défis auxquels GrimoireLab a été confronté est le fait que les communautés open source utilisent une variété de plates-formes de collaboration différentes. GitHub et GitLab sont des plates-formes populaires qui hébergent des référentiels de code source, des trackers de problèmes et des outils associés qui simplifient le développement de logiciels collaboratifs. Les listes de diffusion, la messagerie instantanée et les forums sont des plateformes utilisées pour la communication et la collaboration.

Lorsque nous voulons analyser la santé de la communauté open source, nous nous intéressons aux interactions communautaires dans toutes ces plateformes. Pour avoir un aperçu complet d’une communauté, nous voulons intégrer les données de ces différentes sources de données afin de les analyser.

L’un des défis de l’intégration de données provenant de plusieurs sources de données consiste à établir l’identité des contributeurs. Les membres de la communauté peuvent utiliser différents alias ou adresses e-mail lorsqu’ils contribuent à différentes communautés. Par exemple, j’ai utilisé mes adresses e-mail personnelle, universitaire et professionnelle pour écrire sur des listes de diffusion, et j’ai contribué en tant que «Georg Link», «Georg J.P. Link», «G. Link» et «GeorgLink». Ce n’est peut-être pas par choix, car les membres de la communauté peuvent devoir sélectionner un nom d’utilisateur différent lorsque leur nom d’utilisateur préféré n’est pas disponible. Cependant, pour un aperçu complet des contributions d’un membre de la communauté dans une communauté open source, il est nécessaire de combiner toutes ces différentes identités en une seule.

Un défi connexe consiste à établir les affiliations des membres de la communauté. Dans l’écosystème d’aujourd’hui, de nombreuses contributions aux communautés open source sont faites au nom d’une organisation ou d’un employeur. Les entreprises s’appuient de plus en plus sur les logiciels open source et y contribuent. Un élément essentiel de l’analyse de la santé de la communauté open source consiste à comprendre quelles organisations sont impliquées par procuration grâce à la participation de leurs employés. Parfois, l’affiliation d’un membre de la communauté est évidente, par exemple lorsqu’il utilise son courrier électronique professionnel avec le domaine de l’organisation. D’autres fois, ces informations ne sont pas disponibles directement à partir des sources de données, elles doivent donc être saisies manuellement.

GrimoireLab a surmonté ces défis après avoir trouvé un allié dans SortingHat, qui peut identifier les personnes et leurs affiliations. En tant que fournisseur d’identités pour GrimoireLab, SortingHat enrichit les données collectées avec des informations sur les personnes qui ont contribué.

Leçon apprise: La gestion des identités et des affiliations des personnes est un élément essentiel pour effectuer une analyse de qualité en open source.

Lors du voyage d’un héros, le héros peut être attiré dans un « raccourci » qui mène à des dangers et à des revers. C’était le cas de GrimoireLab pour les visualisations codées en dur. Ses prédécesseurs présentaient les données par le biais de visualisations codées en dur, « rapides et sales ». Les modifications de la structure ou de la présentation des données ont nécessité la modification du code source.

Ce raccourci a été choisi car les utilisateurs étaient également les développeurs, afin qu’ils puissent ajuster les visualisations selon les besoins. Mais cela a créé des revers lorsque Bitergia a commencé à fournir des analyses de santé communautaire aux clients. Les nouveaux utilisateurs voulaient explorer leurs données mais ne pouvaient pas modifier le code source.

Notre héros, GrimoireLab, a réussi à sortir de la situation difficile en rencontrant un allié capable de produire des visualisations à l’aide d’un outil générique d’exploration et de visualisation de données.

La plateforme GrimoireLab utilise désormais Kibana comme outil par défaut pour les visualisations. Les utilisateurs peuvent interroger les données librement et créer des visualisations personnalisées. Cela nécessite une connaissance de la structure et de la signification des données sous-jacentes. Du point de vue de l’outillage, les modifications de la structure des données ne nécessitent aucune modification de l’outil générique d’exploration et de visualisation des données.

Une mise en garde pour fournir un outil générique d’exploration et de visualisation des données est que les utilisateurs apprécient les gains rapides. Les données doivent être visualisées immédiatement pour montrer aux utilisateurs au moins un aperçu d’une communauté. Par conséquent, GrimoireLab Sigils permet le partage de visualisations et de tableaux de bord.

Leçon apprise: Ne codez pas en dur les visualisations si le format et le type de données peuvent changer.

Fournir des données à d’autres outils

Certaines épreuves sont simples pour un héros qui a un allié fiable pour aider à les résoudre. Le héros n’a pas besoin de comprendre comment une épreuve est surmontée ni d’avoir l’impression d’avoir joué un rôle dans sa résolution. Cependant, sans le héros, l’allié ne peut pas surmonter l’épreuve et peut même ne pas le savoir.

Les utilisateurs de GrimoireLab ont des préférences différentes quant aux données qu’ils veulent voir et comment ils veulent les voir. Certains peuvent être heureux d’interroger une base de données, certains peuvent être heureux de jeter un coup d’œil rapide sur un tableau de bord, certains peuvent être heureux d’explorer visuellement les données dans un outil générique, et certains peuvent seulement avoir accès aux données via des rapports ou des annonces d’autres .

Ce dernier groupe pourrait utiliser un instantané des données. Cependant, comme les cours des actions des entreprises, les paramètres de santé communautaire changent. Par conséquent, les utilisateurs peuvent souhaiter inclure des métriques et des visualisations « en direct » sur leurs sites Web ou à d’autres endroits, GrimoireLab propose donc deux options pour différents types d’utilisateurs.

La première option dans GrimoireLab consiste à utiliser Kibana pour incorporer des visualisations et des tableaux de bord à l’aide de cadres en ligne HTML. L’utilisateur conçoit la visualisation dans Kibana et intègre la visualisation, qui est chargée depuis Kibana avec les dernières informations. Cela nécessite que Kibana soit accessible au public. Cette option convient aux utilisateurs qui ont besoin d’un moyen rapide de partager des mesures de santé de la communauté mais qui ne souhaitent pas consacrer d’efforts à personnaliser la visualisation.

Leçon apprise: Fournissez un moyen facile de partager des mesures « en direct ».

La deuxième option consiste pour les utilisateurs à créer des intégrations personnalisées en interrogeant directement l’API Elasticsearch. Les utilisateurs peuvent interroger la base de données pour les données souhaitées, puis créer une visualisation personnalisée. Cette option convient aux utilisateurs qui souhaitent intégrer leurs données dans d’autres plateformes et contrôler pleinement la visualisation et l’expérience utilisateur. Les intégrateurs peuvent utiliser Kibana pour explorer les données, former des requêtes spécifiques, puis copier la requête de Kibana dans leur propre travail d’intégration.

Leçon apprise: Fournissez un moyen simple d’explorer les données et de créer des requêtes personnalisées pour les données qui peuvent être nécessaires pour d’autres outils.

Calcul des métriques à partir des données brutes

Alors qu’un héros grandit à chaque épreuve, le voyage continue avec des épreuves toujours plus difficiles, gardant l’histoire séduisante. GrimoireLab a surmonté les épreuves de collecte de données, de stockage efficace et de visualisation. Le prochain essai consistait à produire des métriques significatives à partir de données brutes.

Pour démontrer, regardons les métriques CHAOSS. Certaines métriques peuvent être créées à partir de données directement disponibles à partir de sources de données. Par exemple, les modifications de code sont un nombre de validations dans le journal Git. Les autres mesures ne sont pas directement disponibles mais nécessitent d’abord la manipulation des données. Par exemple, le temps de réponse aux problèmes nécessite de calculer la différence de temps entre le moment où un problème est ouvert et le moment où la première réponse est soumise.

Je m’attends à ce que CHAOSS continue de définir des paramètres, ils deviendront plus complexes. Les métriques complexes peuvent être basées sur d’autres métriques. Un outil d’analyse de développement logiciel comme GrimoireLab doit être capable de calculer ces métriques complexes.

GrimoireLab’s GrimoireELK stocke les entrées données brutes avant d’en faire quoi que ce soit. Ensuite, les données sont enrichies et le résultat de ce processus est stocké séparément données enrichies. alors études sont réalisées dans lesquelles les données enrichies et brutes sont combinées de différentes manières à partir de différentes sources de données et calculées pour des objectifs spécifiques. Par exemple, l’une des études par défaut de GrimoireLab identifie les contributeurs occasionnels, réguliers et principaux et permet d’analyser les contributions de ces groupes.

Leçon apprise: L’enrichissement des données peut nécessiter plusieurs étapes avec des mesures simples utilisées pour des mesures plus complexes qui sont composées de plusieurs mesures combinées ensemble.

Acte 3: Retour

Le troisième acte du voyage du héros commence après que les épreuves ont été surmontées, une récompense est reçue et le héros rentre chez lui. Le retour peut commencer par une sorte de résurrection ou de renaissance pour une action à couper le souffle. Enfin, le héros gagne la liberté de vivre en tant que maître de deux mondes. GrimoireLab renaît. À partir des cendres de ses ancêtres, les leçons apprises ont été mises en œuvre dans la plate-forme GrimoireLab complètement ressuscitée (c’est-à-dire repensée) que nous avons aujourd’hui.

GrimoireLab a reçu sa récompense sous forme de reconnaissance. En tant que projet fondateur du projet CHAOSS de la Linux Foundation, GrimoireLab est devenu un élément d’un écosystème plus vaste. Bien qu’il ait commencé dans une petite entreprise basée en Espagne, GrimoireLab fait maintenant partie de l’écosystème commercial open source à croissance rapide créé par la Fondation Linux avec cinq groupes de travail et des dizaines de contributeurs.

Issu de la licence publique générale GNU, GrimoireLab a la liberté de choisir son propre destin. Et surtout, ses utilisateurs aussi.

Source : https://opensource.com/article/20/3/grimoirelab Traduit de l’anglais sous licence CC BY-SA 4.0

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *