Ghostty quitte GitHub
(mitchellh.com)- Les pannes répétées de GitHub ont fini par bloquer concrètement les revues de PR et le travail quotidien, mettant en évidence une dépendance à issues, PR et Actions que le seul caractère distribué de Git ne suffit pas à résoudre
- Au cours du dernier mois, des problèmes sur GitHub ont affecté le travail presque tous les jours, et le jour même de la rédaction, une panne de GitHub Actions a bloqué les revues de PR pendant environ deux heures
- La destination de la migration n’a pas encore été décidée, et le projet prévoit de réduire progressivement sa dépendance à GitHub en étudiant plusieurs services commerciaux et fournisseurs FOSS
- Un miroir en lecture seule sera conservé à l’URL actuelle, et ce changement ne s’appliquera dans un premier temps qu’à Ghostty ; les autres projets personnels resteront sur GitHub pour le moment
- Cette décision n’a pas été prise dans l’urgence en réaction à la panne majeure du 27 avril 2026, mais faisait l’objet de discussions depuis plusieurs mois, et un retour ne serait envisageable qu’en cas d’améliorations réelles constatées
Contexte du départ
- Ghostty a décidé de quitter GitHub, estimant que les pannes répétées ont récemment atteint un niveau où elles bloquent réellement le travail
- Un suivi distinct a été tenu des jours où des pannes GitHub ont affecté le travail au cours du dernier mois, et selon l’auteur, les problèmes se sont produits presque quotidiennement
- Le jour même de la rédaction, une panne de GitHub Actions a empêché toute revue de PR pendant environ deux heures
- Le cœur du problème réside dans l’infrastructure périphérique comme issues, PRs et Actions, et l’auteur souligne clairement que le simple fait que Git soit distribué ne résout pas cela
- Avec des blocages de plusieurs heures par jour qui se répètent, GitHub n’est plus considéré comme un espace de travail sérieux
Plan et périmètre
- La destination de la migration de Ghostty n’est pas encore arrêtée, et des discussions se poursuivent avec plusieurs services commerciaux et fournisseurs FOSS
- Le projet prévoit non pas une rupture brutale, mais une suppression progressive de sa dépendance à GitHub
- Un miroir en lecture seule restera sur GitHub à l’URL actuelle
- Ce changement ne s’appliquera dans un premier temps qu’à Ghostty, tandis que les projets personnels et les autres travaux resteront sur GitHub pour l’instant
- Ghostty étant le projet ayant le plus grand impact sur lui-même, ses mainteneurs et la communauté open source, c’est sur lui que ce changement se concentre en priorité
Contexte supplémentaire
- Même si le calendrier coïncide avec la panne majeure du 27 avril 2026, le départ de GitHub était en discussion depuis plusieurs mois et seule la décision finale a été prise cette semaine
- Le texte principal a été rédigé avant la panne majeure d’Elasticsearch, et la panne mentionnée ce jour-là dans l’article était un incident distinct
- Si GitHub s’améliore réellement, un retour sera peut-être possible un jour, mais la condition ne sera ni un discours ni une promesse : il faudra des résultats concrets et des améliorations effectives
3 commentaires
Ceux qui ont déjà migré ailleurs (sur Codeberg, par exemple) doivent sans doute se dire, en voyant cette affaire, qu’ils ont vraiment bien fait de partir.
Mitchell Hashimoto a même écrit dans un commentaire sur HN que cela l’avait vraiment fait pleurer, alors je suis allé voir
https://x.com/mitchellh/status/2049213597419774026
Il paraît qu’il est l’utilisateur GitHub n°1299 et qu’il s’est inscrit en février 2008.
On dirait bien que GitHub a pas mal de problèmes en ce moment. Il y a même quelques heures, un post intitulé GitHub connaît actuellement une panne a été publié.
Réactions sur Hacker News
mitchellh : En écrivant ce billet, j’ai vraiment pleuré, et ce n’est pas une exagération
GitHub n’était pas juste un SaaS pour moi, ça représentait bien plus que ça, donc la relation est devenue plus profonde qu’elle n’aurait probablement dû l’être
On en parlait par intermittence depuis des mois, puis on a eu des discussions sérieuses ces dernières semaines, la décision finale a été prise il y a quelques jours, mais c’est seulement en publiant moi-même ce billet que tout est devenu vraiment réel
Certains vont peut-être s’en moquer, mais je tiens vraiment à GitHub et j’espère qu’il retrouvera sa voie
Je suis l’utilisateur GitHub 22723, donc quand on pense qu’il y a aujourd’hui environ 180 millions de comptes, ça veut dire qu’on est là depuis pratiquement les mêmes débuts
À ma façon de voir les choses, GitHub ne peut aller mieux que si les gens qui y tiennent restent pour le rendre meilleur
Quand j’ai quitté Heroku il y a environ 6 ans, après l’avoir utilisé avec satisfaction pendant presque 10 ans, je n’ai jamais rouvert le dashboard, et j’ai fini par penser que Salesforce l’avait réellement détruit
Mais je n’arrive pas à me dire que je peux quitter GitHub comme ça
Il y a bien eu un aspect chaotique avec l’agentic coding et la croissance explosive, mais ça ne ressemble pas à une catastrophe façon Heroku/Salesforce
Plutôt qu’une explication par plus d’IA pour coder ou par un Microsoft malveillant, il me semble plus plausible que ce soit l’échelle et le terrain même sous les pieds des développeurs qui aient changé
J’espère qu’ils réussiront assez bien pour donner envie d’y revenir, et ce n’est absolument pas idiot de ressentir quelque chose de fort pour ce qui se trouve au centre de la vie des développeurs
Cette sensation d’être empêché de travailler, de vouloir déployer du logiciel et d’avoir l’impression que le service n’en a pas envie, ça me parle particulièrement
Ce sentiment ne concerne pas que GitHub, on dirait que le web en général devient de plus en plus bâclé et de basse qualité en ce moment
Il y a trop de pannes permanentes, de bugs, de petits accrocs d’UI et de fonctionnalités inachevées, au point qu’on ne sait plus trop ce qui se passe
Merci de créer des logiciels ergonomiques pensés pour les gens
Pour les autres, ça peut sembler dérisoire, mais pour la personne concernée, c’est un objet chargé d’affection et de souvenirs accumulés avec le temps
https://knowyourmeme.com/memes/spool-of-wire-guy
Dans la vie, il y a des choses qu’on aime et qu’on chérit, et il est normal d’être triste quand le camp qu’on soutenait se dégrade
Je ne me moquerais pas pour une raison comme celle-là, et les gens qui s’en moquent m’énervent
En revanche, pour être honnête, je ne suis pas optimiste sur le fait que GitHub retrouvera sa voie
C’était assez frappant de voir GitHub se désagréger au niveau organisationnel
Il y a plusieurs explications avancées — intégration à Microsoft, réallocation des ressources vers Copilot, structure de l’organisation, vibe coding — mais quelle qu’en soit la raison, il est difficile de nier qu’il y a un problème grave
L’historique montré par la page de statut non officielle est lui aussi assez terrible
J’aimerais entendre la vision interne, mais pour l’instant on dirait un navire en train de couler qui ne tient plus que par son inertie, et à un moment où toute l’industrie logicielle vacille, l’inertie seule ne semble pas suffisante
Le service est géré comme beaucoup d’autres services après leur rachat par une grande entreprise
Au début tout va bien, puis ça se dégrade lentement, puis ça s’effondre, et tout devient un jeu de chiffres
Microsoft, Oracle, VMware, CA, Salesforce : les exemples semblables ne manquent pas, et les équipes qui savent vraiment bien gérer les fusions-acquisitions sont extrêmement rares
https://onlineornot.com/uptime-calculator/87.25
À mes yeux, quand quelque chose grossit trop sans véritable direction, ça finit par s’effondrer
En pratique, les chiffres réels semblent encore pires
Même avant le rachat, GitHub a eu des périodes où c’était presque pile ou face de savoir si le site fonctionnerait correctement au jour le jour
Le succès est venu parce qu’il était au bon endroit au bon moment, mais au fond c’était déjà un système bricolé de partout
Je comprends l’attachement sincère de Hashimoto envers GitHub et le monde de l’open source
Mais je pense qu’avec un peu plus d’attitude à la Richard Stallman, selon laquelle les logiciels non libres sont par nature douteux et contraires à l’éthique, cette blessure aurait été moins forte
GitHub, en 2008 comme aujourd’hui, a toujours été un logiciel non libre tournant sur les serveurs de quelqu’un d’autre, selon les règles de quelqu’un d’autre, et exploité au final dans l’intérêt de son propriétaire
Je l’ai moi aussi utilisé longtemps, et il m’a souvent fallu l’utiliser pour le travail, mais je ne m’y suis jamais attaché émotionnellement
Le fait qu’il soit construit sur git, qui est un free software, tout en cherchant structurellement à enfermer les utilisateurs dans la plateforme m’a toujours dérangé
Je ne pouvais pas aimer un logiciel qui exige un compte e-mail, l’acceptation de conditions d’utilisation, et qui ne fonctionne même pas en Iran à cause des lois américaines sur les sanctions
Donc le départ de Ghostty de GitHub me réjouit sans la moindre réserve
Chez KDE, on n’a quasiment jamais envisagé GitHub sérieusement, on a géré notre propre infra git, puis plus tard on a travaillé avec Gnome autour de GitLab pour faire remonter dans la Community Edition les fonctionnalités de l’Enterprise Edition dont on avait vraiment besoin
En 16 ans, je crois qu’on n’a eu qu’une seule panne git de plusieurs heures
Il suffit de se demander si ça vaut mon temps et mon argent
Comme pour les hausses de prix de Netflix ou les jeux vidéo, il peut y avoir une charge émotionnelle, mais s’il n’y a plus de valeur, il suffit de partir
Bien sûr, je comprends qu’un lien émotionnel puisse naître, comme avec les souvenirs des débuts de l’informatique
L’idée d’intégrer ce genre d’outil directement dans le dépôt git me semble de plus en plus pertinente
Je pense que cette souffrance vient du fait de ne pas aller jusqu’au bout de la réflexion sur les problèmes du closed source software
Depuis la vente de Hashicorp, j’ai perdu beaucoup de respect
J’avais vu, dans un fil sur X où Mitchell critiquait GitHub, des réponses disant que GitHub devrait le recruter comme CEO, et je trouvais l’idée assez sensée
Pour redresser un navire comme celui-là, il faut plus qu’un simple gestionnaire : il faut quelqu’un qui combine convictions fortes, capacité d’exécution et talent pour attirer les bonnes personnes
Je pense qu’un nouveau GitHub finira par apparaître et, si le timing est bon, il pourra croître très vite, comme OpenClaw ou l’ancien GitHub l’ont fait à l’époque de SVN et SourceForge
On voit déjà beaucoup d’initiatives qui visent cette place
Et pourtant, même si l’on se limite au service central, j’ai l’impression qu’il n’existe toujours pas de bonne UI pour les projets complexes
À l’inverse, jujutsu semble aller globalement dans la bonne direction, mais il n’a toujours pas de forge vraiment convaincante
Code, wiki et tickets y sont en pratique tous gérés de manière distribuée dans un seul outil
Si l’IA remplace vraiment le développement logiciel de la manière espérée par les dirigeants de la big tech, les deux visions se rejoindront peut-être de nouveau, mais aujourd’hui les gens veulent surtout un remote git fiable, et à la place ils ont un hébergeur instable mélangé à des fonctionnalités de vibe coding bricolées
La principale raison pour laquelle tout le monde se concentre sur GitHub, c’est qu’on peut collaborer facilement sur les tickets et les PR sans que chaque forge auto-hébergée doive forcément ouvrir les inscriptions, et ce problème pourrait être résolu sans concentrer tout le code du monde sur une seule infrastructure en déclin
Ce sera probablement difficile à concrétiser, mais ce serait vraiment bien
Je suis assez curieux de voir comment l’écosystème développeur va évoluer dans 5 ans, et à quoi ressemblera GitHub d’ici là
J’ouvre très peu le site web de GitHub, j’utilise surtout github cli
Avec gh, je couvre déjà presque tous mes besoins, les Actions tournent sur GitHub, et les agents récupèrent les résultats, lisent les tickets, corrigent le code : tout le workflow a déjà changé
Si beaucoup de gens partagent l’idée que GitHub n’est plus un endroit agréable et donne l’impression d’empêcher de travailler et de déployer, alors Redmond doit réagir fermement
Si ce ressenti se diffuse vraiment à grande échelle, cela peut devenir très dangereux pour Microsoft
Il y a 8 ans, l’entreprise a investi près de 8 milliards de dollars pour faire des développeurs un pilier central, et elle a aussi mis 2 milliards dans Minecraft pour capter les jeunes futurs développeurs
Elle a déjà perdu le terrain des OS et des serveurs ; si elle perd aussi les développeurs, elle pourrait finir sur une trajectoire proche de Xerox au XXIe siècle
Microsoft retient toujours une masse énorme d’employés de bureau généralistes qui n’ont besoin que de Word et d’Excel, même si l’entreprise n’écrase pas vraiment la concurrence dans le jeu vidéo, le mobile ou l’IA, ou pourrait même perdre sur ces terrains
Il y a énormément de gens qui ne s’intéressent pas à la technologie mais restent captifs d’Office
Le fait que Claude ait appris très tôt à produire des fichiers .docx en fait partie comme compétence pratique montre bien cette réalité
Le problème, ce n’est pas git lui-même, mais l’infrastructure construite dessus : tickets, PR, Actions, etc.
Si je peux faire une suggestion, même en migrant vers une autre forge, il vaut mieux utiliser aussi git-bug
Les tickets, PR et autres y sont stockés directement dans git, non pas dans des branches mais dans des refs spéciales, avec synchronisation bidirectionnelle possible entre plusieurs fournisseurs
D’autres VCS comme fossil stockent aussi les tickets avec le dépôt, et je pense que c’est la bonne approche, parce que les tickets font partie du contexte qui donne du sens au code, comme la documentation
Quand tout est dans le dépôt, c’est effectivement plus pratique
Mais maintenant qu’un agent de coding LLM quasiment sans contraintes peut manipuler tout cela aussi, il devient plus difficile de verrouiller précisément son périmètre d’accès
Pour ce second point, il me semble qu’il y a des travaux en cours dans la direction d’une interface web, mais d’ici là, si l’on veut permettre aux utilisateurs ordinaires de signaler des problèmes, il faut toujours une infrastructure publique
Dans mes projets, je l’utilise avec https://github.com/stryan/materia, et c’est très bien pour centraliser dépôts et tickets
En revanche, pour les entrées aléatoires d’utilisateurs, j’utilise encore GitHub Discussions comme pseudo bug tracker
Si c’est bien un bug, je l’ajoute ensuite dans git-bug et je le synchronise avec GitHub issues pour qu’il reste visible publiquement, mais cette méthode ne convient pas bien à un gros volume de rapports utilisateurs
L’idée de ce workflow, ironiquement, je l’ai prise chez ghostty et mise : tous deux font d’abord remonter les bugs via les discussions, puis ne créent un ticket tagué que lorsqu’il y a quelque chose d’actionnable
Très bon tuyau
Je me demande quelle est la principale cause de la forte baisse de qualité de GitHub
Certains expliquent cela par le fait que le code généré par l’IA aurait dégradé la qualité du codebase, d’autres par la diffusion d’une mauvaise culture d’ingénierie après le rachat par Microsoft
Les deux facteurs sont peut-être mêlés à des degrés divers
https://news.ycombinator.com/item?id=45517173
https://github.blog/news-insights/company-news/an-update-on-github-availability/
On dirait surtout le résultat du mélange entre la culture et l’infrastructure Microsoft, et maintenant la qualité fait penser à celle d’autres services Microsoft
D’ailleurs, les binaires du CLI dotnet sont hébergés de manière si instable que mon CI casse souvent, et j’ai dû les réhéberger moi-même
On voit encore des incidents où la page Pull Request affiche des résultats incomplets, où les données ne sont pas perdues mais n’apparaissent pas correctement tant que la réindexation Elasticsearch n’est pas terminée
Il a dit qu’il partagerait plus en détail dans les prochains mois l’endroit où le projet Ghostty allait déménager, mais du coup cela ressemble un peu à l’idée de répondre à des indisponibilités ponctuelles de GitHub Issues ou des PR dans la journée en créant une indisponibilité de plusieurs mois
Ça donne un peu l’impression d’une décision prise dans l’urgence émotionnelle, et je ne suis pas sûr que ce soit réellement bénéfique pour lui, pour Ghostty ou pour la communauté
J’aurais au moins aimé qu’une solution de repli soit prête avant de bouger