[ad_1]
Le 10 avril, les astrophysiciens ont annoncé qu'ils avaient capturé la toute première image d'un trou noir. C’était une nouvelle enthousiasmante, mais aucun des titres vertigineux n’a indiqué que l’image aurait été impossible sans un logiciel à code source ouvert. L'image a été créée à l'aide de Matplotlib, une bibliothèque Python pour la représentation graphique de données, ainsi que d'autres composants de l'écosystème Python Open Source. À peine cinq jours plus tard, la National Science Foundation (NSF) des États-Unis a rejeté une proposition de subvention visant à soutenir cet écosystème, affirmant que le logiciel n’avait pas un impact suffisant.
C’est un problème familier: les logiciels à code source ouvert sont largement reconnus comme étant d’une importance cruciale en science, mais ils sont financés de manière non durable. Le travail de soutien est souvent géré de manière ponctuelle par des étudiants diplômés et postdoctoraux surmenés, et peut conduire à l'épuisement professionnel. "C'est un peu la différence entre avoir une assurance et avoir un GoFundMe quand leur grand-mère va à l'hôpital", explique Anne Carpenter, biologiste en informatique au Broad Institute of Harvard et au MIT à Cambridge, Massachusetts, dont le laboratoire a développé l'outil d'analyse d'image CellProfiler. "Ce n’est tout simplement pas une belle façon de vivre."
Les scientifiques qui écrivent des logiciels open source manquent souvent de formation formelle en génie logiciel, ce qui signifie qu'ils n'ont peut-être jamais appris les meilleures pratiques en matière de documentation et de test de code. Cependant, un logiciel mal entretenu peut entraîner une perte de temps et d’efforts et nuire à la reproductibilité. Les biologistes qui utilisent des outils informatiques passent régulièrement des «heures et des heures» à essayer d'obtenir le code d'autres chercheurs, explique Adam Siepel, biologiste en calcul au Laboratoire Cold Spring Harbour à New York, et mainteneur de PHAST, un outil utilisé à des fins de comparaison. génomique évolutive. "Ils essaient de le trouver et il n’ya pas de site Web, ou le lien est brisé, ou il ne compile plus, ou se bloque lorsqu'ils ont essayé de l’exécuter sur leurs données."
Mais il existe des ressources qui peuvent aider et des modèles à imiter. Si votre groupe de recherche envisage de publier un logiciel à code source ouvert, vous pouvez vous préparer au travail de support et aux questions qui se poseront lorsque d'autres commenceront à l'utiliser. Ce n’est pas facile, mais cet effort peut générer des citations et une reconnaissance de nom pour les développeurs, et améliorer l’efficacité sur le terrain, explique Wolfgang Huber, biologiste en informatique au Laboratoire européen de biologie moléculaire à Heidelberg, en Allemagne. De plus, il ajoute: "Je pense que c'est amusant."
Avoir un plan
Pour les développeurs de logiciels scientifiques, le jour de la publication n’est pas la fin du travail, mais souvent le début. Tim Hopper, spécialiste des données chez Cylance à Raleigh, en Caroline du Nord, déclare sur Twitter: «Donnez un poisson à un homme et vous le nourrissez pendant une journée. Ecrivez un programme pour le récupérer et le conserver toute votre vie. »Carpenter a embauché un ingénieur logiciel à plein temps pour gérer la maintenance de CellProfiler, qui enregistre environ 700 questions et 100 rapports de bogues ou demandes de fonctionnalités par an, soit environ 15 par semaine. . Mais la plupart des logiciels à source ouverte sont gérés sur une base volontaire. «Je l'ai fait moi-même, comme après minuit», explique Siepel au sujet de ses efforts d'assistance technique sur PHAST.
Pour vous préparer, il est utile d’avoir une idée de ce dans quoi vous vous engagez. Certains logiciels n’auront besoin que d’une assistance à court terme, alors que d’autres programmes pourraient être utilisés pendant des décennies. Nelle Varoquaux explique que, dans son domaine d'apprentissage automatique en biologie, les outils logiciels deviennent rapidement obsolètes car la taille des ensembles de données évolue si rapidement. Varoquaux est biologiste informaticien à l'Université de Californie à Berkeley et co-développeur de scikit-learn, un progiciel d'apprentissage automatique pour Python. «Quand j'ai commencé mon doctorat, tout ce sur quoi je travaillais était intégré dans la RAM et je n'avais jamais eu de problème de mémoire», dit-elle. Mais aujourd'hui, la mémoire est un énorme défi. Elle estime qu'elle devra entretenir deux outils qu'elle a développés pour analyser l'ADN et la conformation des chromosomes – glacée et pastis – pendant encore cinq ans avant qu'ils ne deviennent obsolètes.
L’obsolescence n’est pas grave, ajoute-t-elle: savoir quand arrêter de prendre en charge des logiciels est une compétence importante. «Laisser un outil mourir lorsqu'il a perdu toute utilité ou, lorsqu'un responsable souhaite le quitter, l'orphelin et rechercher un parent nourricier», conseille Huber.
Quelle que soit la durée d'utilisation de votre logiciel, de bonnes pratiques en matière d'ingénierie logicielle et une bonne documentation sont essentielles, déclare Andreas Mueller, scientifique en apprentissage automatique à l'Université Columbia de New York. Cela inclut les systèmes d'intégration continue (tels que TravisCI), le contrôle de version (Git) et les tests unitaires. «L’intégration continue vous dit, chaque fois que vous modifiez votre code, s’il fonctionne toujours ou si vous le rompez», à condition que vous écriviez les tests corrects pour qu’il soit exécuté, dit Mueller; Le contrôle de version est un système d’enregistrement des modifications apportées au code source afin que vous puissiez revenir à une version précédente si nécessaire. et des tests unitaires testent chaque composant individuel du logiciel pour s'assurer qu'il est solide. La combinaison, dit-il, "vous permettra de gagner 100% du temps". Des organisations telles que Software Carpentry, dirigée par des volontaires, et le eScience Institute de l'Université de Washington, à Seattle, hébergent des camps d'entraînement sur le développement de logiciels et proposent des tutoriels sur GitHub. Le centre eScience néerlandais à Amsterdam fournit un guide sur les meilleures pratiques de développement de logiciels sur le site.
Pour faciliter la maintenance, Varoquaux recommande de mettre l’accent sur la lisibilité du code plutôt que sur les performances maximales. «J'essaie toujours de la rendre lisible, bien documentée et testée. Par conséquent, en cas de problème, je peux le réparer rapidement», dit-elle.
Et c’est inévitable en matière de logiciel: «Dès que vous aurez des utilisateurs, ils trouveront des bugs», explique Varoquaux. Huber recommande de répondre aux questions des utilisateurs via un forum public, tel que Stack Overflow, où les utilisateurs peuvent baliser leur question avec le nom du logiciel. «Ne répondez pas aux courriers privés pour obtenir de l'aide des utilisateurs», dit-il. Les forums publics offrent trois avantages. Premièrement, ils atteignent beaucoup plus d'utilisateurs que les courriels individuels. "Pour tous ceux qui écrivent un e-mail, il y a probablement 100 personnes qui sont trop timides pour demander", explique Huber. Deuxièmement, ils ont tendance à encourager des questions plus ciblées et réfléchies. Troisièmement, ils dissuadent les utilisateurs de la stratégie fastidieuse d’envoyer des e-mails à plusieurs responsables de logiciels séparément avec la même question.
Huber recommande également de publier votre logiciel sur un référentiel tel que le réseau CRAN (Comprehensive R Archive Network) ou Bioconductor, un archivage à compartiments multiples pour les logiciels biologiques écrit en R, plutôt que sur votre page d'accueil personnelle ou GitHub. Ces référentiels sont sélectionnés et ont des directives de soumission pour les conventions de dénomination et les composants requis, comme le font les revues scientifiques. De plus, CRAN et Bioconductor «offrent des tests et une intégration continue sur plusieurs plates-formes, ainsi que des installateurs robustes et faciles à utiliser», explique Huber.
Une question de financement
Le support logiciel nécessite du temps et de l'argent. Mais le financement peut être difficile à trouver. Aux États-Unis, les instituts nationaux de la santé (NIH) et la NSF se concentrent sur de nouvelles recherches et la maintenance de logiciels à code source ouvert ne correspond souvent pas à leurs besoins. «C’est vraiment la tragédie des agences de financement en général», déclare Carpenter. "Ils financeront 50 groupes différents pour créer 50 algorithmes différents, mais ils ne paieront pas pour un ingénieur logiciel."
Mais il existe un financement de ces organisations et d’autres. Un fil Twitter (voir) documente les subventions accordées par la NSF, les NIH et le, et un programme commun de la NSF et de la (qui fait maintenant partie de la recherche et de l’innovation au Royaume-Uni). Des fondations privées américaines telles que la Fondation Gordon et Betty Moore, la Fondation Alfred P. Sloan et l'Initiative Chan Zuckerberg (CZI) financent également une assistance logicielle à code source ouvert. CZI prend en charge le logiciel de traitement d’images basé sur Python, scikit-image, les plates-formes ImageJ et Fiji, et finance également l’ingénieur logiciel de l’équipe Carpenter.
Au Royaume-Uni, le Software Sustainability Institute, basé à l'Université d'Edimbourg, fournit des évaluations gratuites, courtes et en ligne de la durabilité des logiciels, et des bourses de 3 000 £ (3 800 USD) pour des chercheurs basés en Grande-Bretagne ou leurs collaborateurs. L'institut met périodiquement à la disposition des utilisateurs des créneaux horaires pour leur permettre de travailler avec leurs experts pendant six mois au maximum, afin de développer de nouveaux logiciels ou d'affiner les pratiques de logiciels et de maintenance existantes. En Allemagne, Huber recommande les subventions de réseau de la Commission européenne et l’initiative deNBI du ministère allemand de la Science, qui financent toutes deux Bioconductor.
Le problème général de la maintenance des infrastructures numériques attire de plus en plus l'attention. Varoquaux et ses collègues ont reçu 138 000 dollars des fondations Alfred P. Sloan et Ford pour étudier «le travail visible et invisible du maintien de logiciels à code source ouvert», a-t-elle déclaré, y compris l'épuisement professionnel des chercheurs qui consacrent leur temps à ces travaux – une partie d'un portefeuille de 13 projets de recherche sur les infrastructures numériques financés à hauteur de 1,3 million de dollars. En mai, le CZI a annoncé trois appels à propositions pour le financement de logiciels biomédicaux à source ouverte, dont le premier s’est ouvert en juin. Siepel a publié un article dans la presse Biologie du génome sur le défi du financement du support logiciel open-source.
Et un financement est nécessaire: écrire un logiciel facile à utiliser pour un large éventail de données demande beaucoup plus d'efforts qu'un logiciel qui ne fonctionne que pour vous. “La différence est au moins aussi grande qu’entre le papier poli publié dans La nature et la première pile de diapositives pour une réunion de laboratoire avec les résultats sous-jacents », explique Huber.
Néanmoins, l’exercice présente un réel intérêt. L’équipe de Siepel répond parfois aux requêtes des utilisateurs en leur indiquant qu’ils appliquent le logiciel à de fausses données, une subtilité qu’un biologiste de l’évolution remarquerait, mais pas un ingénieur en logiciel. «Il existe une sorte d’idiome: manger sa propre nourriture pour chien», explique Huber: «Si vous utilisez votre propre logiciel pour de vraies questions, vous réalisez alors où c’est mauvais, c’est ce qui fait défaut. Avoir un expert en domaine écrit le logiciel tend à le rendre plus précieux. ”
[ad_2]