Le monde de l’open source avant GitHub

• Avant que GitHub ne s’impose comme l’infrastructure sociale de l’open source, les développeurs géraient leurs projets sur une infrastructure qu’ils exploitaient eux-mêmes — Trac, dépôts Subversion, listes de diffusion, etc. —, et l’ajout de dépendances impliquait beaucoup de friction et de prudence
• GitHub a radicalement simplifié la création, la découverte et la contribution aux projets, tout en standardisant le suivi d’issues, les pull requests, la CI, etc., jusqu’à jouer aussi un rôle d’archive pour l’open source
• Avec l’essor des écosystèmes de packages comme npm, une explosion des micro-dépendances s’est produite, et GitHub est devenu un pilier central du système de confiance ; mais aujourd’hui, cette confiance s’érode sous l’effet de l’instabilité, d’une orientation produit confuse et du bruit lié à l’IA
• Ghostty s’en va lui aussi, et des projets comme Strudel et Tenacity migrent vers Codeberg ; si la décentralisation renforce l’autonomie, elle comporte aussi un risque de perte du contexte social — issues, revues, avis de sécurité, etc.
• Alors que des signes récents montrent un affaiblissement de la centralité de GitHub, l’importance d’archives publiques capables de préserver la mémoire tout en réduisant la dépendance grandit. La prochaine époque de l’open source devra conserver la mémoire tout en diminuant les dépendances

---

L’environnement open source avant GitHub

• Avant GitHub, le nombre de projets réellement fiables restait limité, et la réputation ainsi que la pérennité de chaque projet étaient directement liées au choix des dépendances
• Une dépendance n’était pas seulement un nom de package : elle incluait aussi l’histoire du projet, son site web, ses mainteneurs, son processus de publication et le contexte de sa communauté
• Les grands projets exploitaient souvent leur propre infrastructure, tandis que les plus petits étaient parfois hébergés sur des serveurs universitaires ou sur SourceForge
• Il existait une friction, comme dans le processus de packaging Debian où l’on examinait jusqu’aux licences et aux en-têtes de copyright, et cette friction faisait elle aussi partie de l’évaluation de la confiance

Le paradoxe de l’infrastructure autoexploitée et du contrôle de version distribué

• Les premiers projets open source tournaient souvent sur des serveurs hébergeant directement Trac, Subversion, des tarballs et de la documentation
• Il existait aussi des structures où plusieurs projets partageaient les coûts du serveur et la charge d’exploitation de Subversion, Trac et des listes de diffusion, comme chez Pocoo
• Subversion étant un dépôt centralisé, l’exploitation du serveur allait de soi, et le foyer d’un projet était physiquement bien défini par un nom d’hôte, un répertoire, une instance Trac ou des archives de listes de diffusion
• Mercurial et Git étaient des systèmes distribués où chacun pouvait posséder le dépôt complet, les branches et l’historique, mais dans la pratique, le centre de gravité s’est de nouveau déplacé vers GitHub
• Après la victoire des systèmes de gestion de versions distribués, le fait que le monde entier se soit standardisé sur un seul immense service centralisé reste l’une des grandes ironies de l’open source moderne

Ce que GitHub a changé

• GitHub a facilité la création et la découverte de projets, et a rendu le flux de contribution plus compréhensible, même pour les personnes sans expérience des listes de diffusion de développement
• En proposant un suivi d’issues, des pull requests, des pages de release, un wiki, des pages d’organisation, une API, des webhooks, puis plus tard de la CI, GitHub a changé les valeurs par défaut de la collaboration publique
• La collaboration open source s’est généralisée sous une forme reposant sur un historique visible et des discussions visibles
• Pendant un temps, GitHub a servi de choix par défaut très raisonnable pour publier des projets open source
• Comme le montre sa politique visant à maintenir l’accessibilité de GitHub dans des pays visés par des sanctions américaines, cette centralisation allait au-delà du simple hébergement et jouait aussi le rôle d’infrastructure publique accessible

GitHub comme archive

• L’une des fonctions les moins mises en avant de GitHub était son rôle d’archive : même les projets abandonnés restaient trouvables, à la manière d’un index des biens communs logiciels
• Les forks, les anciennes issues et les archives de discussion restaient disponibles, et la centralisation créait ainsi une mémoire découvrable
• À l’inverse, avant les grandes plateformes, il était courant que des fichiers de projet et des services disparaissent avec l’expiration d’un domaine personnel, l’arrêt d’un VPS ou l’absence du développeur
• Comme pour certains projets anciens dont seules les métadonnées subsistent sur PyPI tandis que le package réel a disparu, il arrivait que l’adresse du dépôt pointe vers un vieux serveur personnel désormais hors ligne
• Beaucoup de projets du passé ont fini par dépendre fortement de moyens de préservation externes comme Internet Archive

npm et l’explosion des dépendances

• Le problème des micro-dépendances ne s’est pas limité à la multiplication de petits packages : il s’est aggravé parce que GitHub et npm donnaient l’impression de faire quasiment disparaître le coût de création, de publication, de recherche, d’installation et de dépendance
• Avant GitHub, la confiance et la pérennité étaient des critères indispensables dans le choix d’une dépendance, et comme il était difficile de se fier à la disponibilité d’autres services, le vendoring — inclure directement le code dans le dépôt — était aussi courant
• Avant l’ère des API, il était également pénible de maintenir des scripts récupérant du code externe, et cette friction poussait à réfléchir une fois de plus avant d’ajouter une dépendance
• Dans un écosystème à la npm, le graphe de packages peut croître plus vite que ce qu’un humain est capable de raisonner
• GitHub a même tenté de répondre aux problèmes d’ambiguïté sur l’état des licences en révisant ses conditions d’utilisation
• Une culture s’est installée où, même lorsqu’on dépend d’un petit package, on vérifie sur GitHub l’existence du dépôt et des mainteneurs, les issues, les changements récents, son usage par d’autres projets, ainsi que la cohérence entre le code et la description du package
• GitHub est devenu l’un des rares systèmes à assurer aussi le trusted publishing pour des registres comme npm, si bien qu’un affaiblissement de la confiance envers GitHub affecte non seulement l’hébergement du code source, mais aussi l’ensemble de la culture de la supply chain

L’affaiblissement de GitHub et les premiers signes de migration

• GitHub perd actuellement une partie de son caractère inévitable en raison de son instabilité, des changements produit répétés, du bruit autour de Copilot AI et d’un leadership peu clair
• Placé au cœur de la vague du agentic coding, GitHub subit aussi une pression interne accrue, mais la situation actuelle est décrite comme marquée par une forte absence de leadership
• Pendant un temps, quitter GitHub relevait surtout du geste symbolique, mais désormais, des projets influents envisagent publiquement une migration ou la mettent déjà en œuvre
• L’annonce du départ de Ghostty de GitHub est perçue comme un signal fort, même si la destination finale n’est pas encore clairement établie
• Strudel moved to Codeberg
• Tenacity moved to Codeberg
• Même si cela ne suffit peut-être pas encore à provoquer un basculement de fond, une tendance se dessine : on recommence à voir plus souvent des espaces d’hébergement hors de GitHub
• Git ayant été conçu à l’origine pour fonctionner avec plusieurs foyers, mettre fin à une situation où une seule entreprise sert de maison par défaut à tout le monde pourrait être bénéfique pour l’open source

Le coût d’un retour au distribué

• Revenir à plusieurs forges, plusieurs serveurs et plusieurs petites communautés peut renforcer la décentralisation et l’autonomie, tout en réduisant la dépendance aux changements de direction chez Microsoft
• Cela présente aussi l’avantage de permettre à chaque communauté de choisir son propre workflow
• Le problème actuel du suivi d’issues de Pi montre que certains choix produit de GitHub conduisent aujourd’hui à des résultats mal adaptés à la réalité de la maintenance open source
• GitHub révèle un design davantage centré sur l’engagement que sur la santé mentale des mainteneurs
• En revanche, migrer vers une forge auto-hébergée, un serveur Mercurial maison ou un serveur cgit peut bien distribuer le code lui-même, mais le contexte social peut, lui, se disperser très facilement
• Les issues, les revues, les discussions de conception, les notes de version, les avis de sécurité et les anciens tarballs disparaissent bien plus facilement qu’on ne le pense
• Les listes de diffusion qui portaient autrefois ce contexte n’ont pas suivi les exigences actuelles, et leur expérience utilisateur laisse à désirer
• Le caractère oubliable du logiciel peut avoir un effet purificateur, mais si le risque de perte augmente, il faut aussi repenser la manière dont on exploite réellement les systèmes de gestion de versions distribués

Ce qu’il faut, c’est une archive publique

• Que GitHub reste ou que les projets partent ailleurs, l’open source a besoin d’une archive publique, ennuyeuse mais stable
• Il faut une structure non pas conçue pour gagner sur le marché de la productivité des développeurs, mais pour empêcher la disparition de logiciels importants
• Elle doit reposer sur une base soutenable à long terme, comme un endowment ou des financements publics
• Les archives du code source, les artefacts de release, les métadonnées et le contexte des projets doivent être préservés dans un lieu qui ne dépende ni du modèle économique ni de l’humeur du leadership d’une seule entreprise
• En devenant le centre de l’activité open source, GitHub s’est retrouvé à jouer aussi, par accident, ce rôle d’archive ; mais si sa centralité s’affaiblit, on ne peut pas supposer que cette fonction se maintiendra automatiquement
• Les serveurs personnels et la seule bonne volonté n’ont pas suffi à garantir la préservation, et la fermeture de plateformes comme Google Code ou Bitbucket a déjà mis en évidence ce vide
• Les systèmes à venir doivent aller dans le sens de préserver la mémoire tout en réduisant la dépendance ; il faut faciliter les migrations de projets, la mise en miroir du contexte social et la conservation des releases, afin qu’une dérive d’une seule entreprise ne se transforme pas facilement en crise culturelle pour tout l’écosystème
• Il subsiste ainsi une tension : personne ne veut revenir aux liens de tarballs brisés et aux instances Trac abandonnées, mais on ne peut pas non plus accepter la structure centrée sur GitHub des vingt dernières années comme un état normal permanent

[GN⁺]

Réactions sur Hacker News

• À mon avis, l’un des plus grands changements apportés par GitHub, c’est qu’il a introduit une structure centrée sur les personnes plutôt que centrée sur les projets
  Le simple fait de pouvoir attacher un dépôt directement à mon nom et créer rapidement quelque chose donnait une sensation de liberté bien plus grande que la procédure lourde de SourceForge, où il fallait choisir et réserver un nom de projet, puis mettre en place un dépôt CVS ou SVN, un site web, une mailing list et un issue tracker
  Cela réduisait énormément la charge mentale du type « ce n’est qu’un truc bricolé vite fait »
  GitHub n’a pas non plus fourni d’un seul coup l’issue tracker, les PR, les pages de release, le wiki, les pages d’organisation, l’API, les webhooks et la CI
  À l’époque, il n’y avait même pas de fonction d’organisation, donc on créait parfois un nouveau compte utilisateur pour imiter une organisation, et il m’est arrivé de retarder l’adoption d’un bug tracker séparé en me disant « GitHub va sûrement sortir ça dans quelques mois », pour finalement tout gérer dans un fichier texte du dépôt
• Je regrette encore que, dans la plupart des projets, Git ait pris le dessus sur Fossil
  Pour d’immenses bases de code comme le noyau Linux, Git a sans doute des avantages de performance, mais la grande majorité des projets n’atteint presque jamais les limites de performance d’un VCS
  Le fait que Fossil versionne dans un seul fichier, avec le code, des outils intégrés comme le wiki, le forum ou les tickets est vraiment très utile
  Dans le travail en freelance, Fossil permet de retrouver très facilement le contexte du projet, les détails et les accords passés avec le client
  Pas besoin d’encombrer la base de code ni de fouiller partout dans les e-mails et les outils de notes pour reconstituer le contexte
  Je n’aime pas non plus l’idée qu’on ne peut plus rien changer sous prétexte que Git est trop profondément ancré culturellement
  La transition vers Fossil est simple, et même en venant de Git le workflow est plutôt plus simple
  • On aurait aussi pu construire des outils similaires au-dessus du protocole et des dépôts Git, et il y a effectivement eu des choses comme la revue de code distribuée
    Simplement, la majorité des gens n’en voulait pas vraiment, donc ça n’a pas pris
    Il y a aussi pas mal de cas où stocker les issues avec le projet pose problème
    Si un client envoie beaucoup de captures d’écran ou de vidéos pour reproduire un bug, le dépôt grossit très vite, et si tout est lié au code, tout le monde doit récupérer localement un dépôt énorme juste pour consulter les tickets, ce qui devient très pénible
    Au final, on finit facilement par conclure « n’utilisons pas ça, c’est trop compliqué et ça ne fait que gonfler le dépôt »
    La plupart des fonctions de Fossil semblent pouvoir être implémentées sur un backend Git, et le wiki ou les issues pourraient vivre dans une couche de branches parallèles distincte
  • Le timing a probablement aussi joué
    Si je me souviens bien, à une époque où Git était déjà stable et utilisable au quotidien, Fossil obligeait encore parfois à recréer entièrement le dépôt lors d’une mise à jour de version
    L’UX de Git était pire, et peut encore l’être aujourd’hui, mais au moins ça fonctionnait, avec une vraie impression d’outil prêt pour la prod
    Et comme l’un des plus grands projets open source du monde l’utilisait, l’écart de perception a été décisif
  • C’est peut-être justement le bon moment pour que quelqu’un rachète fossilhub.com et relance une nouvelle communauté
  • Je me demande quand même pourquoi Git est plus rapide sur les gros dépôts
    Cela dit, pendant un temps, j’ai le souvenir que cet avantage se voyait peu sur le traitement des gros blobs
• Je pense plutôt que le rôle de service d’archive joué par GitHub a été néfaste
  Quand on a 99 % du temps un service centralisé pratique, la capacité de préservation de l’ensemble de la communauté s’atrophie
  Si garder quelque chose vivant impliquait que quelqu’un le seed lui-même, les gens conserveraient probablement mieux des copies de ce qu’ils jugent vraiment important
  Le vrai problème, c’est qu’on a fini par considérer comme évident qu’on pourrait « refaire un checkout plus tard »
  Il ne devrait pas exister un lieu unique depuis lequel on peut tout retirer
  Quand un projet GitHub est frappé par un DMCA, même ses forks disparaissent avec lui
  Quand Nintendo a fait retirer en 2024 un émulateur Switch populaire, la préservation et la poursuite du travail n’ont été possibles qu’en retrouvant quelqu’un qui avait encore le dernier commit checkouté quelque part : https://news.ycombinator.com/item?id=40254602
  Et cela n’a marché que parce que c’était un projet extrêmement populaire
  Au passage, l’animation d’en-tête et de pied de page façon Splatoon sur ce site est vraiment excellente
  Elle donne de l’ambiance sans être gênante, et s’écarte immédiatement quand on scrolle ; ça me donne envie de la reprendre telle quelle
  • Du coup, on a aussi vu apparaître une ambiance où ce qui n’est pas sur GitHub a l’impression de ne pas exister
    Il y a vraiment trop de développeurs qui ne savent même pas que le code peut être hébergé ailleurs
  • L’archivage en lui-même est facile, ce sont surtout le droit d’auteur et les lois sur la propriété intellectuelle qui bloquent
    Si on réduisait les obstacles à l’accessibilité de l’information, le pouvoir serait aussi moins concentré
  • Je ne suis pas d’accord avec ça
    L’une des raisons pour lesquelles GitHub a gagné la confiance des gens pendant des années, c’est justement qu’il n’a pas encore monétisé directement ce rôle d’archive
    Cela dit, au vu des nouvelles fonctions liées à Copilot, on peut se demander combien de temps cela durera
    Si l’alternative consiste simplement à éclater tout ça sur plusieurs sites, chacun aura juste ses propres règles DMCA
    Ça pousse à se demander quelle serait exactement une meilleure alternative
• Ce genre de texte me pousse à repenser au parcours des projets auxquels j’ai participé
  L’essentiel de mon travail open source s’est fait sur une infrastructure auto-hébergée, Xfce étant l’exemple le plus marquant
  Quand j’ai commencé à y contribuer en 2004, je crois qu’il n’y avait qu’un serveur SVN et peut-être une interface web avec le support SVN récent de CVSweb
  Après mon entrée dans l’équipe cœur, il me semble que c’est moi qui ai mis en place Bugzilla, mais c’était peut-être quelqu’un d’autre
  Quand Git a commencé à s’imposer, j’ai piloté la migration du gros dépôt SVN vers plusieurs dépôts Git, et j’y ai ajouté l’interface web cgit
  À ce moment-là, on utilisait encore Bugzilla
  Puis, en entrant dans une petite startup vers 2009-2010, j’ai eu moins de temps pour l’OSS et j’ai quitté le projet, avant d’y revenir en 2022 ; entre-temps, ils avaient déployé une instance GitLab, des runners CI, et migré Bugzilla vers les issues GitLab
  L’équipe active reste minuscule et l’admin de l’infrastructure repose encore presque entièrement sur une seule personne, mais ça tourne très bien même avec une petite équipe
  Le fait que l’infrastructure soit fournie par sponsoring est une grande chance, et avec des dons récurrents, on pourrait probablement payer nous-mêmes si besoin
  Surtout, c’est vraiment agréable de ne pas dépendre de GitHub/Microsoft
  Si quelqu’un m’avait dit il y a 20 ans que Microsoft posséderait la plus grande forge de code OSS au monde, j’en aurais eu la nausée, et aujourd’hui encore ça me met mal à l’aise
• C’est souvent sous-estimé, mais le login partagé a aussi été très important
  Rust utilise un outil appelé crater pour lancer des tests à l’échelle de l’ensemble de l’écosystème Rust, et lorsqu’il fallait créer à la main des centaines d’issues pour repérer les projets qui dépendaient des détails d’implémentation internes de Cargo, un flux avec peu de friction était d’une grande aide
  Quand on a déjà les identifiants du site et qu’un template vide est accepté, créer 200 issues devient bien plus simple
  À l’inverse, quand je tombe sur une instance auto-hébergée, c’est souvent là que j’abandonne
• Je publiais déjà sur Planet Source Code avant même l’arrivée de SourceForge
• J’adorais vraiment Trac
  Démarrer un nouveau projet open source en commençant par installer Trac impliquait une quantité de friction presque incroyable, mais malgré ça, j’aimais beaucoup
  Django tourne encore aujourd’hui sur Trac après plus de 20 ans : https://code.djangoproject.com/timeline
  Ce n’est pas moi qui l’ai installé, mais j’ai peut-être aidé à mettre en place un Trac privé encore avant ça
  • Trac était vraiment bien
    Cela dit, mon premier issue tracker a été Bugzilla, dont l’installation était assez douloureuse et l’intégration avec les autres outils plutôt médiocre
    Malgré tout, voir Zarro Boogs avait un charme assez particulier
  • Trac a, à bien des égards, été ce qui m’a poussé à créer des applis déployables en Python plutôt qu’en PHP
    Son système de plugins était vraiment excellent
  • J’aimais bien Bitbucket
    Il faisait bien son travail, je n’ai pas eu de souci particulier avec, et je préférais plutôt l’écosystème Mercurial
    Je suis passé à GitHub parce que les entreprises l’utilisaient, mais même aujourd’hui je me sers de GitHub comme d’un simple endpoint Git un peu lourdaud, et je gère le build/déploiement avec Docker et des scripts shell, donc le coût de migration reste très faible
    Au travail, si je n’ai pas de pouvoir de décision, je considère qu’on peut simplement utiliser l’outil payant du moment, comme à l’époque de SVN
  • Bizarrement, à l’époque je détestais énormément Trac, alors qu’aujourd’hui j’en garde un bon souvenir
    J’avais l’impression qu’il essayait d’en faire trop sans exceller vraiment sur aucun point
    Je suppose que ce titre revient aujourd’hui à GitLab, et que j’en garderai probablement aussi un souvenir positif plus tard
• Par curiosité, j’ai regardé les services d’archivage de code, et il y en a quelques-uns
  Il y a le programme de GitHub lui-même : https://archiveprogram.github.com/
  Et il y a aussi Software Heritage, une association soutenue par l’UNESCO : https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
  En revanche, cela concerne surtout la préservation du code et de l’historique des commits, et beaucoup moins les métadonnées périphériques comme les issues, les PR, les discussions ou les wikis
• J’ai l’impression d’avoir été l’une des premières personnes à utiliser Flask
  J’ai appris Python pour profiter d’AppEngine, qui offrait à l’époque un hébergement moderne à la fois gratuit et simple, ce qui m’a placé dans une position idéale quand Flask est arrivé
  J’admire Armin depuis longtemps, et avant même d’ouvrir le lien, j’ai reconnu le domaine immédiatement
  Je partage aussi son constat qu’à l’époque GitHub n’était pas encore le choix par défaut
  Le fait que ce texte soit une réponse à un billet de Mitchell publié quelques heures plus tôt est aussi frappant, et je trouve impressionnant qu’il ait écrit si vite un texte aussi long, bien structuré et de qualité
• Ça me rappelle code.google.com
  J’ai encore du mal à croire à quel point Google a raté une occasion aussi énorme
  • Quelle nostalgie, vraiment
    Je faisais partie de cette équipe avant la fermeture du service