GitHub sinkt
(dbushell.com)- Seit der Übernahme durch Microsoft hat sich die Verfügbarkeit (Uptime) von GitHub merklich verschlechtert; selbst die offizielle Statusseite zeigt besorgniserregende Werte, und inoffizielle Statusseiten zeichnen ein noch ernsteres Bild
- Durch den exzessiven Einsatz von Copilot und die Flut von KI-generiertem minderwertigem Code (Slop) bringt GitHub sich gewissermaßen selbst in eine DDoS-Situation; Bots und eine Ökonomie gefälschter Stars untergraben das Vertrauen in die Plattform
- Git ist ein Open-Source-verteiltes Versionskontrollsystem und funktioniert auch ohne GitHub; man sollte daher davon wegkommen, GitHub mit Git selbst gleichzusetzen
- Es gibt verschiedene alternative Git-Forges wie Codeberg, Tangled, Gitea, GitLab und selbstgehostetes Forgejo, und man sollte sofort mit der Migration beginnen
- Mehrere bekannte Entwickler haben nacheinander Beiträge veröffentlicht, in denen sie ihren Abschied von GitHub ankündigen; die Abkehr von der Abhängigkeit von GitHub wird damit zu einer Aufgabe für das gesamte Ökosystem
Warum man GitHub verlassen sollte
- GitHub steht seit der Übernahme durch Microsoft in der Kritik, weil Verfügbarkeit und Nutzererfahrung schlechter geworden seien; die fehlende Statusseite soll einen noch schlechteren Trend zeigen als die offizielle Uptime-Angabe
- Das Diagramm GitHub’s Historic Uptime wird als Beleg dafür herangezogen, dass die monatliche durchschnittliche Verfügbarkeit seit der Microsoft-Übernahme instabiler geworden ist
- Microsoft hat nach der Übernahme von GitHub die Copilot-Produktfamilie ausgebaut, und GitHub leidet so sehr unter „Slop“, dass das Unternehmen selbst ein Update zu Verfügbarkeitsproblemen veröffentlichen musste
- In letzter Zeit erscheinen vermehrt Texte darüber, GitHub zu verlassen oder zu Arbeitsweisen aus der Zeit vor GitHub zurückzukehren
Git ≠ GitHub
- GitHub ist zum Synonym für „Quellcodeverwaltung“ geworden, aber zu viele Nutzer wissen nicht, dass Git nicht GitHub ist
- Git und GitHub sind nicht dasselbe; die Kerntechnologie von Git ist Open Source und verteilt, daher sind alle Repositories gleichwertig und können auch ohne einen zentralisierten Dienst funktionieren
- Zentralisierte Dienste sind ein Produkt sozialer Bequemlichkeit; GitHub war ursprünglich nur ein nützliches Zusatzwerkzeug, das Microsoft in eine teure Last verwandelt hat
- Netzwerkeffekte sind stark, aber GitHubs Ökonomie gefälschter Stars ist wertlos, und die Plattform ist überflutet von Bots und Slop
- GitHub Actions ist Teil übermäßig komplexer CI-Pipelines. Andere Lösungen zu finden ist zwar mühsam, aber man sollte sich fragen, ob man der Stabilität von GitHub noch vertrauen kann
- Das Schiff sinkt, daher sollte man den Migrationsprozess sofort beginnen, auch wenn nicht alles auf einmal umgezogen wird
Alternativen und Migrationswege
- Der naheliegendste Fluchtweg ist der Umzug zu einer anderen zentralisierten Git-Forge; nach der Anmeldung muss man das Repository nur zum neuen Upstream pushen
- Manche Dienste automatisieren die Migration und unterstützen eventuell auch den Import von Issues, aber man kann sich auch dafür entscheiden, die GitHub-Issues einfach dort zu belassen
- Keine der folgenden Alternativen ist perfekt; ihr gemeinsamer Nenner ist lediglich, dass sie nicht GitHub sind
-
Alternativen zu zentralisierten Git-Forges
- Codeberg — ein gemeinnütziges, Community-getriebenes Projekt und eine sichere Alternative mit verlässlicher Historie. Es ist die Hauptinstanz von Forgejo
- Tangled — ein Startup in der Alpha-Phase; die Integration mit dem AT protocol macht es zu einer interessanten Option. Für kleine persönliche Projekte einen Blick wert
- Gitea — bietet gemanagtes Cloud-Git-Hosting und ist das ursprüngliche Open-Source-Projekt, von dem sich Codeberg/Forgejo abgespalten haben
- GitLab — auf Enterprise-Niveau, daher schwergewichtig und unübersichtlich, kann aber für Entscheidungen innerhalb von Organisationen passend sein
- Bitbucket — nicht empfohlen, gehört aber immerhin in die Kategorie „nicht GitHub“
- Game of Trees, Radicle, Sourcehut — weitere Alternativen, die man selbst prüfen sollte
-
Self-Hosting
- Organisationen oder Einzelpersonen können eine Git-Forge selbst hosten; auch Actions und Releases lassen sich betreiben
- Die empfohlene Option für Self-Hosting ist Forgejo
- Es gibt Diskussionen über Föderation zwischen Forgejo-Instanzen, und auch Tangled hat einen Beitrag zur Föderation veröffentlicht, aber kurzfristig scheint das kaum realistisch
- Wenn öffentliche Zusammenarbeit nötig ist, kann man eine Kopie zu Codeberg pushen
- Auch Gitea und GitLab bieten Self-Hosting-Optionen, wobei GitLab vergleichsweise deutlich schwergewichtiger ist
- Nicht nur GitHub, auch andere Forges sind von Git selbst getrennt; man kann also hinterfragen, ob man die Zusatzfunktionen einer Forge überhaupt braucht
- Git lässt sich auch direkt nur über SSH verwenden
git clone user@192.168.1.67:/path/to/repo
- Zusammenarbeit ist zwar ein eigenes Thema, aber wenn Linux durch den Austausch von Patches über E-Mail-Mailinglisten gepflegt werden kann, lässt sich schwer behaupten, dass es allein aus Skalierungsgründen unmöglich sei
- Zentralisierte Git-Forges können ein realistischer Kompromiss sein, aber man sollte immer einen Exit-Plan haben und im Hinterkopf behalten, dass sie wie GitHub ebenfalls scheitern können
2 Kommentare
Wenn man bedenkt, welche Funktionen es bietet, ist es schon erstaunlich, dass es damit mehr als 99 % abdeckt.
Hacker-News-Meinungen
Alle wollen das auf die Microsoft-Übernahme oder auf Inkompetenz schieben, aber wenn man sich die von GitHub veröffentlichten Daten ansieht, wirkt ziemlich klar, dass sich die Menge des auf GitHub eingecheckten Codes wegen KI verzehnfacht hat und die Auswirkungen sich auf CI, Actions, Code-Erfassung und alles Weitere ausgebreitet haben
Der Autor macht seltsame Dinge wie MS Copilot zur Ursache, aber das wirkt eher wie eine Auflistung von Dingen, die er nicht mag, als wie ein Kausalzusammenhang
Der eigentliche Elefant im Raum, die durch KI verursachte Code-Explosion, wird ignoriert
OpenAI hat GPT-3.5 im November 2022 veröffentlicht, faktisch also im Dezember, und das beschriebene Coding mit Large Language Models/Agenten hat erst 2024 richtig Fahrt aufgenommen und fühlt sich eigentlich eher nach 2025 an
Wie erklärt man dann die schlechte Verfügbarkeit in den etwa vier Jahren nach der Übernahme, bevor das Thema KI überhaupt begann?
Auf Microsoft einzuprügeln ist in Ordnung, aber man sollte den Elefanten im Raum nicht übersehen
Selbst wenn morgen eine perfekte GitHub-Alternative auftauchte, was würde verhindern, dass Hunderte Millionen Zeilen KI-generierten Codes dort die Infrastruktur ruinieren?
Zentralisiertes Code-Hosting scheint wegen KI fast dem Tod geweiht zu sein. Ähnlich wie das, was in sozialen Medien passiert
Zehn Jahre sind eine lange Zeit, und das Ergebnis zeigt sich
GitHub Actions, Copilot und die hässliche KI-Suche, die man nicht einmal abschalten kann. Dazu noch der Umzug zu Azure
Microsoft hat es geschafft, die Netzwerkeffekte kaputtzumachen, und die Ausfälle sind nur der letzte Strohhalm, der dem Kamel den Rücken bricht
Es hat selbst riesige Codebasen und rund 200.000 Mitarbeiter
Zumal Entscheidungen wie kostenlose private Repositories bewusst getroffen wurden, taugt das kaum als Entschuldigung
Jedes Mal, wenn GitHub ausfällt, denke ich: „Wahrscheinlich hat jemand den Windows Server aktualisiert, auf dem GH läuft, und musste alles neu starten“
Ich bin zu 99 % sicher, dass das nicht stimmt, aber der Gedanke beruhigt mich und ist bei jedem Ausfall ein bisschen komisch
Ich wollte heute auf GitHub ein Repository ansehen
Ich klickte auf den Link „xxx commits“, um den Commit-Verlauf zu sehen, und bekam die Meldung, ich sei im secondary rate limit gelandet und solle warten
Ich bin der Einzige in diesem Netzwerk, der GitHub anschaut, und die Verbindung läuft über eine dedizierte IP, nicht über CGN
Danach wird die Seite normal geladen
In Wirklichkeit ist das seit Jahren eher eine Standard-Ablehnung als ein Rate Limit, aber man weigert sich, den Text an die Realität anzupassen
„GitLab – Enterprise-tauglich bedeutet: aufgebläht und verwirrend, aber es macht auf den Chef Eindruck. Wenn für die Auswahl mehrere Meetings nötig sind, nimm das.“
Lustig
Schon für die einfachsten Dinge ist die UI viel zu kompliziert. Um zum Beispiel ein MR freizugeben, muss man praktisch einen Button drücken, der selbst wieder ein Menü ist, Diffs sind schwer zu lesen, und in der „To-do list“ stehen sogar bereits gemergte MRs. Wie soll das ein umsetzbares To-do sein?
Das Problem, dass bereits gemergte MRs in der „To-do list“ bleiben, wurde schon vor Jahren gemeldet, aber die Verbesserungen scheinen nicht schnell zu kommen
Umgekehrt überrascht mich der Widerstand gegen Bitbucket etwas. Die UI ist sehr simpel und klar, und auch neue Teammitglieder empfinden das so. Mit Script Runner kann man ziemlich erstaunliche Dinge machen, und selbst riesige Repositories werden gut gehandhabt
GitLab ist nicht besonders aufgeblähter oder verwirrender als GitHub
Es ist nicht einmal wirklich Enterprise-Software. Wenn du so etwas willst, schau dir Jira oder irgendetwas von Microsoft an
Wir nutzen selbstgehostetes GitLab, und ich habe es wegen git und der Container-Registry ausgewählt
Wenn man die Web-UI nicht oft benutzt, kann die Oberfläche definitiv verwirrend wirken
Für 5 Dollar im Monat kann man einen Server hosten und mehrere Projekte darauf ablegen
Das Repository bekommt dann vielleicht keine Million Sterne, aber für meine Zwecke funktioniert es völlig ausreichend, und ich kann Leuten, die ich möchte, Zugriff geben
Ich bin mir nicht sicher, wie ich die Grafik lesen soll
Einerseits könnte sich die Verfügbarkeit wegen der GitHub-Übernahme verschlechtert haben
Andererseits wirkt es verdächtig, dass die Verfügbarkeit vor der Übernahme als 100,00 % erscheint, und vielleicht wurde die Statusseite einfach nur besser gepflegt
Ich weiß, dass es in letzter Zeit Probleme mit der GitHub-Verfügbarkeit gibt, aber in der Grafik scheint das Problem 2020 zu beginnen und sich nicht massiv zu verschlimmern
Es fühlt sich an, als könne man große Open-Source-Repositories am Ende einfach nicht in Ruhe lassen
Ich erinnere mich daran, wie SourceForge kaputtging, und es ist wirklich traurig, dass man dasselbe jetzt bei GitHub sieht
Nebenbei habe ich die URL als „dBus hell“ gelesen. Das haben wir doch alle schon einmal erlebt
Ich denke oft darüber nach, wie ich es machen würde, wenn ich eine Firma führen würde
Ich würde wirklich gern sehen, wie es wäre, alle Code-Reviews per E-Mail zu machen
Für Repositories würde ein einfacher VPS-artiger Server reichen, mit git-only-SSH-Zugang und einem
for-review/-Branch-Namespace für zu prüfenden Code; CI könnte ein Bot sein, der auf neu auftauchende Branches wartet und den Refs Kommentare oder Tags anhängt, um den Status als bestanden anzuzeigen. Die Ergebnisse könnte er auch als Antwort im E-Mail-Thread schickenAn die Mailingliste könnte man natürlich einen Web-Archiv-Viewer hängen, damit man frühere Reviews ansehen kann. Solche Lösungen gibt es bereits reichlich, es ist einfach nur HTML
Für Chat würde IRC reichen, und ein Bot kann den Channel archivieren. Super einfach
Das gesamte System könnte auf sehr günstigen Servern laufen, abgesehen von den CI-Runnern, die stärkere Hardware brauchen
GitHub ist für das Betreiben von Softwareprojekten weit stärker überentwickelt, als nötig wäre. Wenn man auf den Linux-Kernel schaut: Dort verwendet man eine einfache Mailingliste, und es ist kaum strittig, dass es eines der erfolgreichsten Softwareprojekte aller Zeiten ist
Nur Themen/Fehlerverfolgung ist etwas beängstigender. Ich habe das Gefühl, ich würde mich dabei zu sehr darin verlieren, selbst eine Lösung zu bauen, statt mich mit dem eigentlichen Geschäft der Firma zu beschäftigen. Vielleicht sollte man dann einfach eine Bug-Tracking-Softwarefirma werden?
Ich möchte also sehen können, an welcher genauen Zeile ein Kommentar hing, wann diese Zeile geändert wurde, und bequem vor- und zurückspringen
E-Mail könnte als Protokoll zum Austausch dieser Daten ausreichen, aber E-Mail-Clients sind meiner Meinung nach keine gute Darstellungsform dafür
Vielleicht braucht es sogar ein verteiltes Code-Review-System
Das Leben in Osteuropa hat auch Vorteile
Dank der Zeitzone bekomme ich große GitHub-Ausfälle fast nie mit
Ich bin auch zufrieden damit, dass sie kostenloses Hosting und Actions recht großzügig anbieten
Seit ich Forgejo auf meinem Heimserver installiert habe, habe ich nicht mehr zurückgeblickt
Das einzige Problem entsteht, wenn ich Apps auf DigitalOcean App Platform oder Vercel hosten will, denn die verbinden sich nur mit GitHub
DigitalOcean App Platformunterstützt Deployments nicht nur von GitHub, sondern auch von GitLabAllerdings muss man dafür die auf gitlab.com gehostete Instanz verwenden, nicht eine selbstgehostete GitLab-Instanz
Wenn du ohnehin schon eine selbstgehostete Forge betreibst, kannst du gitlab.com als Brücke nutzen, um sie mit DigitalOcean App Platform zu verbinden. Du musst nur einmal ein gitlab.com-Konto erstellen und deine selbstgehostete Forge Replikate dorthin pushen lassen. GitLab selbst musst du dann kaum wirklich benutzen
Trotzdem ergibt es keinen Sinn, dass DigitalOcean als Unternehmen, das IaaS/PaaS verkauft, einen nicht mit so etwas wie selbstgehostetem Forgejo verbinden lässt, das auf der eigenen Infrastruktur läuft
Eigentlich gibt es viele Leute, die gern ihre eigene Forge hosten würden, aber nur wenige, die sie selbst einrichten und betreiben wollen; deshalb ist es auch seltsam, dass DigitalOcean nicht Forgejo oder eine Alternative übernimmt, eine halbverwaltete One-Click-Deployment-Option zu einem stark rabattierten Preis wie 20 Dollar pro Jahr anbietet und die Anbindung an App Platform erstklassig unterstützt
Ich nutze DigitalOcean, aber nur für VPS
Man sollte sich nicht an solche Mittelschichten vendor-locken lassen, sondern möglichst universelle Schichten des Stacks anpeilen und dabei die Kontrolle behalten
Ich bin schon vor einigen Jahren, noch vor dem Forgejo-Fork, auf Gitea umgestiegen und bereue es nicht
Wenn GitHub gebraucht wurde, konnte ich Repositories dorthin spiegeln und es so zum Laufen bringen. Nur den Code synchron zu halten, ist mühsam
GitHub kommt ins Straucheln, weil die Zahl der Commits durch KI-gestütztes Coding im letzten Jahr um das 14-Fache gestiegen ist und sich das Tempo immer noch beschleunigt
Die Website hat Mühe, hinterherzukommen
Der GitHub-COO bestätigt das hier: https://x.com/kdaigle/status/2040164759836778878
Die Aktivität auf der Plattform schießt in die Höhe. 2025 gab es 1 Milliarde Commits, jetzt sind es 275 Millionen pro Woche, also selbst bei nur linearem Wachstum ein Tempo von 14 Milliarden in diesem Jahr. Und natürlich wird es kaum bei linearem Wachstum bleiben
GitHub Actions ist von 500 Millionen Minuten pro Woche im Jahr 2023 auf 1 Milliarde Minuten pro Woche im Jahr 2025 gestiegen, und diese Woche sind es bisher schon 2,1 Milliarden Minuten
Deshalb wird massiv in mehr CPU, den Ausbau der Services und die Stärkung der Kernfunktionen von GitHub investiert