Has Github Become Too Big To Function
Mitchell Hashimoto, créateur de Ghostty et co-fondateur de HashiCorp, annonce le départ de son projet de GitHub, dénonçant une dégradation continue de la fiabilité, une perte de vision produit et une obsession pour Copilot au détriment de l’infrastructure critique.
SYNTHÈSE STRUCTURÉE
Un départ motivé par des années de frustration
Mitchell Hashimoto, utilisateur GitHub numéro 1299 (inscrit en février 2008, soit les premiers jours de la plateforme), explique que son départ n’est pas une décision soudaine mais l’aboutissement d’un sentiment croissant d’échec. Il confie : « GitHub is failing me every single day. And it is personal. It is irrationally personal. » Ce n’est pas un caprice : il utilise GitHub plusieurs fois par jour depuis 18 ans, et la plateforme était devenue son espace de travail principal, son hobby et sa passion.
Des pannes fréquentes et mal documentées
L’intervenant a tenu un journal des outages pendant un mois et constate que presque chaque jour comporte un « X » marquant une interruption de travail. Il cite un exemple précis : « On the day that I’m writing this post, I’ve been unable to do any PR work for about two hours because there is a GitHub actions outage. » Pourtant, le statut officiel de GitHub n’affiche rien ce jour-là. Il pointe vers une page alternative, missing-github-status.vercel.app, qui recense 89 incidents en 90 jours pour une disponibilité de 84,92 % – un chiffre bien plus réaliste que le tableau de bord officiel.
Une dégradation centrée sur GitHub Actions
Les données historiques scrapées montrent que les pannes touchent surtout GitHub Actions (CI/CD). L’intervenant précise : « Actions are your CI stuff, your GitHub automation. If you’re a regular developer on some random little project, you probably aren’t even using actions. If you’re on a large-scale project though, 100% you are interacting with those. » Pour un projet comme Ghostty, qui repose lourdement sur l’automatisation, chaque panne bloque le travail de toute l’équipe.
Une perte de vision produit depuis le rachat par Microsoft
Le départ de Mitchell est aussi idéologique. Il estime que GitHub a perdu le fil conducteur qui en faisait un outil indispensable. Il propose une stratégie radicale : « Establish a North Star plan around being critical infrastructure for agentic code life cycles. […] Fire everyone who works on or advocates for Copilot and shut it down. » Selon lui, GitHub devrait être un partenaire neutre pour l’IA, pas un concurrent qui impose Copilot au détriment de la fiabilité.
L’interface utilisateur vieillissante et mal conçue
L’intervenant critique sévèrement l’interface web : « One of the most requested GitHub features in years. And the website looks like it was designed by someone nine years into a two-year community college program. » Cette remarque illustre un sentiment partagé : GitHub accumule les fonctionnalités sans jamais moderniser son socle, rendant l’expérience utilisateur frustrante pour les projets complexes.
Un attachement émotionnel douloureux
Mitchell ne cache pas son chagrin : « I actually cried writing this blog post. Tears hit my keyboard. I’m embarrassed to say. Nobody should cry over a SaaS that is software as a service, of all things. » Ce témoignage montre que son départ n’est pas un rejet de la plateforme, mais une rupture douloureuse avec un outil qui a façonné sa carrière et sa vie personnelle.
La migration de Ghostty est un processus long et complexe
Le projet Ghostty ne quitte pas GitHub du jour au lendemain. Mitchell explique : « When we’re dealing with a project, the scale of Ghostty, much like, you know, obviously considerably bigger, but the Linux kernel, it’s not a matter of just, oh, migrate the code to another repo, and then everything is done. » Il faut déplacer le code, les issues, les PRs, les actions, le wiki, et surtout la communauté. Plusieurs fournisseurs (commerciaux et FOSS) sont en discussion.
Un possible effet domino
Mitchell laisse entendre que si la migration de Ghostty réussit, il pourrait étendre ce mouvement à tous ses projets personnels : « If it goes well for Ghostty, I can very well imagine all of it leaving GitHub. » Ce précédent pourrait encourager d’autres mainteneurs de projets importants à envisager des alternatives.
CONCEPTS CLÉS
- GitHub Actions : service d’intégration et de déploiement continu (CI/CD) intégré à GitHub. C’est le composant le plus sujet aux pannes selon les données présentées.
- Agentic code life cycles : concept où l’IA agit comme un agent autonome dans le cycle de vie du code (création, révision, déploiement). Mitchell estime que GitHub devrait être l’infrastructure de ces agents, pas un concurrent.
- North Star plan : stratégie produit unique et mesurable qui guide toutes les décisions. Mitchell reproche à GitHub de ne plus en avoir une.
- Missing GitHub Status Page : site tiers (
missing-github-status.vercel.app) qui compile les incidents réels de GitHub, souvent non reportés sur la page officielle.
CONCLUSION
Le départ de Ghostty de GitHub n’est pas un simple caprice de développeur nostalgique. C’est un signal d’alarme pour l’ensemble de l’écosystème open source : quand un projet de cette envergure, porté par un utilisateur historique et influent, quitte la plateforme à cause de pannes récurrentes et d’une dérive produit, c’est que GitHub a un problème systémique. La leçon à retenir est double : d’une part, la fiabilité d’une infrastructure critique ne se négocie pas – 84 % de disponibilité est inacceptable pour un outil utilisé quotidiennement par des millions de développeurs. D’autre part, la confiance des mainteneurs ne s’achète pas avec des fonctionnalités tape-à-l’œil comme Copilot ; elle se gagne par une exécution irréprochable sur les fondamentaux. Les administrateurs système et les responsables de projets devraient surveiller de près l’évolution de cette migration, car elle pourrait bien annoncer une fragmentation durable de l’hébergement de code open source.