One Maintainer Is All It Takes To Break A Project
Cette vidéo analyse la situation critique de nombreux projets GNOME laissés sans mainteneur après le départ de Christian Hergert de Red Hat, soulignant la fragilité des écosystèmes open source qui reposent souvent sur une seule personne.
SYNTHÈSE STRUCTURÉE
Le départ de Christian Hergert de Red Hat
Christian Hergert, ancien employé de Red Hat, a quitté l’entreprise après plusieurs refus de transfert vers le bureau français. Il a annoncé publiquement que tous les projets qu’il maintenait dans le cadre de son emploi ne seraient plus maintenus par lui. Comme il le dit : « I am not available to maintain, review, or support them in any capacity for the foreseeable future. » Il réside désormais en France sous un visa longue durée qui ne l’autorise pas à travailler.
La différence entre logiciel propriétaire et open source
L’intervenant souligne que dans le logiciel propriétaire, remplacer un développeur est généralement possible si l’entreprise a les moyens financiers. Dans l’open source, c’est plus complexe : « even in the case of popular distros, popular tools, foundational things that everybody relies on, and there should be a lot of people working on it, in a lot of cases, there is a singular person involved in everything. » Le simple fait de forker un projet, souvent suggéré, est rarement mis en pratique.
La liste des projets abandonnés
Hergert a publié une liste des projets critiques dont il était le seul mainteneur actif. Parmi eux :
- GTK Source View : fondation des éditeurs GTK, dernière modification réelle il y a des mois (traductions uniquement)
- Text editor : éditeur de texte principal de GNOME, dans le même état
- Ptyxis : terminal par défaut sur Fedora, Debian, Ubuntu, RHEL, etc., maintenu par une seule personne
- Sysprof : profileur système intégrant Linux perf, Mesa, GTK, etc.
- Builder : IDE officiel de GNOME
- Libpeas : système de plugins pour C, C++, Rust, Lua, Python, JavaScript
- Libdex : intégration de Futures, Fibers et io_uring
- GOM : liaison entre GObject et SQLite
- Manuals : lecteur de documentation
- D-Spy : introspection des connexions D-Bus
- Libmks : implémentation QEMU avec intégration DMA buff pour GTK
L’état réel des dépôts
L’intervenant examine chaque dépôt et constate un schéma récurrent : seules des traductions automatiques ou des commits mineurs sont effectués. Les issues ne sont plus fermées, les merge requests ne sont plus traitées. Il note : « Just because a project is really popular doesn’t mean that there is a bunch of people working on it. » La popularité n’est pas synonyme de main-d’œuvre active.
Les projets qui peuvent survivre sans maintenance active
Certains projets comme Template GLib, JSON RPC GLib ou Libpeas n’ont pas besoin de changements fréquents. L’intervenant explique : « This one’s probably going to be fine for a long while without anyone really actively maintaining it. » Ces projets sont stables et ne nécessitent que des mises à jour de dépendances pour rester compatibles avec les nouvelles versions de GNOME.
Le problème des projets « invisibles »
L’intervenant identifie un problème structurel : les développeurs préfèrent travailler sur des projets visibles (environnements de bureau, applications graphiques) plutôt que sur les bibliothèques fondamentales. Il explique : « if you make a change to, I don’t know, futures, fibers, and io_uring integration, even most developers are not really thinking about that. » Ces projets sont pourtant essentiels au fonctionnement de l’écosystème.
L’exemple de l’impression
Pour illustrer son propos, l’intervenant cite l’impression comme un domaine où peu de développeurs s’investissent : « printing is not something that most people are doing outside of like a corporate or education environment, so that already limits down the number of people who are even thinking about that being a problem. » Cela réduit encore le bassin de mainteneurs potentiels.
L’appel à l’action
L’intervenant encourage les développeurs à s’impliquer dans ces projets : « If you’re looking for something that you want to go and take over, something that actually needs someone involved in it, not just another developer in a really popular project, check out any of these projects here. » Il souligne que même une maintenance minimale (mise à jour des dépendances, alignement sur les nouvelles versions) serait bénéfique.
CONCEPTS CLÉS
- Sole maintainer : développeur unique responsable d’un projet open source, situation risquée pour la pérennité du projet
- Fork : copie d’un dépôt pour créer un projet indépendant, souvent suggéré mais rarement réalisé
- Foundational libraries : bibliothèques de base qui ne sont pas visibles mais sur lesquelles reposent de nombreux autres logiciels
- Translation commits : mises à jour de traduction qui ne modifient pas le code source, souvent le seul signe de vie d’un projet abandonné
- Long stay visitor visa : visa de long séjour qui n’autorise pas le travail, situation de Christian Hergert
CONCLUSION
Le message principal est que l’open source repose sur un équilibre fragile : des projets critiques sont maintenus par une seule personne, souvent bénévolement ou dans le cadre d’un emploi qui peut prendre fin. La popularité d’un projet ne garantit pas sa maintenance. Les développeurs et les organisations qui dépendent de ces bibliothèques doivent s’impliquer activement, ne serait-ce que pour des tâches de maintenance minimales. Comme le dit l’intervenant : « the fact that open source even works to begin with, the fact that there are people who want to work on these random little foundational libraries, genuinely insane that we’ve come this far. » Sans un engagement collectif, ces projets risquent de tomber en désuétude, menaçant l’ensemble de l’écosystème.