- Ghostty migriert von GitHub zu einem anderen kollaborativen Code-Repository
- Mitchell Hashimoto ist seit Februar 2008 als GitHub-Nutzer Nr. 1299 dabei und hat den Dienst seitdem fast täglich genutzt; zeitweise hielt er GitHub für den Ort, der ihn am glücklichsten machte
- Im vergangenen Monat gab es an fast jedem Tag Einträge, an denen eine nachlassende Service-Zuverlässigkeit seine Arbeit beeinträchtigte; selbst am Tag des Artikels konnte er wegen eines GitHub-Actions-Ausfalls rund zwei Stunden lang keine PR-Reviews durchführen
- GitHub ist für ihn kein angenehmer Ort mehr, und nach 18 Jahren Nutzung hat er sich zum Weggang entschieden; bei real results and improvements schließt er eine Rückkehr aber nicht aus
- Die Migration von Ghostty erfolgt in Gesprächen mit mehreren kommerziellen und FOSS-Anbietern incremental, während auf GitHub ein Read-only-Mirror bestehen bleibt
Hintergrund zu Ghostty und der GitHub-Nutzung
- Sein aktuelles Hauptprojekt ist Ghostty, ein Terminal-Emulator, der Geschwindigkeit und der Kategorie ausgereifter Software „interesting new wrinkles“ hinzufügt
- Für die Entwicklung von Ghostty wurde GitHub genutzt, und Mitchell Hashimoto ist seit Februar 2008 als GitHub-Nutzer Nr. 1299 registriert und verwendet den Dienst seitdem fast täglich
- GitHub war der „Ort, der ihn am glücklichsten machte“, ein Dienst, zu dem er über lange Zeit so viel Zuneigung hatte, dass er sich selbst in den Flitterwochen Zeit dafür nahm
- Statt in sozialen Medien Doomscrolling zu betreiben, schaute er sich seit Langem GitHub-Issues an und studierte selbst im Urlaub den Quellcode von GitHub-Projekten, OSS-Prozesse und den Umgang von Maintainern
Ausfälle, die täglich die Arbeit blockieren
- Seine Gefühle gegenüber GitHub haben sich zuletzt stark verändert, und GitHub bringe ihn inzwischen jeden Tag zum Scheitern, was sich sehr persönlich anfühle
- Der Hauptgrund sei die nachlassende Service-Zuverlässigkeit; im vergangenen Monat markierte er in seinem Journal jeden Tag mit einem „X“, an dem ein GitHub-Ausfall seine Arbeitsfähigkeit negativ beeinflusste
- In diesem Journal stand an fast jedem Tag ein „X“, und selbst am Tag des Artikels konnte er wegen eines GitHub-Actions-Ausfalls etwa zwei Stunden lang keine PR-Reviews durchführen
- Der Beitrag wurde einige Tage vor dem Vorfall vom 28. April geschrieben, bei dem Pull Requests wegen eines Elasticsearch-SNAFU nicht abgeschlossen werden konnten
- Wenn solche Störungen jeden Tag über Stunden die Arbeit blockieren, ist GitHub kein Ort mehr für „serious work“
Entwicklungsfluss und emotionale Entfremdung
- GitHub ist kein angenehmer Ort mehr, sondern ist, wie der Satz „I want to ship software and it doesn't want me to ship software“ ausdrückt, zu etwas geworden, das die Auslieferung von Software verhindert
- Er hofft zwar auf Verbesserungen bei GitHub, muss aber zugleich Code schreiben und ist an einem Punkt angekommen, an dem er mit GitHub nicht mehr weiter programmieren kann
- Nach 18 Jahren Nutzung ist er zu dem Schluss gekommen, dass er gehen muss; bei real results and improvements schließt er eine Rückkehr aber nicht aus
- Voraussetzung für eine Rückkehr zu GitHub sind nicht bloß Worte oder Versprechen, sondern tatsächliche Ergebnisse und Verbesserungen
Art der Ghostty-Migration
- Ghostty wird derzeit zu einem anderen collaborative code locker migriert
- Er spricht mit mehreren Anbietern, darunter sowohl kommerzielle Anbieter als auch FOSS-Anbieter
- Es wird Zeit brauchen, alle GitHub-Abhängigkeiten zu entfernen, und der Umzug soll so weit wie möglich incremental erfolgen
- Auf GitHub bleibt ein Read-only-Mirror von Ghostty bestehen, und persönliche Projekte will er weiterhin bei dem Microsoft-eigenen Dienst belassen
- Ghostty ist das Projekt, das ihn selbst, die Maintainer und die Open-Source-Community am stärksten betrifft, weshalb es im Mittelpunkt dieser Änderung steht
GitHubs Stellung und der Microsoft-Kontext
- Nach der Übernahme von GitHub durch Microsoft gab es Sorgen, der Dienst könne zu einem stärker auf Redmond ausgerichteten Angebot werden, das für Entwickler ohne Bindung an das Windows- oder Azure-Ökosystem weniger angenehm ist
- Diese Sorgen haben sich größtenteils nicht bewahrheitet, und GitHub hat sich als de facto place zum Bearbeiten und Teilen von Code etabliert
- Hashimotos Erfahrung zeigt jedoch, dass dieser Status ins Wanken geraten könnte, und fällt zeitlich auch mit dem Zeitpunkt zusammen, an dem Microsoft Windows has serious quality problems eingeräumt hat
- Als Teilursache für die Qualitätsprobleme von Windows wurde genannt, dass zu viele Werkzeuge zwangsweise mit KI angereichert wurden; auch die von Hashimoto beobachtete zunehmende Instabilität bei GitHub trat in derselben Phase von Microsofts KI-Fixierung auf
1 Kommentare
Hacker-News-Kommentare
Ich bin extrem frustriert, dass genau in dem Moment, in dem das Unternehmen alles von CircleCI zu GitHub Actions umstellt, die Stabilität von GitHub zusammenbricht.
Am absurdesten ist sogar, dass selbst Azure Repos/Pipelines besser war als das.
Ich habe zwar gehört, dass GitHub möglicherweise noch mitten in der Migration auf Azure-Infrastruktur steckt und deshalb in einem Zwischenzustand ist, aber das schafft kein Vertrauen.
Könnte eine Ausrede sein, klingt aber ziemlich plausibel.
Ich würde auch gern etwas wie Forgejo nutzen, aber wir sind nur etwa 12 Entwickler, und ehrlich gesagt habe nur ich selbst bisher damit gearbeitet.
Es ist wirklich sehr schlicht, daher gibt es nicht viel, was kaputtgehen kann, und aus demselben Grund mag ich auch das Ticketsystem sehr.
Es hat nur die Funktionen, die man braucht, und das Management kann nicht eine Million Felder hinzufügen und einen dann mit Reporting oder Burndown-Charts quälen.
https://news.ycombinator.com/item?id=47616242
https://isolveproblems.substack.com/p/how-microsoft-vaporize...
GitLab ist auch nicht wirklich besser.
Es wirkt, als gäbe es unendlich Budget für dumme UI-Änderungen ohne jeden praktischen Nutzen, während schwerwiegende Bugs in Releases ignoriert werden.
Als ich GitLab vor etwa 8 bis 9 Jahren zum ersten Mal genutzt habe, fand ich es wirklich großartig, und als die Firma ein paar Jahre später zu GitHub wechselte, fühlte sich das wie ein klarer Rückschritt an.
GitLab hatte viele kleine UX-Komfortfunktionen und zwar auch einige Ecken und Kanten, wirkte insgesamt aber gut durchdacht.
Seitdem ist es jedoch viel schlechter geworden, die UX wurde unzählige Male verändert, und mit jeder Änderung scheint sie schlechter zu werden.
Die alten Macken wurden nie behoben, und stattdessen kommen ständig neue dazu.
Mir fällt kaum eine nützliche Funktion ein, die in den letzten Jahren hinzugekommen oder verbessert worden wäre, und da GitHub ebenfalls chaotisch ist, hätte ich wirklich gehofft, dass GitLab klar die bessere Alternative wird und sich Marktanteile holt.
Ich habe tagelang nach der Ursache gesucht, und erst beim nächsten Update wurde das Problem überhaupt gemeldet, sodass ich mit einem Repair-Command alles wieder bereinigen konnte.
Das war ein sehr kleiner Server mit etwa 10 Nutzern und höchstens 50 Repositories.
GitHub, Bitbucket, Codeberg und andere waren okay, aber GitLab war voller Bugs, und in Firefox war es unmöglich, SSH-Schlüssel zu aktualisieren, ohne dass klar darauf hingewiesen wurde, dass es sich um einen GitLab-Firefox-Kompatibilitätsfehler handelt.
Es dauerte fast eine Stunde, bis ich überhaupt auf die Idee kam, das Hochladen des neuen SSH-Schlüssels in Chrome zu versuchen, und seitdem fasse ich GitLab nicht mehr an.
Ghostty ist nun das neueste Projekt, das GitHub verlässt, daher frage ich mich, wer als Nächstes geht.
Ich glaube nicht, dass bis nächsten Mittwoch alle GitHub verlassen und ihren eigenen Forgejo-Server aufsetzen, aber allein die Tatsache, dass Menschen endlich anfangen, ernsthaft über einen Abschied von GitHub nachzudenken, sollte GitHub Sorgen machen.
Der durchschnittliche Softwareingenieur interessiert sich überhaupt nicht für VCS oder eine Forge und hat von beidem nur sehr oberflächliche Kenntnisse.
Für Leute, die einfach nur arbeiten und dann zu ihrem Leben zurückkehren wollen, ist das nicht besonders wichtig.
Bin nur ich das, oder sind die Probleme seit der MSFT-Übernahme deutlich schlimmer geworden?
Wie sehr ist es in dieser Zeit gewachsen? Zehnfach? Hundertfach? Noch mehr?
Wenn ein Unternehmen etwas kauft, stellt sich als Nächstes die Frage, wem es danach tatsächlich gehört.
Entscheidend ist, wer im neuen Unternehmen die Verantwortung dafür übernimmt, „es weiterhin gut zu halten“, und selbst wenn die Leute bleiben, die das vorher getan haben, ist die Motivationsfrage noch einmal etwas anderes.
Microsoft hat da ein ernstes Problem.
Es wirkt, als bestünde Microsoft aus mindestens zehn mit Klebstoff zusammengehaltenen Firmen, und entsprechend groß ist auch das Reputationsrisiko, dass ein Ausfall in der Xbox-Sparte den Tools-Bereich in Mitleidenschaft zieht oder umgekehrt.
In vielen Bereichen fehlt der Fokus, und nachdem die Pressemitteilungen verstummt waren, hätte es einen „Service Pack 2“-Moment gebraucht, um diesen Everest an technischen Schulden abzubauen.
Embrace, extend, and extinguish
Da steht „GitHub user 1299, beigetreten im Februar 2008“ — wie findet man eigentlich heraus, welche GitHub user # man ist?
curl [https://api.github.com/users/YOUR_USER_HERE](<https://api.github.com/users/YOUR_USER_HERE>;)ausführen und in der Payload nach der id schauen."id": 2851Oder in den HTML-Quelltext des Avatars schauen: https://avatars.githubusercontent.com/u/2851?v=4
Ehrlich gesagt hätte ich eher mit einer Zahl in den Millionen gerechnet.
/u/#.Ich liege bei ungefähr 4 Millionen.
Gemessen an den Statistiken zur Benutzeraktivität, die ich über fast 20 Jahre gesammelt habe, bin ich ziemlich sicher ein Nutzer in den obersten 1 % oder zumindest nahe daran, was konstante, langfristige Arbeitsmenge und das tägliche Schreiben von Software angeht, die tatsächlich von anderen verwendet wird.
Ich bin ebenfalls ein recht früher GitHub-Nutzer, wenn auch keiner der allerersten, und ich liefere trotz schlechter GitHub-Metriken weiterhin aus.
Denn zum Schreiben von Software braucht man GitHub nicht.
Hashimotos Kommentar wirkt auf mich verstört, und ich hoffe, dass er Ruhe findet, aber wenn diese Aussage nicht von ihm gekommen wäre, hätte ich beim Lesen gedacht, dass da ein Problem vorliegt, und deshalb denke ich, dass das tatsächlich so ist.
Falls nicht, wirkt es ziemlich überheblich und unangenehm, Leute zu verurteilen, die sich über Ausfälle beschweren.
So etwas kannte ich eher von Reddit.
Es war allzu vorhersehbar, dass jemand den Kern verfehlt und sagt: „Es hindert dich ja nicht daran, auf deinem eigenen Rechner zu coden“, deshalb wurde genau dieser Punkt schon im ursprünglichen Blogpost vorweggenommen.
Solche ekelhaften persönlichen Angriffe auf die psychische Gesundheit anderer sollte man unterlassen.
Nachdem ich den Beitrag gelesen habe, wirkt seine emotionale Reaktion aber tatsächlich nicht ganz angemessen zur Situation.
Trotzdem kann GitHub je nach Projektgröße durch Issue-Bearbeitung, Reviews und Ähnliches auch ein Vollzeitjob werden, und es ist keineswegs ungewöhnlich, PR-Beschreibungen und Kommentare anstelle von Commit-Messages als Teil der Dokumentation zu verwenden.
Daher kann die Verfügbarkeit von GitHub für viele Unternehmen wirklich ein großes Hindernis sein.
Selbst in diesem Moment gibt es noch Probleme mit der GitHub API.
Die Kernfrage ist, was die beste Alternative ist.
Selbst mit der kostenlosen Version haben wir keine großen Beschwerden.
Man kann allen öffentlichen Code auch problemlos dorthin spiegeln.
Wenn man einen Ort zum Ausführen von Tests braucht, kann man eigene Infrastruktur aufbauen.
Das ist einfacher denn je, warum also von so einer Blackbox abhängig sein?
Das ist viel schneller als GitLab.