Développement ouvert de logiciels scientifiques

Révolutionner la recherche avec une infrastructure logicielle collaborative

Écrit par Max Schulz

La révolution de l'open source

Image générée par Stable Diffusion: "Un programmeur se reposant sur les épaules de géants" (Mon ingénierie prompte a clairement besoin d'être améliorée)

Avez-vous déjà pensé au fait que la technologie que nous utilisons tous les jours repose principalement sur le travail de bénévoles ? Le mouvement open source a révolutionné le secteur technologique en permettant aux individus et aux entreprises d'accéder librement au code source, de le modifier et de le diffuser. Mais il ne s'agit pas seulement d'économiser quelques dollars sur les licences de logiciels. Le mouvement open source a encouragé l'esprit de communauté et de collaboration, ce qui a donné naissance à certains des projets les plus utilisés du secteur.

Tout a commencé aux débuts de l'informatique, lorsque les logiciels étaient librement échangés entre les universitaires et les chercheurs. À la fin des années 1980 et au début des années 1990, le terme "open source" a été inventé et le mouvement a commencé à prendre de l'ampleur. Parmi les personnalités éminentes de cette époque, on trouve Richard Stallman, fondateur de la Free Software Foundation et du projet GNU (qui comprend également le compilateur populaire GCC ). Il a plaidé pour une définition assez stricte du mouvement, permettant à chacun d'utiliser et de vendre du code open source, mais obligeant les développeurs à publier également leurs logiciels en open source (il a rédigé la licence GPL), généralement qualifiée de "restrictive").

Ce n'est qu'à la fin des années 1990 et au début des années 2000 que l'open source a vraiment commencé à secouer les choses. La publication du système d'exploitation Linux et du serveur web Apache a prouvé que l'open source pouvait être non seulement viable, mais aussi très fructueux. De grandes entreprises comme IBM et Red Hat ont reconnu le potentiel et ont commencé à investir dans des projets open source et à les soutenir.

L'open source est aujourd'hui omniprésent. Il est difficile de trouver un morceau de technologie qui n'ait pas été influencé d'une manière ou d'une autre par l'open source. Des systèmes d'exploitation mobiles et des infrastructures cloud à l'apprentissage automatique et à l'analyse des données, l'open source est devenu une partie intégrante du secteur technologique.

Introduction à l'industrie des sciences de la vie

Dans cet article, je souhaite aborder le développement de l'open source du point de vue d'un fournisseur de logiciels et de services dans le secteur des sciences de la vie. Bien qu'il existe de nombreux articles sur l'adoption générale des logiciels open source (et livres sur l'évaluation des projets en vue de leur déploiement) et des prévisions de marché relativement saines pour le marché des services open source (par exemple, ce rapport), il n'y a pas autant de contenu sur les contributions réelles à d'autres secteurs verticaux que le logiciel (par exemple, la biotechnologie ou la production).

D'après mon expérience, l'adoption des principes de l'open source dans d'autres secteurs est encore en retard par rapport à "l'industrie tech" (qui a commencé en quelque sorte à ne prendre en compte que l'électronique et la technologie logicielle). Certes, il est également difficile d'obtenir des financements dans l'industrie tech (bon article de James Turner),mais il existe de grandes fondations comme l'Apache Software Foundation ou la Linux Foundation. Le nombre de personnes qui utilisent par exemple un programme de serveur web pourrait au moins rendre envisageable un financement durable par des dons (par exemple par des sponsors GitHub ou Open Collective).

Dans des domaines de niche comme l'utilisation de logiciels open source dans le travail scientifique, la situation est plutôt mauvaise. Bien qu'il soit clair que les percées récentes n'auraient pas été possibles sans eux (voir cette analyse de la Chan Zuckerberg Initiative), la plupart des organismes publics de financement ne reconnaissent pas leur importance.

"Ils financent 50 groupes différents qui développent 50 algorithmes différents, mais ils ne paient pas un seul ingénieur logiciel." - Anne Carpenter

Ce n'est que récemment que des voix s'élèvent pour aborder le problème du financement des infrastructures logicielles pour la science. Comme le décrivent par exemple Adam Siepel ou Anna Nowogrodzki, les chercheurs doivent généralement programmer de nouveaux outils dans le cadre de leurs recherches sans être reconnus ou formés pour cela, et si les besoins de maintenance d'un projet open source augmentent - a fortiori s'il rencontre le succès -, les scientifiques n'auront peut-être pas d'autre choix que de cesser complètement leurs efforts, puisque seul le "travail scientifique pur" sera reconnu et financé.
Heureusement, les choses changent lentement, du moins dans le domaine scientifique. De grandes fondations privées américaines mettent en place des subventions spéciales, comme la subvention "Essential Open Source Software for Science" de l'Initiative Chan Zuckerberg. En outre, la National Science Foundation (NSF) a créé un programme approprié appelé "Pathways to Enable Open-Source Ecosystems (POSE)" (premières propositions en 2022).

En revanche, dans le secteur de la biotechnologie commerciale, il y a très peu d'activités de financement et de contributions aux efforts communs en matière de logiciels libres. Cela s'explique par deux facteurs principaux : le manque de concentration sur le développement de logiciels et l'absence de culture de partage.

Aaccent sur le développement de logiciels: traditionnellement, les logiciels et l'infrastructure informatique étaient considérés comme de simples centres de coûts et non comme des expertises créant un avantage concurrentiel. De nouvelles entreprises dans ce domaine modifient lentement cette dynamique avec une nouvelle génération de start-ups "Techbio" qui définissent le développement de logiciels comme une activité principale explicite.

Absence de culture du partage: nulle part ailleurs la protection de la propriété intellectuelle n'est aussi forte que dans le secteur de la biotechnologie, en particulier dans le développement de médicaments. Comparés aux brevets dans le secteur des logiciels, qui sont relativement sans valeur, leur valeur pour les entreprises pharmaceutiques est énorme et leur création pourrait être considérée comme leur "raison d'être". Il existe des efforts précompétitifs comme l'Alliance Pistoia. Néanmoins, je pense qu'il faut faire beaucoup plus pour favoriser le sentiment que le partage des outils et des infrastructures profite à tous.

L'"ambiance" dans le secteur change lentement, car de jeunes entreprises comme Colossal créent des spin-off de logiciels comme Form Bio et des membres de grandes entreprises pharmaceutiques comme Roche préconisent leur utilisation d'outils open source comme Arvados ou Camunda.

Stratégies pour le succès

Un projet est généralement lancé par un seul ou un petit nombre de contributeurs individuels. Des exemples dans le secteur de la biotechnologie sont MultiQC de Phil Ewels, PyLabRobot de Stefan Golas ou Poly de Timothy Stiles. L'impulsion initiale d'un nouveau projet provient généralement d'un besoin qui émerge dans différents contextes :

• Contexte du travail scientifique (financé indirectement par une bourse de recherche)
• Contexte d'un projet pour un client (éventuellement financé directement)
• Contexte du développement de produits (généralement financé par l'employeur)

Le travail initial est généralement inspirant et il n'est pas nécessaire de se soucier beaucoup de la durabilité à long terme des efforts. Malheureusement, la "phase de chiot mignon", comme Jacob Thornton l'a si bien décrit dans son exposé, prend fin au bout d'un moment et le projet doit être correctement entretenu - d'autant plus s'il est couronné de succès et que le nombre d'utilisateurs ne cesse d'augmenter. À un moment donné, vous voudrez être payé pour vos efforts, surtout si vous devez embaucher plus de personnes pour répondre à la demande.

Après quelques années passées à construire et à maintenir SiLA 2 (un standard de connectivité ouvert et un outil pour les instruments et logiciels scientifiques) et à observer le domaine de l'"open source dans les sciences de la vie", je ne peux qu'être d'accord avec Aaron Stannard: pour poursuivre son projet de manière durable, on ne peut pas compter sur des dons, mais on a besoin d'une offre commerciale - soit en tant que consultant indépendant, soit en tant qu'entreprise. Dans l'article d'Aaron, il expose les différents modèles de financement, que je cite ici :

• Prestations de services: Formation, conseil et vente d'assistance aux utilisateurs de vos logiciels. The Hyve est un bon exemple d'entreprise de conseil en outils open source pour la biologie.
• Offre de base ouverte: une offre de base gratuite et ouverte avec des fonctions "d'entreprise" propriétaires pour les clients payants. Les fonctions populaires sont par exemple le contrôle d'accès et la disponibilité d'audit.GitLab, une plateforme de gestion de logiciels (Git), en est un bon exemple.
• Licence: définition d'une licence libre pour l'utilisation open source non commerciale et d'une licence propriétaire pour l'utilisation commerciale du logiciel. Un exemple connu est l'outil Qt pour les interfaces utilisateur graphiques.
• Services gérés: Mise en place d'un service géré à l'aide d'un logiciel open source qui peut être vendu sous forme de plateforme ou de logiciel en tant que service (PaaS ou SaaS). Ce modèle est souvent combiné avec certaines fonctions propriétaires afin de simplifier la gestion. Un bon exemple dans le domaine de la bio-informatique est Netflow Tower.
• Réputation: Plutôt que de vendre directement quelque chose, une entreprise ou un individu peut utiliser le prestige d'une contribution à un projet communautaire pour attirer des clients ou des talents dans votre entreprise. C'est actuellement le modèle d'exploitation de l'entreprise pour laquelle je travaille : wega, où le projet SiLA a permis d'attirer de nouveaux clients et d'embaucher (plus d'informations ci-dessous).

De nombreux développeurs (moi y compris) penseraient que lorsqu'une partie du code est essentielle à son succès, une entreprise analyse ses dépendances et s'assure qu'elle est maintenue de manière durable. Malheureusement, d'innombrables fois, il s'est avéré que cette idée ne pourrait pas être plus éloignée de la vérité [note de bas de page : la dynamique me rappelle la Tragédie des biens communs]. La boîte à outils de sécurité OpenSSL en est un exemple typique : ce n'est qu'après la publication de la fameuse faille "Heartbleed" (dont le coût est estimé à 500 millions de dollars) que les dons sont passés de 2000 dollars par an à 9000 dollars, ce qui est manifestement loin d'être suffisant pour faire vivre ne serait-ce qu'un développeur, et encore moins les ressources dont un tel projet aurait besoin (Source). Comme toujours, XCKD illustre parfaitement la situation :

Le financement fragile des infrastructures modernes (XKCD)

Récemment, une faille de sécurité dans la célèbre bibliothèque de journalisation Java log4j a provoqué car elle affectait presque tous les systèmes et avait un mainteneur avec trois sponsors Github. Par la suite, Filippo Valsorda a écrit sur la nécessité de rémunérer directement et contractuellement les mainteneurs pour leur travail (Article) - et je suis d'accord avec lui. Néanmoins, je crains que de nombreux services d'approvisionnement ne comprennent pas ce cas pendant un certain temps.

Il existe des contre-exemples où Il existe des contre-exemples où des communautés se sont créées autour de projets qui se sont ancrés si profondément dans la chaîne de valeur des entreprises qui les utilisent qu'ils ont obtenu un financement durable, mais c'est généralement un chemin long et solitaire. Mis à part les célèbres projets Linux et Apache, Jupyter semble se porter raisonnablement bien, avec des dons importants de Microsoft pour son prédécesseur IPython et, plus tard, d'organisations publiques. Un autre exemple intéressant est celui du Robot Operating System (ROS), qui a commencé comme un projet de recherche, puis a fait partie d'une entreprise privée et fait désormais partie de l'Open Source Robotics Foundation, qui reçoit des fonds considérables de la part d'entreprises comme Amazon, Bosch ou Nvidia.

 

Open Source et standardisation

De nombreux secteurs industriels ont bénéficié de la standardisation des formats afin que la même solution puisse être utilisée dans différents contextes. Des exemples souvent cités sont les conteneurs d'expédition, les clés USB ou, en laboratoire, la spécification SBS pour les microplaques. Ces histoires motivent la création de nouvelles normes dans des domaines inexplorés, ce qui conduit souvent à plusieurs définitions concurrentes au départ. Cette situation est souvent tournée en dérision par une autre bande dessinée XKCD :

Un autre XKCD

En réfléchissant à ce qu'est une norme, j'ai réalisé que ce que nous appelons communément une norme est une documentation versionnée, approuvée par un comité "indépendant" comme l'ISO. En revanche, je dirais qu'une norme n'est en réalité qu'un ensemble de définitions qui sont le plus souvent utilisées dans un contexte/application donné. On peut citer par exemple l'API Amazon S3 utilisée par des services concurrents, les descriptions d'images Docker compatibles avec d'autres services de conteneurs (par exemple Singularity), ou le ROS déjà mentionné et ses interfaces de messagerie.

Les "normes gagnantes" sont simplement celles qui sont le plus souvent utilisées - et même s'il serait plus agréable pour un utilisateur d'avoir toujours une définition qui s'applique à tous, en réalité, au moins une poignée de définitions est nécessaire pour garantir une saine concurrence qui incite à l'amélioration continue.

Compte tenu de cette prise de conscience, tout logiciel pourrait être considéré comme un standard si une acceptation suffisante était obtenue. Pour garantir l'accessibilité et la maintenance continues de ces infrastructures standard, une organisation indépendante à but non lucratif est généralement créée et financée par les cotisations des membres et les dons. Parmi les exemples issus du secteur des sciences de la vie, on peut citer Open Microscopy Environment, SiLA ou LADS.

De nombreux efforts de normalisation échouent pour diverses raisons. Certaines d'entre elles peuvent être facilement atténuées avec une culture ouverte et des logiciels open source comme colonne vertébrale. Quelques règles à cet égard :

• L'adhésion sert uniquement à la prise de décision, pas à l'accès: Certaines fondations se concentrent trop sur l'incitation à l'adhésion en ne donnant aux membres (payants) qu'un accès aux définitions et aux fichiers sources. Cela entrave drastiquement l'adoption.
• Code d'implémentation dès le départ: Avant même qu'une première définition ne soit publiée, il doit y avoir (au moins) des applications librement accessibles (mieux encore, des applications à code source ouvert) qui utilisent les définitions dans des scénarios pertinents pour le secteur afin de tester les concepts.
• Création d'une communauté: Il doit être facile pour les personnes intéressées de voir les dernières discussions et de les rejoindre - simple au sens de quelques clics, sans entretien et sans formulaires d'inscription ! Il faut créer des plates-formes telles que des événements en face à face et des forums en ligne pour permettre aux membres d'échanger régulièrement leurs idées.

De telles règles devraient être établies le plus tôt possible, car les entreprises à but lucratif (sans principes d'open source) tenteront inévitablement de prendre l'avantage sur une norme à venir en excluant les nouveaux arrivants.

 

Avantages du développement ouvert

J'ai parlé de l'open source comme s'il allait de soi qu'il était avantageux - et je suis parti du principe que l'impact des projets précédents parlait de lui-même. Néanmoins, le développement fermé présente bien sûr des avantages, tels qu'un contrôle plus strictnote de bas de page : le modèle de développement un peu lâche de l'open source est bien décrit dans cet article révolutionnaire intitulé "The Cathedral and the Bazaar"]] et une monétisation plus facile. Quels sont donc les avantages concrets de l'ouverture d'une partie de votre propriété intellectuelle ?

En ce qui concerne les statistiques, vous trouverez de nombreux articles, par exemple de grands cabinets de conseil, comme celui-ci de McKinsey, qui montrent que les entreprises qui utilisent l'open source sont plus innovantes. Concrètement, je pense qu'il s'agit là des principaux avantages :

• Contributions de la communauté: les utilisateurs de votre logiciel apporteront une multitude de fonctionnalités et d'extensions avec lesquelles une seule entreprise ne peut pas rivaliser. Un excellent exemple est la différence entre les contributions au logiciel libre Stable Diffusion et l'alternative fermée DALL-E - comme l'a montré Yannic Kilcher.
• Meilleur retour d'information:si les utilisateurs peuvent analyser eux-mêmes le code et bricoler son fonctionnement interne, vous bénéficiez d'un retour d'information plus profond et plus rapide sur la qualité - ce qui peut conduire à des améliorations spectaculaires, notamment en ce qui concerne les aspects de sécurité. Une alternative à l'open sourcing de composants clés peut également consister à avoir au moins un accès ouvert (comme le récent phénomène ChatGPT, voir aussi l'article sur l'innovation centrée sur l'utilisateur d'Eric von Hippel).
• Réputation: comme nous l'avons déjà mentionné en tant que mécanisme de financement, la participation à des projets open source peut contribuer à maintenir ou à créer la réputation d'un leader d'opinion dans un domaine particulier - pour Wega, par exemple, ses contributions au SiLA ont renforcé son image d'expert en matière de numérisation des laboratoires. En outre, cela rend l'entreprise beaucoup plus attrayante en tant qu'employeur pour les futurs ingénieurs.

De nombreux chefs d'entreprise craignent de rendre quoi que ce soit open source, car ils pensent que cela signifie seulement qu'ils cèdent leur travail pour rien. Cette façon de penser ignore le bien le plus précieux que vous conservez - l'expertise. Bien sûr, ce capital peut aussi être volé (c'est-à-dire "détournement de talents"), mais lorsqu'il s'agit de talents, il faut de toute façon vivre avec ce risque.

L'aspect le plus important est toutefois bien résumé dans cet article: "Lorsque nous partageons nos ressources, notre travail et notre savoir-faire en matière d'open source, tout le monde en profite. Mais les entreprises qui en tirent le meilleur parti sont celles qui participent activement à des projets open source".

Il est préférable de se lancer dans un voyage open source sans avoir en tête un bénéfice direct, mais il est bon de se rendre compte qu'à long terme, le résultat final de votre entreprise en bénéficiera également. Je vous encourage à réfléchir aux domaines dans lesquels les initiatives open source pourraient avoir un sens dans votre entreprise.