- De récentes couvertures médiatiques ont critiqué l’usage de logiciels open source créés par un développeur russe
- En réalité, la grande majorité des projets open source sont gérés par un seul mainteneur individuel
- Pas seulement NPM, mais aussi de nombreux autres écosystèmes comptent énormément de cas où un seul mainteneur gère des packages populaires
- Le problème de cette structure, c’est la charge excessive sur une seule personne et le risque sur la chaîne d’approvisionnement
- Le fond du problème n’est pas la nationalité, mais le manque très concret de ressources et de soutien
Introduction : l’open source et la controverse récente
- The Register a publié un article mettant en cause la dépendance du département américain de la Défense à un utilitaire open source créé par un développeur russe
- Le développeur open source concerné fait l’objet de critiques injustifiées
- Le contenu de l’article repose sur une mauvaise compréhension de la réalité de l’open source, et en souligne les limites de cette approche
La réalité de l’open source : la structure du « une seule personne »
- D’après les données, presque tous les projets open source sont gérés par une seule personne
- Le projet ecosyste.ms recense environ 11,8 millions de projets open source dans ses données
- Parmi eux, environ 7 millions ont un seul mainteneur
- Pour les quelque 4 millions de projets restants, le nombre de mainteneurs est inconnu, mais on estime qu’une grande partie n’en a là aussi qu’un seul
- Seule une infime minorité de projets compte des centaines de mainteneurs
Même les projets populaires ne font pas exception
- Beaucoup pensent que « les projets open source importants ou populaires sont probablement gérés par plusieurs personnes », mais en réalité, les grands écosystèmes comme NPM ne sont pas différents
- L’écosystème NPM compte plus de 4 millions de projets à mainteneur unique
- Même parmi les packages NPM téléchargés plus d’un million de fois par mois, environ la moitié sont exploités par un seul mainteneur
- En relevant le seuil à 1 milliard de téléchargements, on observe quelques différences, mais il existe toujours des packages gérés par une seule personne
- Les quelque 4 millions de projets à mainteneur unique sur NPM sont en fait gérés par environ 900 000 personnes (autrement dit, une même personne porte plusieurs projets)
Le cœur du problème : non pas le pays, mais le manque de ressources
- Le poids économique de l’open source constitue une infrastructure de plusieurs milliers de milliards de dollars (8,8 billions de dollars selon une étude de Harvard)
- La plupart des projets à mainteneur unique manquent de ressources, avec un risque réel pour la chaîne d’approvisionnement
- Le risque principal n’est pas un pays, mais « un seul mainteneur » qui travaille trop et n’est pas correctement rémunéré
- Le fait que les médias ciblent des mainteneurs individuels n’apporte aucune solution
Conclusion et points d’action
- La cause du problème actuel réside dans la structure à mainteneur unique, et il est inutile de se focaliser sur les pays
- Diaboliser ou traquer les mainteneurs individuels n’est pas une solution
- Le problème est complexe et il n’existe pas de réponse immédiate
- Au lieu de désigner des mainteneurs individuels à la vindicte, il faut réfléchir aux problèmes structurels et aux moyens de soutien
1 commentaires
Avis Hacker News
J’ai l’impression qu’il y a beaucoup de malentendus, dans la communauté logicielle, sur ce sujet : en réalité, le risque de supply chain relève davantage de la gouvernance que d’un problème purement logiciel ou d’ingénierie
Même sans mauvaise intention de la part de quiconque, un projet peut présenter un risque de supply chain, et les personnes chargées de l’évaluer n’ont pas toutes la même vision de la sécurité ni les mêmes critères
Le DoD (département de la Défense des États-Unis) évalue le risque d’un point de vue totalement différent de celui d’un développeur ordinaire, et beaucoup de projets maintenus par une seule personne sont considérés comme risqués simplement parce qu’il n’y a qu’un seul responsable
Quand le « facteur bus » est de 1, c’est en soi un risque de supply chain
La plupart des gens ne pensent pas à un contexte de guerre quand ils choisissent un package, mais l’armée, elle, peut très bien le faire
Si une guerre éclate, même des projets open source normalement gérés de façon autonome peuvent voir leur situation changer brutalement
En pratique, comme beaucoup de pays peuvent en temps de guerre exiger par la loi la coopération d’entreprises privées ou de projets individuels, certains organismes (comme le DoD) intègrent aussi ce type de scénario dans leur calcul du risque de sécurité
En temps de guerre, ils ne fonctionneraient pas avec une logique du type : « si seulement il y avait au moins une autre personne en qui nous n’avons absolument pas confiance »
Il y avait des données disant qu’il existe 4 millions de projets solo sur NPM et qu’environ 900 000 personnes les maintiennent ; je me demandais si c’était vraiment le point important
autrement dit, la majeure partie de la valeur économique de l’open source (estimée par Harvard à 8,8 billions de dollars) est produite par des « projets solo », et pourtant aucun de leurs mainteneurs ne reçoit de ressources dignes de ce nom
Dans les discussions sur le risque de supply chain, le vrai danger, ce sont les mainteneurs isolés, sous-payés et surchargés de travail
Le pays d’où ils viennent n’est en réalité pas si important que ça
Je me demande s’il existe des statistiques sur ce qui se passe quand un mainteneur solo a soudainement un accident ou abandonne le projet
Avec autant de données, ça semblerait valoir le coup d’étudier la question
J’aimerais savoir si un nouveau développeur reprend le projet, s’il est remplacé par un autre projet similaire, ou s’il disparaît complètement
En pratique, c’est plus souvent le cas du « mainteneur qui perd l’intérêt ou manque de temps et lâche l’affaire » que celui du vrai accident de bus
Les scénarios fréquents sont alors :
La force de l’open source, c’est que même si le créateur disparaît, devient problématique ou change la licence, quelqu’un peut toujours forker et faire survivre le projet
À l’inverse, avec un logiciel propriétaire, si le créateur — entreprise ou individu — disparaît ou change le produit, c’est tout simplement terminé
Au mieux, il faut trouver une alternative
C’est d’ailleurs aussi pour ça que je ne dirige pas Netflix
Au final, tout dépend du nombre d’utilisateurs, de la complexité de la base de code et de l’existence ou non de substituts
C’est une histoire bien plus étrange qu’un simple « il s’est fait renverser par un bus », et le projet a fini par disparaître
Même dans les projets maintenus par plus de deux personnes, la majorité des commits est en général quand même réalisée par une seule personne
Lien connexe : https://github.com/11ty/eleventy/graphs/contributors
C’est dommage : un simple contrôle de l’activité aurait suffi pour constater immédiatement que, sur l’ensemble des projets, la moitié n’avaient plus aucun mainteneur
Autrement dit, pas besoin de nettoyage, de tuning ni d’ajustement : on peut juste le laisser tel quel
Souvent, le problème vient plutôt des mises à jour que du projet lui-même
Le fait que le DoD utilise node m’inquiète davantage
J’ai l’impression qu’une plateforme comme npm offre une surface d’attaque bien trop grande
Le DoD est l’une des plus grandes organisations du monde, donc il a aussi quantité de tâches comme l’envoi de newsletters ou des pages web pour réserver une visite de camp des Boy Scouts
Pour ce genre de choses, utiliser node ne me semble pas problématique
Ces systèmes sont exploités séparément des systèmes critiques comme le lancement de missiles, et même si une simple page d’inscription à un événement était compromise, ce ne serait pas bien grave
Je pense que beaucoup de projets GitHub tenus par une seule personne ne sont en fait que des expériences personnelles ou des blagues du genre « hello world »
Je ne sais pas pour npm, mais PyPI regorge aussi d’exemples comparables
J’ai cliqué sur « browse projects » et je suis tombé sur ça : https://pypi.org/project/helloworld-eduardo/
Franchement, il faudrait être sacrément ivre pour envisager d’utiliser ça en production
Le DoD est particulièrement doué pour obtenir quelque chose gratuitement en convainquant tout le monde que « c’est gagnant pour tous », pour finir ensuite par payer un prestataire externe
Il était question d’un « package maintenu par une seule personne et téléchargé plus d’un milliard de fois », mais je me demande ce que cela désigne exactement
J’ai entendu pas mal de bonnes choses sur le travail fait par un certain Linus, et j’ai l’impression d’en avoir beaucoup utilisé en pratique
Comme il vient d’un pays frontalier de la Russie, je me demande si c’est aussi le genre de critère dont il faudrait se préoccuper
Je développe dans l’open source depuis des décennies, le plus souvent seul ou parfois avec une équipe de bénévoles
Ceux qui ont déjà travaillé avec des équipes bénévoles savent que ce n’est vraiment pas simple
Bien sûr, ce n’est pas totalement impossible, mais ça fonctionne bien beaucoup moins souvent qu’on ne l’imagine
Quand ça marche, c’est généralement soit parce qu’il y a un « BDFL (dictateur bienveillant à vie) », soit parce que tout le monde avance vers un objectif commun
Dans mon cas, c’était presque toujours plutôt la deuxième forme
Son père a même vécu quelques années à Moscou