Redonner à l'open source sur lequel nous bâtissons
Gabriel Devenyi, PhD
Chaque analyse que nous menons à la Plateforme de neuroinformatique Douglas repose sur des logiciels écrits par d’autres et offerts gratuitement. Les données du scanner deviennent un article grâce à ITK, ANTs, FreeSurfer, la trousse MINC, RMINC, Nipoppy, Nextflow, nf-neuro, Dcm2Bids, jsPsych et des dizaines de bibliothèques plus petites en dessous. Rien de tout cela ne nous est facturé. Tout cela demande de l’entretien.
Les outils libres ne s’entretiennent pas tout seuls. Les compilateurs changent, les systèmes d’exploitation évoluent, les dépendances cassent, et un paquet qui se compilait proprement il y a cinq ans échoue soudain sur une machine récente. Quelqu’un doit corriger cela. Trop souvent, on suppose que ce « quelqu’un » est l’auteur original, travaillant seul, gratuitement, sur son temps libre. Quand cette personne passe à autre chose, l’outil se dégrade en silence, et tous ceux qui en dépendent héritent du problème.
Nous avons décidé il y a un moment que si nous dépendons d’un outil, nous aidons à le maintenir.
Ce que cela représente en chiffres
Nous avons recensé les contributions publiques de notre équipe à des projets que nous ne possédons pas, depuis 2021. En excluant nos propres organisations et dépôts personnels, des membres de la plateforme ont ouvert plus de 200 demandes de tirage (pull requests) réparties sur environ 70 projets libres en amont, dont plus de 130 déjà intégrées aux outils que l’ensemble de la communauté utilise chaque jour.
L’essentiel de ce travail consiste à garder la chaîne d’outils de neuroimagerie vivante et correcte :
Corrections d’exactitude dans des bibliothèques fondamentales. Un correctif à ITK a rectifié la lecture des fichiers MINC2, en convertissant les coordonnées de RAS vers LPS afin que les images se retrouvent dans la bonne orientation, un bogue qui affectait silencieusement quiconque lisait ces fichiers. Des correctifs à RMINC ont résolu des erreurs d’arrondi dans la conversion monde-vers-voxel et libéré de la mémoire que valgrind signalait comme fuyante.
Faire compiler du vieux code sur des machines récentes. Les compilateurs modernes (GCC 15, C23) et les systèmes de compilation (CMake 4) cassent du code scientifique vieux de plusieurs décennies. Nous avons soumis des correctifs à libminc, minc-tools, la trousse MINC, ITK et d’anciens outils d’affichage afin que ces logiciels se compilent et fonctionnent encore aujourd’hui, sous Linux, sous macOS récent et sur Apple Silicon.
De nouvelles capacités, pas seulement des réparations. Le
travail se poursuit et n’est pas que défensif : des contributions
récentes ajoutent un véritable support des images MINC en quatre
dimensions (x, y, z, temps) à ITK, corrigent un plantage des
modèles à effets mixtes de RMINC avec les versions récentes de
lme4, et rectifient la lecture des données IRM brutes Bruker
dans la bibliothèque brukerapi-python.
Performance et fiabilité. Nous avons appris à ANTs à ne pas répéter une étape coûteuse de correction de biais à chaque itération et à cesser de relire les mêmes images depuis le disque, et corrigé des plantages (segfaults) sur des fichiers manquants. De petits changements, du temps réellement économisé à chaque exécution, pour chaque utilisateur.
Empaquetage, conteneurs et reproductibilité. Des images Docker et Singularity pour FreeSurfer, DSI-Studio et les outils scilus ; des recettes conda-forge ; et des correctifs de conteneurs qui permettent d’exécuter ces outils dans des pipelines Nextflow. Nous avons aussi publié sur Zenodo des configurations de pipeline Nipoppy prêtes à l’emploi et reproductibles pour FreeSurfer, mideface et RABIES, afin que d’autres laboratoires puissent reproduire exactement nos traitements.
Toutes les contributions ne sont pas acceptées, et c’est très bien. Certaines de ces demandes de tirage sont encore ouvertes, d’autres ont été refusées au profit d’une approche différente. C’est ainsi qu’un projet sain fonctionne : on propose, on discute, on améliore l’outil ou on comprend pourquoi il est ainsi. L’important est d’être présent.
Pourquoi c’est important, et pourquoi nous vous demandons d’y prêter attention
Le logiciel scientifique a un problème de pérennité. Les outils qui soutiennent un domaine entier sont souvent maintenus par une ou deux personnes, financés par rien en particulier, en concurrence pour l’attention avec les subventions et les articles qui, eux, font réellement avancer les carrières. Pendant ce temps, des milliers de laboratoires fondent leurs résultats publiés sur ce travail non rémunéré. Quand cela casse, la science casse avec, et la facture des réparations tombe pour tout le monde en même temps.
Vous pouvez aider, que vous écriviez du code ou non :
- Contribuez en retour. Si un outil que vous utilisez a une aspérité, une compilation cassée, une faute de frappe dans la documentation, corrigez-la et envoyez le correctif. La première contribution est la plus difficile ; ensuite, cela devient une habitude.
- Signalez clairement. Un bon rapport de bogue accompagné d’un exemple reproductible est un véritable cadeau pour une personne qui maintient un projet.
- Citez et créditez les logiciels que vous utilisez dans vos articles, afin que les personnes qui les maintiennent puissent en démontrer l’impact lorsqu’elles demandent du financement.
- Financez l’entretien, pas seulement les nouvelles fonctionnalités. Si votre subvention dépend d’un outil, un petit parrainage ou un contrat d’entretien le garde en vie bien plus sûrement qu’en espérant qu’un bénévole ait une fin de semaine libre.
Nous profitons énormément de la générosité de la communauté du logiciel libre, alors nous considérons qu’il fait partie de notre travail de lui redonner. Si votre groupe dépend de logiciels scientifiques et souhaite de l’aide pour les maintenir, contribuer en amont ou bâtir des pipelines reproductibles par-dessus, contactez-nous à contact@douglasneuroinformatics.ca.