Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See
Cet article introduit une carte de « déforkage » (deforking) organisée pour le World of Code qui reconstruit les familles de projets inter-forges en réduisant les historiques git partagés en grappes unifiées, corrigeant ainsi l'inflation de popularité et révélant des milliers de relations de fork — incluant des familles multi-forges et des racines non issues de GitHub — qui sont invisibles pour les graphes spécifiques à une plateforme.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez l'histoire entière du développement logiciel comme une immense et chaotique bibliothèque. Dans cette bibliothèque, il y a des millions de livres (des dépôts ou « repositories »). Mais voici le piège : beaucoup de ces livres ne sont que des photocopies de la même histoire originale.
Dans le monde du codage, cela s'appelle le forking (la création d'une fourche). Un développeur prend un projet existant, le copie, et commence sa propre version. Il peut modifier quelques lignes ici ou là, mais l'histoire centrale est identique.
Le problème que l'article traite est que si vous essayez de compter à quel point un morceau de code est « populaire » en comptant simplement chaque livre dans la bibliothèque, vous obtenez un chiffre largement gonflé. Si une histoire populaire a été copiée 10 000 fois, cela donne l'impression que 10 000 histoires différentes sont lues, alors qu'en réalité, c'est une seule histoire qui est lue dans 10 000 endroits différents.
Cet article présente une nouvelle carte (un outil) qui nettoie cette bibliothèque. Elle regroupe toutes les photocopies avec leur source originale, afin que les chercheurs puissent voir la vraie histoire, et non le bruit généré par les copies.
Voici comment ils ont procédé, en utilisant des analogies simples :
1. Le détective de la « page partagée »
Les auteurs ont réalisé que dans le monde numérique, on ne peut pas facilement falsifier un historique. Si deux livres partagent exactement la même page (un « commit » ou une modification spécifique de code), ils sont forcément liés.
- L'ancienne méthode : Ils essayaient de lier chaque livre qui partageait une page. Mais cela revenait à dire : « Si deux livres possèdent tous deux une page qui dit "Copyright 2024", ils racontent la même histoire. » C'est faux ! Beaucoup de livres sans rapport possèdent la même page de copyright. Cela provoquait un effet où la carte collait des histoires complètement différentes pour former un énorme bloc informe et désordonné.
- La nouvelle méthode : Ils ont construit une carte plus intelligente. Ils cherchaient des nombreuses pages partagées, et non une seule. Si deux livres partagent un chapitre entier, ils sont certainement liés.
2. Le filtre de « limite de taille » (Le Cap)
Même avec une carte plus intelligente, certaines pages géantes et ennuyeuses (comme les accords de licence standards ou les modèles de démarrage vides) agissaient encore comme des ponts, reliant des histoires sans rapport.
- La solution : Les auteurs ont imposé une limite de taille à ces ponts. Si une page partagée apparaît dans plus de 250 livres, ils supposent qu'il s'agit d'un modèle générique (comme une page standard de « Conditions Générales d'Utilisation ») et l'ignorent.
- Le résultat : Cela a brisé les énormes blocs désordonnés. Soudain, la carte montrait des familles d'histoires distinctes au lieu d'un seul super-amas confus. Cela n'a pas brisé les vraies familles ; cela a simplement supprimé la colle qui collait des éléments sans rapport entre eux.
3. La vérification de l'« histoire réelle »
Les auteurs craignaient qu'en découpant ces gros blocs, ils ne découpent accidentellement une histoire réelle et complexe (comme une histoire qui aurait été traduite dans de nombreuses langues puis recombinée).
- Le test : Ils ont examiné le plus grand groupe restant sur leur carte. Ils ont constaté qu'il ne s'agissait pas d'une erreur, mais d'une histoire réelle et complexe où un grand projet avait véritablement absorbé des parties d'autres projets célèbres (comme un système d'exploitation majeur incorporant du code provenant d'un navigateur web).
- La décision : Parce que ce groupe « résiduel » était composé d'une histoire réelle et profonde, et non d'une simple colle bon marché, ils ont décidé de ne pas le découper davantage. Ils l'ont laissé intact car il représente une relation réelle et complexe dans le monde du logiciel.
4. La comparaison avec la « liste officielle »
Pour s'assurer de l'exactitude de leur carte, ils l'ont comparée à la « Liste des Forks » officielle de GitHub (une liste où les utilisateurs cliquent manuellement sur un bouton « Fork »).
- La correspondance : Lorsqu'ils ont examiné les projets présents à la fois sur leur carte et sur la liste de GitHub, ils ont concordé 99 % du temps.
- La surprise : Leur carte a trouvé des choses que la liste de GitHub a manquées !
- Familles inter-plateformes (Cross-Forge Families) : Ils ont trouvé des familles de projets qui ont commencé sur GitHub mais ont été copiées sur GitLab, Bitbucket et d'autres sites. La liste de GitHub ne voit que le côté GitHub ; cette carte voit toute la généalogie à travers Internet.
- Forks détachés (Detached Forks) : Ils ont trouvé des projets qui ont commencé comme des copies mais qui ont complètement réécrit leur historique, de sorte qu'ils ne sont plus connectés à l'original. La carte les a correctement identifiés comme des entités distinctes, alors que la liste officielle pourrait encore les considérer comme connectés.
5. Pourquoi cela importe
Avant cette carte, si vous vouliez savoir sur combien de projets différents un seul programmeur a travaillé, vous pourriez obtenir un chiffre faux comme « 5 000 projets », simplement parce qu'il a travaillé sur un projet populaire qui possède 5 000 copies.
- La correction : Cette carte corrige cela. Elle vous indique que le programmeur a réellement travaillé sur 5 projets distincts, et non 5 000.
- L'issue : Elle fournit une vue propre et précise du monde du logiciel, séparant les histoires originales des photocopies, et capable même de repérer des histoires qui s'étendent sur différents sites web.
En résumé : Les auteurs ont construit un outil qui démêle le réseau complexe des codes copiés. Ils ont utilisé une « limite de taille » pour empêcher les projets sans rapport de rester collés ensemble, ont vérifié leur travail par rapport aux registres officiels, et ont découvert que le monde du logiciel est encore plus interconnecté à travers différents sites web que ce que nous pensions auparavant. Ils ont rendu cette carte disponible pour que quiconque puisse l'utiliser, garantissant que les futures études sur l'histoire du logiciel ne soient pas trompées par le volume massif de copies.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.