Removing Noise or Introducing Bias? The Hidden Cost of MSR Filtering

Imaginez l'internet comme une bibliothèque géante et chaotique où n'importe qui peut construire une étagère et l'appeler une bibliothèque. C'est le monde du Logiciel Libre (Open Source ou OSS), un immense terrain de jeu numérique où des millions de personnes — des étudiants testant de nouvelles idées de codage aux développeurs professionnels construisant la prochaine grande application — stockent leurs projets. Les chercheurs, qui sont comme des détectives essayant de résoudre des mystères sur le fonctionnement des logiciels, adorent visiter cette bibliothèque. Ils fouillent dans les étagères, regardant combien de personnes ont « aimé » un projet (étoiles), combien de fois les gens ont modifié les livres (commits) et combien de personnes ont aidé à les écrire. Ces indices les aident à comprendre les secrets de l'ingénierie logicielle. Mais voici le hic : la bibliothèque est si vaste qu'elle est remplie de boîtes vides, de mannequins de test et de gribouillages inachevés. Pour trouver les « vrais » livres, les chercheurs jettent généralement tout ce qui ne semble pas assez populaire ou actif. Ils utilisent des règles comme : « Si un projet n'a pas au moins 10 étoiles, c'est juste du bruit, alors jetons-le. »

Mais et si ces règles jetaient les histoires les plus intéressantes ? Et si, dans notre tentative désespérée de nettoyer la bibliothèque, nous cachions accidentellement le fait que la plupart des livres sont en réalité abandonnés, ou que nous ne finissons par lire que ceux écrits par les mêmes quelques auteurs célèbres ? C'est la grande question que posent les chercheurs Mohit Kaushik et Jyoti Bawa. Ils craignent que les filtres mêmes que les scientifiques utilisent pour rendre leurs données « propres » ne rendent leurs conclusions « sales » en cachant la réalité véritable, désordonnée, de la vie des projets logiciels.

Le Grand Filtre : Nettoyer les Données ou Cacher la Vérité ?

Dans cette étude, les auteurs ont décidé de jouer à un jeu de « Et si ? » avec une pile massive de données. Ils ont examiné 1,57 million de dépôts de logiciels provenant d'une plateforme appelée SEART. Considérez cet ensemble de données comme un grand seau de briques LEGO mélangées. Certaines sont de grands châteaux colorés ; d'autres sont de minuscules briques rouges isolées ; et beaucoup ne sont que des morceaux cassés que personne n'a jamais finis.

Habituellement, les chercheurs regardent ce seau et disent : « D'accord, nous ne voulons que les grands châteaux terminés. Jetons tout ce qui a moins de 10 étoiles (likes) ou moins de 10 commits (changements). » Les auteurs ont testé ce qui se passe lorsqu'ils appliquent ces règles strictes, comme en montant le volume d'un filtre jusqu'à ce qu'il devienne très fort.

Le Coût Caché de la « Popularité »
Lorsque les chercheurs ont appliqué un « filtre de popularité » (en ne regardant que les projets avec plus d'étoiles), ils ont découvert quelque chose de surprenant. À mesure qu'ils augmentaient le seuil d'étoiles de 10 à 1 000, le projet « moyen » de leur échantillon ne devenait pas seulement légèrement meilleur ; il devenait 7 fois plus grand. Les projets devenaient plus vieux, avaient plus de personnes travaillant dessus et étaient beaucoup plus susceptibles d'avoir une licence formelle (comme un livre de règles).

Mais voici le rebondissement : en poursuivant les projets populaires, ils ont complètement perdu de vue la réalité. Dans leur seau original, non filtré, 73,42 % des projets étaient en fait inactifs ou « abandonnés ». Cependant, à mesure qu'ils filtraient pour la popularité, ce chiffre diminuait. Au moment où ils ne regardaient plus que les projets super populaires (1 000+ étoiles), les données donnaient l'impression que seulement 50,65 % étaient abandonnés. Le filtre n'a pas seulement supprimé le bruit ; il a caché le fait que la plupart des projets échouent ou sont délaissés. C'est comme si vous ne demandiez aux personnes les plus réussies d'une ville que de parler de leur travail, et que vous concluiez que « le chômage est bas » parce que vous n'avez jamais parlé aux personnes qui ont perdu leur emploi.

Le Piège de l'« Activité »
Les auteurs ont également testé des « filtres d'activité », qui ne conservent que les projets ayant un nombre élevé de commits (changements). C'était encore plus extrême. Lorsqu'ils ont filtré pour une activité élevée, la taille moyenne du projet a grandi de 18 fois ! Ces filtres ont également changé la « personnalité » du logiciel. Par exemple, les projets utilisant le langage C++ étaient courants dans les groupes à seuil bas, mais disparaissaient du top 5 lorsque le filtre devenait strict. Pendant ce temps, TypeScript et Go sont devenus beaucoup plus courants dans les listes filtrées.

L'étude suggère que ces filtres ne sont pas neutres. Ils agissent comme un tamis qui ne laisse passer que certains types de projets : des projets d'infrastructure plus anciens, massifs et bien financés. Ils écartent les projets plus petits, plus récents ou plus expérimentaux, même si ces petits projets sont réels et actifs.

Le Bazar des Relations
La découverte la plus ludique (et potentiellement dangereuse) concerne la façon dont ces filtres faussent les relations entre différentes choses. Imaginez que vous essayez de déterminer si « travailler dur » (commits) mène à « être populaire » (étoiles). Dans le monde réel et désordonné (les données de base), ces deux choses sont seulement faiblement connectées. Mais lorsque les chercheurs ont appliqué leurs filtres, la connexion est soudainement apparue comme très forte.

Par exemple, le lien entre « commits » et « taille du projet » est passé d'un 0,466 modéré à un 0,808 très fort dans le groupe filtré par l'activité. Les auteurs expliquent que ce n'est pas parce que les projets ont réellement changé ; c'est parce que le filtre les a forcés à apparaître ainsi. En ne gardant que les gros projets très occupés, le filtre a fait croire que « les gros projets ont toujours beaucoup de commits », alors qu'en réalité, la relation est beaucoup plus complexe. C'est comme si vous n'étudiez que les plus grands joueurs de basket et concluiez que « la taille est la seule chose qui compte dans le sport », en ignorant tous les autres.

Le Verdict : Ne Jetez Pas Simplement le Bruit

Les auteurs concluent que, bien que nous ayons besoin de nettoyer nos données, nous ne pouvons pas simplement utiliser des règles arbitraires comme « 10 étoiles » ou « 500 commits » sans y réfléchir. Ces règles sont comme un marteau contondant : elles écrasent le « bruit », mais elles écrasent aussi la vérité. Elles créent une image déformée où les projets logiciels semblent plus prospères, plus vieux et plus uniformes qu'ils ne le sont réellement.

Au lieu de filtrer aveuglément, les auteurs suggèrent d'utiliser l'échantillonnage stratifié. Imaginez prendre une louche dans le seau de LEGO qui contient un mélange équitable de grands châteaux, de petites maisons et de morceaux cassés, plutôt que de simplement choisir les plus grands châteaux. Ils exhortent également les scientifiques à repenser ce qui constitue du « bruit ». Peut-être qu'un projet avec zéro étoile n'est pas seulement une expérience ratée ; peut-être est-ce un trésor caché qui n'a pas encore été découvert.

En résumé, cet article nous avertit que, dans notre hâte de trouver les données « parfaites », nous risquons de construire un château de cartes qui semble parfait à l'extérieur, mais qui s'effondre dès que nous essayons de comprendre le monde réel et désordonné du logiciel. Les auteurs ne disent pas d'arrêter totalement le filtrage, mais ils suggèrent fortement de cesser d'utiliser ces règles « universelles » et de commencer à être plus prudents quant à ce que nous jetons.