Ghostty verlässt GitHub
(mitchellh.com)- Wiederholte GitHub-Ausfälle haben ein Niveau erreicht, auf dem sie PR-Reviews und die tägliche Arbeit tatsächlich blockieren. Dabei wurde sichtbar, wie stark die Abhängigkeit von Issues, PRs und Actions ist – etwas, das sich nicht allein durch ein verteiltes Git-Repository lösen lässt.
- Im vergangenen Monat haben GitHub-Probleme die Arbeit fast täglich beeinträchtigt, und selbst am Tag der Veröffentlichung blockierte ein GitHub-Actions-Ausfall die PR-Reviews für etwa zwei Stunden.
- Das Ziel für den Umzug steht noch nicht fest. Während mehrere kommerzielle Dienste und FOSS-Anbieter geprüft werden, soll die Abhängigkeit von GitHub schrittweise reduziert werden.
- Unter der aktuellen URL bleibt ein schreibgeschützter Mirror bestehen, und die Änderung gilt zunächst nur für Ghostty; andere persönliche Projekte bleiben vorerst auf GitHub.
- Diese Entscheidung wurde nicht hastig als Reaktion auf den großen Ausfall vom 27. April 2026 getroffen, sondern seit mehreren Monaten diskutiert. Eine Rückkehr ist keine Zusage und kommt nur infrage, wenn konkrete Verbesserungen nachweisbar sind.
Hintergrund des Wechsels
- Ghostty hat beschlossen, GitHub zu verlassen, weil die wiederholten Ausfälle inzwischen ein Ausmaß erreicht haben, das die tatsächliche Arbeit behindert.
- Es wurde eigens festgehalten, an welchen Tagen im vergangenen Monat GitHub-Ausfälle die Arbeit beeinflusst haben; laut dem Beitrag traten Probleme fast täglich auf.
- Selbst am Tag des Schreibens konnten wegen eines GitHub-Actions-Ausfalls etwa zwei Stunden lang keine PR-Reviews durchgeführt werden.
- Im Mittelpunkt des Problems steht die umgebende Infrastruktur wie Issues, PRs und Actions; es wird ausdrücklich betont, dass sich das Problem nicht dadurch lösen lässt, dass Git allein verteilt ist.
- Da die Arbeit inzwischen täglich über mehrere Stunden blockiert werde, sei GitHub nicht länger als ernsthafter Arbeitsplatz anzusehen.
Plan und Umfang
- Das Ziel für den Umzug von Ghostty ist noch nicht festgelegt; Gespräche mit mehreren kommerziellen Diensten und FOSS-Anbietern laufen weiter.
- Die Abhängigkeit von GitHub soll nicht auf einmal beendet, sondern schrittweise abgebaut werden.
- Unter der aktuellen URL soll auf GitHub ein schreibgeschützter Mirror erhalten bleiben.
- Diese Änderung betrifft zunächst nur Ghostty; persönliche Projekte und andere Arbeiten bleiben vorerst auf GitHub.
- Da Ghostty das Projekt mit den größten Auswirkungen auf ihn selbst, die Maintainer und die Open-Source-Community ist, liegt auch der Fokus dieser Änderung darauf.
Zusätzlicher Kontext
- Zwar überschnitt sich der Zeitpunkt mit dem großen Ausfall am 27. April 2026, doch die Pläne für den Abschied von GitHub wurden seit Monaten diskutiert; nur die endgültige Entscheidung fiel in dieser Woche.
- Der Haupttext wurde vor dem großflächigen Elasticsearch-Ausfall geschrieben, und der im Beitrag erwähnte Ausfall am selben Tag war ein separater Vorfall.
- Sollte GitHub sich tatsächlich verbessern, wäre eine Rückkehr irgendwann möglich, aber die Voraussetzung dafür wären nicht Worte oder Versprechen, sondern greifbare Ergebnisse und Verbesserungen.
3 Kommentare
Wer bereits an einen anderen Ort (z. B. Codeberg) umgezogen ist, dürfte sich beim Anblick dieser aktuellen Entwicklungen nur noch mehr in der Entscheidung bestätigt fühlen, gut daran getan zu haben.
Mitchell Hashimoto schrieb sogar in den HN-Kommentaren, dass ihm wirklich die Tränen kamen, also habe ich nachgesehen.
https://x.com/mitchellh/status/2049213597419774026
Offenbar ist er GitHub-Nutzer Nummer 1299 und seit Februar 2008 dabei.
Anscheinend gibt es bei GitHub in letzter Zeit tatsächlich viele Probleme. Vor ein paar Stunden wurde auch noch GitHub hat derzeit eine Störung gepostet.
Hacker-News-Kommentare
mitchellh: Während ich das geschrieben habe, habe ich wirklich geweint, und das ist keine Übertreibung
GitHub war für mich nicht einfach nur SaaS, sondern hatte eine viel größere Bedeutung, deshalb ist die Beziehung dazu etwas ungesund tief geworden
Wir haben über einige Monate hinweg immer wieder darüber gesprochen, in den letzten Wochen dann ernsthaft diskutiert, und vor ein paar Tagen die endgültige Entscheidung getroffen, aber erst jetzt, wo ich den Text selbst veröffentliche, fühlt es sich wirklich real an
Manche werden vielleicht darüber lachen, aber ich hänge wirklich an GitHub und hoffe, dass es wieder auf den richtigen Weg findet
Ich bin GitHub User 22723, und wenn man bedenkt, dass es heute ungefähr 180 Millionen Accounts gibt, waren wir also praktisch seit derselben Zeit dabei
So wie ich es sehe, kann GitHub nur besser werden, wenn die Menschen, denen es wichtig ist, bleiben und es verbessern
Als ich Heroku vor etwa 6 Jahren verlassen habe, nachdem ich es fast 10 Jahre lang zufrieden genutzt hatte, habe ich das Dashboard nie wieder geöffnet und am Ende das Gefühl gehabt, dass Salesforce es wirklich kaputtgemacht hat
Aber von GitHub kann ich mich nicht so lösen
Agentic Coding und explosives Wachstum haben zwar zusammen einiges durcheinandergebracht, aber das wirkt nicht wie ein Heroku/Salesforce-artiger Totalschaden
Plausibler als mehr AI Coding oder ein böses Microsoft erscheint mir, dass sich Maßstab und der Boden unter den Füßen der Entwickler selbst verändert haben
Ich hoffe, sie machen es gut genug, dass man zurückkehren möchte, und es ist überhaupt nicht dumm, starke Gefühle für etwas zu haben, das im Zentrum des Entwicklerlebens steht
Dieses Gefühl, bei der Arbeit behindert zu werden, dieses Gefühl, Software ausliefern zu wollen, aber der Dienst scheint das nicht zu wollen, trifft es besonders gut
Diese Gefühle betreffen nicht nur GitHub, auch das Web insgesamt wirkt in letzter Zeit schlampiger und minderwertiger
Es gibt zu viele ständige Ausfälle, Bugs, UI-Stolpersteine und unfertige Funktionen, ich weiß wirklich nicht, was da gerade passiert
Danke, dass du ergonomische Software für Menschen baust
Für andere wirkt es unbedeutend, aber für die betroffene Person ist es ein Gegenstand voller über Jahre angesammelter Zuneigung und Erinnerungen
https://knowyourmeme.com/memes/spool-of-wire-guy
Im Leben gibt es Dinge, die man mag und liebt, und wenn das Lager, das man unterstützt hat, schlechter wird, ist es ganz natürlich, traurig zu sein
Ich würde darüber aus diesem Grund auch nicht lachen, und Menschen, die so etwas auslachen, machen mich wütend
Allerdings bin ich ehrlich gesagt nicht optimistisch, dass GitHub seinen Weg finden wird
Es war ziemlich erstaunlich, GitHub auf Organisationsebene zerfallen zu sehen
Da werden viele Erklärungen genannt, etwa die Eingliederung in Microsoft, die Verlagerung von Ressourcen in Richtung Copilot, die Organisationsstruktur oder Vibe Coding, aber was auch immer der Grund ist, es lässt sich schwer leugnen, dass es ein ernstes Problem gibt
Auch die Historie auf der inoffiziellen Statusseite ist ziemlich grauenhaft
Ich würde gern die interne Perspektive hören, aber im Moment wirkt es wie ein sinkendes Schiff, das nur noch durch Trägheit weiterfährt, und in einer Phase, in der die gesamte Softwarebranche ins Wanken gerät, scheint Trägheit allein nicht mehr zu reichen
Es wird so betrieben, wie es bei Diensten oft läuft, die von großen Unternehmen übernommen wurden
Anfangs funktioniert alles noch, dann wird es langsam schlechter, am Ende bricht es zusammen, und alles wird zu einem Zahlenspiel
Bei Microsoft, Oracle, VMware, CA und Salesforce gibt es viele ähnliche Fälle, und Teams, die Übernahmen und Fusionen gut handhaben, sind extrem selten
https://onlineornot.com/uptime-calculator/87.25
Wenn etwas ohne richtige Führung zu groß wird, bricht es am Ende eben zusammen
Gefühlt sind die tatsächlichen Zahlen noch schlechter
GitHub hatte auch schon vor der Übernahme Zeiten, in denen es wie ein Münzwurf war, ob die Seite an einem bestimmten Tag ordentlich funktioniert
Es war erfolgreich, weil es zur richtigen Zeit am richtigen Ort war, aber im Kern war es ein notdürftig zusammengeklebtes System
Ich verstehe Hashimotos aufrichtige Zuneigung zu GitHub und zur Open-Source-Welt
Aber ich glaube, mit ein wenig mehr Richard-Stallman-artiger Haltung, dass unfreie Software im Kern fragwürdig und unethisch ist, hätte sich dieser Schmerz verringern lassen
GitHub war 2008 wie heute unfreie Software, die auf fremden Servern nach fremden Regeln läuft und letztlich zum Vorteil ihrer Eigentümer betrieben wird
Ich habe es auch lange benutzt und musste es aus beruflichen Gründen oft benutzen, aber ich habe nie eine emotionale Bindung dazu aufgebaut
Dass es auf freier Software wie git aufsetzt und Nutzer strukturell dennoch an die Plattform binden will, hat mich immer gestört
Ich konnte keine Software lieben, die ein E-Mail-Konto und die Zustimmung zu Nutzungsbedingungen verlangt und wegen US-Sanktionsrecht im Iran nicht einmal funktioniert
Deshalb freue ich mich ohne Zögern darüber, dass Ghostty GitHub verlässt
Bei KDE wurde GitHub fast nie ernsthaft in Betracht gezogen, man hat die eigene git-Infra betrieben und später zusammen mit Gnome mit GitLab kooperiert, damit essenzielle Funktionen der Enterprise Edition in die Community Edition übernommen werden
In den letzten 16 Jahren gab es, soweit ich mich erinnere, genau einen mehrstündigen git-Ausfall
Es geht nur darum, ob es meine Zeit und mein Geld wert ist
Wie bei Netflix-Preiserhöhungen oder Spielen kann das emotional aufgeladen sein, aber wenn der Wert nicht mehr da ist, geht man eben
Natürlich verstehe ich, dass emotionale Bindungen entstehen, wie bei Erinnerungen an die Anfangszeit des Computings
Es erscheint mir zunehmend sinnvoll, Dinge wie Issue-Tracker in ein git-Repo einzubetten
Ich glaube, dieser Schmerz entsteht, weil man die Probleme von Closed-Source-Software nicht bis zum Ende durchdenkt
Seit dem Verkauf von Hashicorp ist bei mir viel Respekt verloren gegangen
In einem Thread, in dem Mitchell GitHub auf X kritisiert hatte, habe ich Antworten gesehen, dass GitHub ihn als CEO einstellen sollte, und das klang ziemlich plausibel
Wer ein solches Schiff wenden soll, muss mehr sein als nur ein Verwalter: jemand mit starken Überzeugungen, Umsetzungsstärke und der Fähigkeit, Talente anzuziehen
Ich glaube letztlich, dass ein neues GitHub entstehen wird, und wenn es den Nerv trifft, kann es schnell wachsen, so wie OpenClaw oder das frühere GitHub zu Zeiten von SVN und SourceForge
Es scheint bereits viele Versuche zu geben, diesen Platz einzunehmen
Und trotzdem habe ich gemessen am Kerndienst das Gefühl, dass es besonders für komplexe Projekte noch keine gute UI gibt
Jujutsu dagegen scheint in seiner Grundrichtung ziemlich gut zu sein, aber es gibt immer noch keine ordentliche Forge dafür
Code, Wiki und Issues werden dort praktisch als ein einziges Tool verteilt verwaltet
Wenn AI die Softwareentwicklung so ersetzt, wie Big-Tech-Führungskräfte es sich wünschen, könnte das wieder zusammenpassen, aber im Moment wollen die Leute ein stabiles git remote, bekommen aber eine instabile Hosting-Plattform zusammen mit halb garen Vibe-Coding-Funktionen
Der größte Grund, warum alle zu GitHub gehen, ist, dass man auch dann leicht bei Issues und PRs zusammenarbeiten kann, wenn nicht jede self-hosted forge Registrierungen erlaubt, und das ließe sich auch lösen, ohne allen Code auf eine einzige zerfallende Infrastruktur zu werfen
Wahrscheinlich wird das schwer umzusetzen sein, aber es wäre wirklich großartig
Ich bin ziemlich neugierig, wie sich das Entwickler-Ökosystem in 5 Jahren verändert haben wird und wie GitHub in 5 Jahren aussehen wird
Ich öffne GitHub im Web fast nie und benutze stattdessen viel die github cli
Mit gh geht schon jetzt fast alles, was ich brauche, und während Actions auf GitHub laufen und Agenten die Ergebnisse holen, Issues lesen und Code ändern, verändert sich der gesamte Workflow bereits
Wenn viele Menschen zustimmen, dass GitHub kein angenehmer Ort mehr ist und sich anfühlt, als würde es Arbeit und Deployments behindern, dann sollte Redmond hart reagieren
Wenn sich dieses Gefühl tatsächlich stark verbreitet, könnte das für Microsoft ein schwerer Schlag werden
Vor 8 Jahren hat man fast 8 Milliarden Dollar ausgegeben, um Entwickler zum zentralen Pfeiler zu machen, und weitere 2 Milliarden für Minecraft, um auch junge Entwickler langfristig an sich zu binden
Das Unternehmen hat OS und Server bereits verloren, und wenn es auch noch die Entwickler verliert, könnte es einen Weg einschlagen, der an Xerox im 21. Jahrhundert erinnert
Microsoft hält immer noch eine enorme Zahl gewöhnlicher White-Collar-Arbeiter, denen Word und Excel reichen, auch wenn es bei Games, Mobile und AI nicht dominiert oder eher zu verlieren scheint
Es gibt zu viele Menschen, die sich nicht für Technik interessieren, aber an Office gebunden sind
Dass Claude früh unter den praktisch nutzbaren Fähigkeiten auch das Erstellen von .docx gelernt hat, zeigt das ebenfalls
Das Problem ist nicht git selbst, sondern die darauf aufgesetzte Infrastruktur wie Issues, PRs und Actions
Mein Vorschlag wäre, auch bei einem Wechsel zu einer anderen Forge git-bug mitzuverwenden
Damit werden Issues, PRs und Ähnliches nicht in Branches, sondern in speziellen Refs gespeichert und direkt in git abgelegt, außerdem wird bidirektionale Synchronisation mit verschiedenen Anbietern unterstützt
Andere VCS wie fossil speichern Issues ebenfalls zusammen mit dem Repo, und ich denke, das ist sinnvoll, weil Issues wie Dokumentation ein Teil davon sind, dem Code Bedeutung zu geben
Wenn alles im Repo liegt, ist das durchaus praktisch
Nur wird jetzt fast alles zusätzlich von einem nahezu uneingeschränkten LLM coding agent mitbenutzt, was es noch schwieriger macht, Zugriffsbereiche wirklich zu begrenzen
Soweit ich weiß, wird an Letzterem in Richtung Web-UI gearbeitet, aber bis dahin braucht man für Issues von normalen Nutzern letztlich doch öffentliche Infrastruktur
In meinem Projekt nutze ich es mit https://github.com/stryan/materia, und zum Zentralisieren von Repository und Issues ist es gut geeignet
Zufällige Eingaben von Nutzern laufen bei mir aber weiterhin über GitHub Discussions als Pseudo-Bugtracker
Wenn es wirklich ein Bug ist, füge ich ihn in git-bug hinzu und synchronisiere ihn mit GitHub Issues, damit er öffentlich sichtbar ist, aber für umfangreiche Bugreports vieler Nutzer eignet sich dieser Ansatz nicht besonders gut
Ironischerweise habe ich diese Workflow-Idee ausgerechnet von Ghostty und mise übernommen: Beide nehmen Bugs zuerst über Discussions entgegen und erzeugen nur dann ein getaggtes Issue, wenn es tatsächlich umsetzbar ist
Guter Tipp
Ich frage mich, was die größte Verantwortung dafür trägt, dass die GitHub-Qualität so stark gesunken ist
Es gibt die Erklärung, dass AI-generierter Code die Qualität der Codebasis verschlechtert habe, und die Erklärung, dass sich nach der Microsoft-Übernahme eine schlechte Engineering-Kultur verbreitet habe
Vielleicht ist es auch eine Mischung aus beidem
https://news.ycombinator.com/item?id=45517173
https://github.blog/news-insights/company-news/an-update-on-github-availability/
Es wirkt wie das Ergebnis einer Mischung aus Microsoft-Kultur und -Infrastruktur, und inzwischen fühlt es sich qualitativ ähnlich an wie andere Microsoft-Dienste
Zusätzlich musste ich die dotnet-CLI-Binaries selbst rehosten, weil das Hosting so instabil ist, dass meine CI ständig kaputtging
Auf Pull-Request-Seiten werden Ergebnisse unvollständig angezeigt, und es passieren weiter Vorfälle, bei denen die Daten zwar nicht weg sind, aber die Listen nicht korrekt erscheinen, bis ein Elasticsearch-Index neu aufgebaut und die Reindexierung abgeschlossen ist
Es wurde gesagt, dass in den kommenden Monaten genauer mitgeteilt werde, wohin das Ghostty-Projekt umziehen soll, aber das wirkt auch ein wenig so, als wolle man auf das Problem reagieren, dass GitHub Issues oder PRs tagsüber manchmal nicht erreichbar sind, indem man für mehrere Monate gar nicht erreichbar ist
Die Entscheidung wirkt etwas emotional und überhastet, und ich bin nicht sicher, ob sie für ihn selbst, für Ghostty oder für die Community wirklich von Vorteil ist
Ich würde mir wünschen, dass man zumindest einen Fallback-Pfad vorbereitet, bevor man den Schritt geht