Que se passe-t-il quand un projet open source perd son leader

Quand Ryan Dahl a pris du recul par rapport à Node.js, le projet a survécu, mais il a fallu des années de restructuration de la gouvernance, un fork (io.js) et une réconciliation avant qu'il ne se stabilise. Quand Guido van Rossum a démissionné de son poste de BDFL (« Benevolent Dictator For Life », dictateur bienveillant à vie) de Python, la communauté a passé des mois à débattre de modèles de gouvernance avant d'opter pour un conseil de direction. Quand le projet Deno a dû faire face à ses propres questions de leadership, les répercussions ont touché chaque développeur qui avait misé sur ce runtime.

Ce ne sont pas des cas isolés. C'est une caractéristique structurelle du développement open source. La plupart des projets open source importants dépendent d'un tout petit nombre de personnes, souvent d'une seule, bien plus que leurs utilisateurs ne l'imaginent. Quand cette personne part, s'épuise, change de priorités ou prend une décision controversée, le projet traverse une crise existentielle qu'aucun nombre d'étoiles GitHub ne peut empêcher.

Le problème du facteur bus

Le « bus factor », c'est-à-dire le nombre de personnes qu'un bus devrait renverser pour que le projet s'effondre, est dramatiquement bas pour la plupart des projets open source. Une étude de 2015 a montré que plus de 60 % des paquets npm n'avaient qu'un seul mainteneur. Une analyse plus récente de l'infrastructure open source critique a révélé que de nombreux projets comptant des millions de dépendants en aval sont maintenus par une ou deux personnes, souvent bénévolement, en dehors de leurs heures de travail.

Ce n'est pas un problème hypothétique. OpenSSL, la bibliothèque qui sécurisait la majeure partie du trafic chiffré de l'internet, était principalement maintenue par deux personnes qui y travaillaient sur leur temps libre au moment où la faille Heartbleed a été découverte. Left-pad, un paquet npm trivial de 11 lignes, a cassé des milliers de builds quand son auteur l'a supprimé. Core-js, téléchargé plus de 25 millions de fois par semaine, est maintenu par un seul développeur qui a publiquement expliqué qu'il avait à peine de quoi se nourrir.

Le schéma est toujours le même : un projet critique naît de l'initiative d'une personne passionnée, gagne en adoption, devient une infrastructure dont dépendent des millions d'utilisateurs, et pourtant la charge de maintenance reste sur les épaules de la même ou des deux mêmes personnes. L'importance du projet croît de façon exponentielle. Son soutien, lui, ne suit pas.

Modèles de gouvernance et leurs compromis

Les projets open source gèrent leur gouvernance de quelques façons distinctes, chacune avec des forces et des modes d'échec prévisibles.

Le modèle BDFL

Une seule personne prend les décisions finales. Python (Guido van Rossum), Linux (Linus Torvalds), Ruby (Matz) : les projets les plus réussis ont souvent un leader technique fort, dont le goût et le jugement façonnent le projet. L'avantage est clair : une direction nette, une vision cohérente et des décisions rapides. Le BDFL peut dire « non » aux fonctionnalités qui ne collent pas, et le projet reste concentré.

Le mode d'échec est tout aussi clair : le BDFL part, et il n'existe aucun plan de succession. La transition de Python après la démission de Guido a été chaotique, malgré des décennies de construction de la communauté. Les projets dont la communauté est moins impliquée meurent souvent tout simplement quand leur BDFL passe à autre chose.

Le modèle fondation

Des projets comme Apache, Eclipse ou la Linux Foundation reposent sur des fondations à but non lucratif dotées de structures de gouvernance formelles : comités techniques de pilotage, élections des committers, processus de décision. Cela apporte une continuité institutionnelle : le projet survit aux départs individuels parce que la structure, elle, perdure.

Le compromis, c'est la bureaucratie et les jeux politiques. La gouvernance d'une fondation peut être lente, conflictuelle et capturée par des intérêts industriels. Certains développeurs trouvent le processus des comités étouffant, comparé à l'agilité d'un projet piloté par un BDFL. Le pire scénario : une fondation où la gouvernance devient davantage une affaire de politique interne que de mérite technique.

Le modèle sponsor industriel

React (Meta), Go (Google), Rust (initialement Mozilla, aujourd'hui sa propre fondation), TypeScript (Microsoft) : beaucoup de grands projets sont parrainés par des entreprises qui emploient les principaux mainteneurs. Cela règle le problème du financement : les mainteneurs sont payés, peuvent travailler à temps plein, et le projet profite des ressources d'ingénierie de l'entreprise.

Le risque, c'est l'alignement. Les priorités d'une entreprise évoluent. Mozilla a licencié l'équipe Rust. Google a déprioritisé et sous-financé des projets open source quand son focus business a changé. Quand les intérêts stratégiques d'une entreprise divergent de ceux de la communauté, les frictions sont inévitables. La tendance récente à voir des sponsors industriels modifier les licences de leurs projets (Redis, Terraform, Elastic) montre à quel point ce modèle peut être fragile.

Quand les forks sont sains

Le fork, qui consiste à créer une copie concurrente d'un projet, est souvent perçu comme un signe d'échec. Pourtant, dans l'open source, c'est en réalité la soupape de sécurité ultime. Quand le leadership défaille, les forks permettent à la communauté de continuer sans dépendre des mainteneurs d'origine.

Le fork io.js de Node.js a poussé Node vers un modèle de gouvernance plus ouvert et des cycles de publication plus rapides. Quand les projets ont fusionné, Node en a profité. LibreOffice, né d'un fork d'OpenOffice.org, a sauvé le projet du désintérêt grandissant de Sun puis d'Oracle. MariaDB, issu d'un fork de MySQL après le rachat par Oracle, reste l'alternative portée par la communauté.

Plus récemment, les changements de licence ont déclenché des forks productifs. Quand Elastic a modifié la licence d'Elasticsearch, Amazon en a forké la version OpenSearch. Quand HashiCorp a changé celle de Terraform, la communauté a forké le projet sous le nom OpenTofu, sous l'égide de la Linux Foundation. Ces forks existent parce que le droit de forker est le contre-pouvoir ultime de la communauté face au leadership d'un projet.

Le point clé : un fork fonctionne le mieux quand c'est la communauté, et pas seulement le code, qui se sépare proprement. Un fork porté par des mainteneurs actifs et soutenu par la communauté prospère. Un fork lancé par un développeur frustré que personne ne suit ne fait qu'ajouter de la confusion.

La spirale de l'épuisement

La plupart des crises de leadership dans l'open source ne commencent pas par une sortie spectaculaire. Elles commencent par l'épuisement : l'érosion lente de la capacité et de l'enthousiasme d'un mainteneur, sous le poids des tickets, des pull requests, des demandes de fonctionnalités et des utilisateurs qui se croient tout permis.

La dynamique est prévisible. Un mainteneur crée quelque chose d'utile. Des utilisateurs arrivent. Avec eux viennent les rapports de bugs, les demandes de fonctionnalités, les questions de support et les exigences. Le mainteneur, qui se sent responsable, essaie de tout traiter. Le volume dépasse sa capacité. Il commence à redouter ses notifications. Il répond plus lentement, puis plus sèchement, puis plus du tout. Finalement, il disparaît, et le projet entre dans une période de maintenance zombie : techniquement vivant, en pratique abandonné.

L'épuisement d'un mainteneur open source n'est pas un échec personnel. C'est un problème structurel : les projets génèrent une demande illimitée en temps et en attention, confiée à un nombre fini de personnes, sans mécanisme intégré pour gérer cette demande.

Certains mainteneurs ont trouvé des moyens de tenir : des limites strictes sur les délais de réponse, la délégation du tri à des membres de la communauté, une maintenance rémunérée via GitHub Sponsors ou Open Collective, ou simplement l'acceptation de délais de réponse plus longs. Mais tout cela suppose de résister consciemment à la pression d'une disponibilité permanente, ce qui va à l'encontre de la culture de nombreuses communautés open source.

À quoi ressemble une succession saine

Quelques projets ont bien géré leurs changements de leadership, et ils partagent des schémas communs.

• Une connaissance distribuée, pas seulement du code distribué. Le « savoir tribal » du projet, c'est-à-dire les raisons de certaines décisions, les alternatives envisagées et les principes de conception, est documenté et ne reste pas dans la tête d'une seule personne. Les Architecture Decision Records (ADR) et les RFC détaillées remplissent ce rôle.
• Plusieurs personnes ayant accès en écriture et l'autorité de publication. Si une seule personne peut publier une version, cette personne est un point de défaillance unique. Les projets sains comptent au moins 3 à 5 personnes capables de publier de nouvelles versions de façon indépendante.
• Des documents de gouvernance explicites. Comment les décisions sont-elles prises ? Qui a autorité sur quoi ? Comment ajoute-t-on de nouveaux mainteneurs ? Les projets qui répondent à ces questions avant une crise gèrent mieux la succession que ceux qui improvisent.
• Des transitions progressives, pas des départs soudains. Les meilleures transitions de leadership surviennent quand le leader sortant réduit délibérément son implication sur plusieurs mois, en accompagnant ses successeurs et en transférant explicitement l'autorité. Les départs brutaux, même bien intentionnés, créent des vides.
• Une pérennité financière. Les projets disposant d'un financement fiable (via des fondations, des sponsors industriels ou un financement communautaire) survivent mieux aux transitions, car les nouveaux mainteneurs peuvent être rémunérés pour leur temps. Demander à quelqu'un d'hériter d'un travail à temps plein non rémunéré, c'est une proposition difficile à accepter.

Ce que les utilisateurs et les entreprises devraient faire

Si votre entreprise dépend de logiciels open source, et c'est le cas, vous avez tout intérêt à la bonne santé des projets dont vous dépendez. Quelques étapes concrètes :

1. Auditez le bus factor de vos dépendances. Regardez les projets open source critiques de votre stack. Combien de mainteneurs actifs ont-ils ? Quand a eu lieu la dernière version ? À quelle vitesse les failles de sécurité sont-elles corrigées ? Un projet avec un seul mainteneur et une faille de sécurité vieille de six mois est un risque dont vous devriez avoir connaissance.
2. Financez ce que vous utilisez. Si un projet est critique pour votre activité, contribuez à son financement. GitHub Sponsors, Open Collective et Tidelift proposent des mécanismes pour cela. Le coût de la rémunération d'un mainteneur est dérisoire comparé à celui d'une dépendance critique qui n'est plus maintenue.
3. Contribuez en amont. Corrections de bugs, améliorations de la documentation, tri des tickets : tout cela allège la charge du mainteneur et donne à votre équipe une bonne familiarité avec la base de code. Si le projet a besoin de nouveaux mainteneurs un jour, vous serez en position de vous proposer.
4. Prévoyez un plan de secours. Pour les dépendances critiques, sachez ce que vous feriez si le projet était abandonné. Pouvez-vous le forker et le maintenir ? Existe-t-il une alternative vers laquelle migrer ? Le moment pour répondre à ces questions, c'est avant d'en avoir besoin.

La gouvernance open source n'est pas un travail glamour. Elle ne fait pas la une et ne rapporte pas d'étoiles GitHub. Pourtant, la différence entre un projet qui survit au départ de son fondateur et un projet qui ne survit pas tient presque toujours à la gouvernance : ce travail austère et structurel qui consiste à documenter les décisions, répartir l'autorité et préparer la succession. Les projets qui durent sont ceux qui bâtissent des institutions, pas seulement des logiciels.