GitHub hat RIESIGE Probleme!
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsManagementInternet Technology
Transcript
00:00:00GitHub befindet sich in einer sehr kritischen, einer sehr schlechten Lage.
00:00:04Es gibt viele, viele Probleme, von denen viele mit KI zu tun haben,
00:00:08aber vielleicht nicht aus den Gründen, die Sie denken,
00:00:10aber darauf komme ich noch zurück.
00:00:11Und natürlich spielt das eine Rolle.
00:00:13Es ist wichtig, weil GitHub das Rückgrat
00:00:16der modernen Entwicklungsarbeit ist.
00:00:17Ganz gleich, ob Sie Open-Source-Entwicklung betreiben,
00:00:20ob Sie Open-Source-Projekte pflegen,
00:00:22ob Sie nur an Ihren eigenen Projekten arbeiten,
00:00:24Ihren persönlichen Projekten, Ihren Nebenprojekten,
00:00:26ob Sie ein kleines Unternehmen führen,
00:00:29oder ob Sie in einem größeren Unternehmen tätig sind,
00:00:32es wird für alles Mögliche genutzt: als Code-Archiv,
00:00:35für CI/CD-Workflows, zur Zusammenarbeit,
00:00:38um gemeinsam an Projekten zu arbeiten, über Issues,
00:00:42für Pull-Requests und viele, viele andere Dinge und Anwendungsfälle.
00:00:47Das ist also von Bedeutung, aber wie erwähnt,
00:00:49gibt es viele, viele Probleme.
00:00:51Fangen wir damit an, was schiefläuft,
00:00:53bevor wir uns das Warum ansehen
00:00:54und was das für die Zukunft bedeutet.
00:00:57Und fangen wir mit einer großen Sache an.
00:00:59Es wurde eine große, eine gewaltige,
00:01:02eine unglaubliche Sicherheitslücke gemeldet – gestern,
00:01:07als ich dies aufnehme.
00:01:09Eine Remote-Code-Ausführung auf github.com.
00:01:12Ich meine, das zu lesen, ist einfach wahnsinnig.
00:01:16Sie wurde von Viz entdeckt, einem Sicherheitsunternehmen,
00:01:19und sie wurde nicht ausgenutzt.
00:01:21Sie wurde also entdeckt, gemeldet und behoben.
00:01:25Es entstand kein Schaden.
00:01:28Laut GitHub,
00:01:31die auch eine Antwort auf diesen Bericht veröffentlicht haben.
00:01:33Ich werde jetzt nicht auf die Details eingehen,
00:01:36wie diese Sicherheitslücke funktionierte.
00:01:39Ich werde den Artikel jedoch unten verlinken.
00:01:42Aber letztendlich funktionierte alles über "git push".
00:01:44Es war also kein Phishing im Spiel,
00:01:46keine Kontoübernahme eines Mitarbeiters,
00:01:49kein Supply-Chain-Angriff.
00:01:51Davon haben wir in den letzten Wochen viel gesehen,
00:01:54aber nein, nichts dergleichen war beteiligt.
00:01:56Stattdessen war es einfach nur "git push",
00:01:58und zwar ganz spezifisch die Standardfunktion "push option",
00:02:03die man dem Befehl "git push" hinzufügen kann,
00:02:05um zusätzliche Optionen an diesen Push-Befehl anzuhängen.
00:02:10Und durch diese Optionen-Funktion und die Schwachstelle
00:02:13sowie die Art und Weise, wie GitHub Pushes verarbeitete,
00:02:17konnten die Sicherheitsforscher hier Code mitschicken,
00:02:22der dann einfach so auf den GitHub-Servern ausgeführt wurde.
00:02:27Die genauen Details stehen wie gesagt in diesem Bericht,
00:02:31aber letztendlich nutzten sie die Tatsache aus,
00:02:34dass man zusätzliche Metadaten zu einem xstat-Header hinzufügen konnte,
00:02:39der mithilfe dieses Push-Options-Flags befüllt wurde.
00:02:44Und diese Metadaten, diese Informationen, die man
00:02:49mit der Push-Anfrage über diesen Header mitschicken konnte,
00:02:52wurden von GitHub letztendlich nicht bereinigt.
00:02:54Sie authentifizierten am Ende lediglich die Push-Anfrage,
00:02:58den Push-Befehl.
00:02:59Sie prüften, ob man berechtigt ist, in das Repository
00:03:01zu pushen, in das man zu pushen versucht,
00:03:03aber dann nahmen sie diese Options-Daten
00:03:07und erstellten diesen xstat-Header, ohne diese Daten zu bereinigen.
00:03:12Und das ermöglichte es den Sicherheitsforschern,
00:03:15Befehle auszuführen, die dann nicht auf das Repository
00:03:18beschränkt waren, in das sie gepusht hatten,
00:03:21sondern stattdessen frei auf den GitHub-Servern liefen
00:03:24und auch auf andere Repositories zugreifen konnten,
00:03:27einschließlich privater Repositories.
00:03:29Diese Sicherheitslücke wurde wie gesagt gemeldet und behoben
00:03:33und sie existiert nicht mehr,
00:03:35aber es ist offensichtlich eine gewaltige Sache.
00:03:39Ich meine, es ist ein riesiges Problem, eine Schwachstelle zu haben,
00:03:43die eine Remote-Code-Ausführung auf github.com ermöglicht.
00:03:45Das ist wirklich enorm.
00:03:47Das ist also eine große Sache,
00:03:48aber es ist natürlich nicht das einzige Problem.
00:03:51Am 23. April, also nur ein paar Tage zuvor,
00:03:56gab es einen riesigen Vorfall im Zusammenhang mit GitHub Merge Queues.
00:04:01GitHub Merge Queues sind, falls Sie es nicht wissen,
00:04:04eine GitHub-Funktion, die für Repositories gedacht ist,
00:04:07in denen es viel Aktivität und viel aktive Arbeit gibt,
00:04:11wo also viele Pull-Requests eingehen.
00:04:13Und um sicherzustellen, dass man nicht jeden
00:04:16Pull-Request mergen muss, bevor ein neuer gesendet werden kann –
00:04:19denn natürlich möchte man einen Pull-Request
00:04:21gegen den neuesten Stand des Repositories haben,
00:04:24des Main-Branch zum Beispiel –
00:04:26um also sicherzustellen, dass man nicht jeden Pull-Request
00:04:28mergen muss, bevor ein neuer geöffnet werden kann,
00:04:30existiert letztendlich diese Merge-Queue-Funktion,
00:04:34die das einfache Ziel hat, effektiv bereits
00:04:38eine Art Zwischen-Merge zu erstellen,
00:04:42also einen neuen Zustand des Repositories bzw. des Branch
00:04:46für jeden Pull-Request zu erzeugen.
00:04:49Und wenn ein neuer Pull-Request zur Kette
00:04:51der Pull-Requests hinzugefügt wird,
00:04:53wird dieser auch schon kombiniert mit den Pull-Requests
00:04:57davor in den Main-Branch gemergt,
00:04:58sodass neue Pull-Requests so geöffnet werden,
00:05:01als wären die vorherigen bereits gemergt worden.
00:05:05Und das erlaubt es Teams einfach, schneller zu arbeiten,
00:05:08weil man immer mehr Pull-Requests öffnen kann,
00:05:10ohne dass die davor zuerst fertig sein müssen.
00:05:13Irgendwann werden sie natürlich gemergt,
00:05:15aber es ermöglicht ein kontinuierliches Arbeiten,
00:05:17was natürlich zum Beispiel für große Teams wichtig ist.
00:05:19Wichtig im Zusammenhang mit dieser Funktion ist
00:05:22natürlich auch, dass sie korrekt funktioniert.
00:05:24Und was am 23. April passierte, war,
00:05:28dass es einen Fehler gab, einen internen Logikfehler
00:05:32dabei, wie GitHub diese verschiedenen Pull-Requests auflöste,
00:05:37sodass letztendlich ein Merge erstellt wurde,
00:05:41der Informationen verwarf, was wiederum
00:05:45zu einem ungültigen Commit führte und Teile
00:05:49der Git-Historie dort löschte.
00:05:50Die Daten waren zwar nicht wirklich verloren,
00:05:53aber diese Funktion arbeitete fehlerhaft
00:05:55und erzeugte diesen falschen Commit.
00:05:57Das ist die Kurzfassung, der Kern der Sache.
00:06:00Und natürlich ist das auch völlig inakzeptabel,
00:06:03wenn man ein großes Unternehmen ist oder irgendein Unternehmen,
00:06:06das sich auf diese Funktion verlässt, und plötzlich
00:06:09ist das Projekt in einem defekten Zustand, ohne
00:06:13dass man eine klare Erklärung dafür hat.
00:06:16Ihr erster Gedanke ist dann wahrscheinlich nicht,
00:06:19dass es einen internen Bug in dieser Merge-Queue-Funktion gibt.
00:06:23Man denkt eher, dass man selbst etwas falsch gemacht hat.
00:06:26Man verbringt also viel Zeit mit der Fehlersuche,
00:06:28bis man herausfindet: Oh nein, es liegt an GitHub.
00:06:30Und das alles kommt natürlich noch zusätzlich
00:06:33zu den ständigen Uptime- und Downtime-Problemen von GitHub.
00:06:38Die offizielle Statusseite sieht zwar schlecht aus,
00:06:42aber vielleicht noch okay; allerdings haben wir hier
00:06:46keine "drei Neunen" an Verfügbarkeit, zumindest für die meisten Systeme.
00:06:49Sie geben die Uptime separat für verschiedene Systeme an.
00:06:53Aber die Dinge sehen etwas anders aus, wenn wir uns
00:06:55die "Missing GitHub"-Statusseite ansehen,
00:06:57die die Verfügbarkeit auf eine andere Weise erfasst
00:07:00und jeden kleinen Vorfall als Problem wertet,
00:07:04also letztendlich als Downtime.
00:07:05Hier sehen wir eine schreckliche Uptime für ein so wichtiges System
00:07:10wie GitHub, was natürlich völlig inakzeptabel ist.
00:07:14Wir hatten also Uptime-Probleme in den letzten Monaten
00:07:18und sogar schon im letzten Jahr.
00:07:20Und es gab auch hier und da kleinere Bugs,
00:07:23nur eben nicht so groß wie dieser oder so wichtig
00:07:26wie diese Sicherheitslücke.
00:07:28Aber ja, es gibt viele Probleme,
00:07:31und GitHub ist zu diesem Zeitpunkt definitiv zu einer
00:07:36unzuverlässigen Plattform geworden, leider.
00:07:38Das ist ein Desaster angesichts seiner Rolle und Bedeutung
00:07:43für die, wie eingangs erwähnt, moderne Entwicklung,
00:07:47unabhängig davon, welche Art von Entwicklungsarbeit man leistet.
00:07:50Ein weiteres Problem ist, dass die Kommunikation vonseiten GitHubs,
00:07:54sagen wir mal, nicht besonders umfangreich war.
00:07:59Es gab nicht viel Kommunikation,
00:08:01aber es wurde am 28. April ein Blogpost geteilt,
00:08:06noch vor dieser Sicherheitslücke,
00:08:10in dem sie gewissermaßen erklären, was los ist,
00:08:14woher die Probleme kommen,
00:08:16dass sie verstehen, dass ihre Kommunikationsstrategie
00:08:19nicht ideal war und dass es besser werden wird.
00:08:23Das ist nun der nächste Teil.
00:08:25Woher kommen die Probleme?
00:08:28Das offizielle Statement nennt KI als einen Grund,
00:08:32aber nicht in dem Sinne, dass GitHub-Ingenieure
00:08:36bei Microsoft KI nutzen und fehlerhafte Software ausliefern,
00:08:40also fehlerhafte Updates für GitHub.
00:08:43Das mag passieren, aber wir haben keine Beweise dafür.
00:08:47Stattdessen wird hier als Hauptgrund angeführt,
00:08:51dass es wegen der KI so viel mehr Projekte gibt,
00:08:57die erstellt werden, so viel mehr Code generiert wird,
00:09:00und letztendlich all diese Projekte und dieser ganze Code
00:09:03zu GitHub gepusht werden.
00:09:04Und sie teilen hier einige, nun ja, nicht sonderlich hilfreiche,
00:09:09aber sie teilen hier einige Diagramme.
00:09:12Sie sind nicht sehr hilfreich, weil wir keine y-Achse haben.
00:09:14Wir sehen die absoluten Zahlen nicht,
00:09:17aber wir können hier natürlich die Verhältnisse sehen.
00:09:20Und wir können natürlich sehen, dass es im Jahr 2025
00:09:23einen steilen Anstieg bei den gemergten Pull-Requests gab,
00:09:28bei den gepushten Commits und natürlich auch bei neu eröffneten Repos.
00:09:32Das sind all unsere Nebenprojekte, die wir jetzt erstellen
00:09:34und dank KI nicht zu Ende bringen.
00:09:36Und im Jahr 2026 schießen die Kurven für all diese Metriken
00:09:41offensichtlich einfach nur in den Himmel, schätze ich.
00:09:46Das ist also natürlich ein ziemlich klarer Trend.
00:09:49Und dieser Traffic, diese Art von Verkehrszunahme,
00:09:54würde natürlich jedes System unter Stress setzen.
00:09:58Es ist besonders problematisch für GitHub,
00:10:01weil sie mitten in der Migration weg
00:10:05von einer monolithischen Struktur und ihren eigenen dedizierten
00:10:09Rechenzentren oder Systemen hin zur Azure-Cloud sind,
00:10:13sowie in ein stärker aufgeteiltes System, ein Microservices-System,
00:10:17könnte man sagen, statt dieser monolithischen Struktur.
00:10:21Das war ein laufender Prozess, schon bevor wir das Jahr 2026 erreichten.
00:10:26Aber es bedeutet natürlich, dass dieser Migrationsprozess jetzt
00:10:31voll von diesem Nachfrageschub getroffen wird.
00:10:34was bedeutet, dass man trotz der Migration
00:10:36das aktuelle System irgendwie stabilisieren muss,
00:10:39während man die Migration fortsetzt,
00:10:40was dann hoffentlich bei diesem Anstieg
00:10:44des Traffics in der Zukunft helfen wird.
00:10:46Das ist natürlich die Hoffnung, keine Garantie.
00:10:50Aber es ist natürlich etwas, womit GitHub fertig werden muss.
00:10:52Hier geben sie an, dass sie im Oktober 2025 mit der Ausführung
00:10:56eines Plans zur Verzehnfachung der Kapazität begonnen haben.
00:11:01Man könnte also sagen, etwa hier sahen sie:
00:11:04„Nun, das geht alles steil nach oben."
00:11:06Ich meine, das konnten sie schon vorher sehen,
00:11:09aber hier entschieden sie, die Kapazität zu verzehnfachen.
00:11:13Und im Februar 2026 sahen sie dann:
00:11:16„Okay, wir brauchen das 30-fache, nicht das 10-fache", weil...
00:11:20nun ja, wegen dieser Entwicklung hier, richtig?
00:11:22Das muss natürlich zusätzlich zu dieser Migration geschehen.
00:11:28Und das ist offensichtlich eine gewaltige Aufgabe.
00:11:33Es ist zwar Teil von Microsoft, also kein kleines Startup,
00:11:37aber dennoch ist es eine entmutigende Aufgabe.
00:11:39Und das ist ein Aspekt dieses gesamten GitHub-Problems,
00:11:44bei dem ich gewisses Mitgefühl habe, weil ich denke,
00:11:47dass es leicht ist, auf GitHub zu schimpfen oder es zu belächeln.
00:11:51Und das kann man definitiv tun.
00:11:52Ich komme noch auf weitere Probleme zurück, die wirklich schlimm sind.
00:11:56Aber diese Art von Traffic-Zunahme wäre ein riesiges Problem
00:11:59für jedes System und jedes Unternehmen da draußen.
00:12:03Und es ist schwer zu glauben, dass irgendein GitHub-Konkurrent
00:12:07in dieser Situation besser abschneiden würde.
00:12:09Trotzdem ist das natürlich keine Ausrede.
00:12:10Es ist Teil von Microsoft.
00:12:12Und daher haben sie natürlich definitiv die Ressourcen,
00:12:16um diesen Übergang zu meistern und ihre Systeme
00:12:20an diese neue Welt und dieses neue Traffic-Aufkommen anzupassen.
00:12:24Aber es gibt hier noch ein weiteres wichtiges Problem mit GitHub.
00:12:28Und zwar, dass es keinen CEO mehr hat.
00:12:32Der vorherige CEO, Thomas Domke,
00:12:37ging in den Ruhestand oder trat zurück bzw. kündigte dies
00:12:41für den August 2025 an.
00:12:43Und Microsoft hat keinen neuen CEO ernannt.
00:12:48Stattdessen wurde GitHub Teil von „Core AI",
00:12:51einer internen Abteilung bei Microsoft, bei der es,
00:12:56wie der Name sagt, um KI und KI-Tools und -Plattformen geht.
00:13:01Und GitHub ist nun ein Teil davon.
00:13:03Aus Sicht von Microsoft ist die Mission von GitHub also klar,
00:13:07Teil dieser KI-Toolchain zu werden,
00:13:11Teil dieser KI-Revolution.
00:13:13Und offensichtlich drängt Microsoft den Copilot
00:13:15in all seine Produkte.
00:13:16Und tatsächlich sagten sie bereits auf der GitHub Universe 2023,
00:13:20dass sie GitHub in die KI-gestützte Entwicklerplattform
00:13:24transformieren werden, mit „GitHub überall".
00:13:28Das beinhaltet Dinge wie neue Funktionen,
00:13:30die beim Erstellen von Issues mit GitHub Copilot helfen,
00:13:32was ein riesiges Problem für Open-Source-Maintainer ist,
00:13:36aber auch einfach die schiere Präsenz von GitHub Copilot
00:13:39überall auf GitHub.
00:13:43Es gibt diese „Agent HQ"-Sache hier auf GitHub,
00:13:44[github.com/copilot](https://github.com/copilot),
00:13:48wo man mit GitHub Copilot interagieren
00:13:49und direkt innerhalb von GitHub Copilot an seinem Code arbeiten kann,
00:13:52ohne jemals eine lokale IDE oder ein Coding-Agent-Tool zu öffnen,
00:13:55und viele, viele weitere Bereiche.
00:14:00GitHub Copilot ist überall in GitHub,
00:14:02genau wie der Copilot wohl überall
00:14:05in allen Microsoft-Produkten präsent ist.
00:14:07Und das ist natürlich eine klare strategische Entscheidung,
00:14:10die gewissermaßen gegen die eigentliche Mission von GitHub geht,” Zumindest gegen die Mission, die GitHub in der Vergangenheit hatte.
00:14:14Denn wie ich ganz zu Beginn erwähnt habe,
00:14:19ist GitHub für verschiedene Arten von Entwicklern
00:14:23für alle möglichen Anwendungsfälle wichtig.
00:14:25Open-Source-Maintainer nutzen es, um ihren Quellcode
00:14:29dort zu hosten und mit anderen Maintainern
00:14:31und Mitwirkenden aus der Community zusammenzuarbeiten.
00:14:36Issues sind entscheidend, um Probleme zu erkennen
00:14:39und an ihnen zu arbeiten.
00:14:41Pull Requests sind wichtig, damit andere Leute
00:14:45zur Codebasis beitragen können.
00:14:46Diskussionen können großartig sein, um neue Features
00:14:50oder die Richtung eines Repositories oder einer Library zu besprechen.
00:14:52Es gibt hier viele verwandte Funktionen,
00:14:55die Open-Source-Maintainern helfen,
00:15:01oder zumindest in der Vergangenheit geholfen haben.
00:15:03Andere Leute nutzen GitHub einfach als Ressource
00:15:04zum Hosten von Links oder Dokumenten,
00:15:07wie all diese „Awesome"-Repositories – Awesome Go, Awesome Rust
00:15:11und so weiter –, mit denen man leicht Ressourcen findet,
00:15:13wenn man mit Go oder Rust arbeiten möchte.
00:15:17Ich nutze GitHub auch zum Hosten meiner Kursmaterialien,
00:15:20wie hier zum Beispiel für meinen Codex-Kurs
00:15:22und für viele andere Kurse ebenfalls.
00:15:26Man kann GitHub also sogar als eine Art
00:15:29Dokumentenspeicher „zweckentfremden".
00:15:31Und dann kann man GitHub natürlich auch für CI/CD-Arbeiten nutzen.
00:15:33In einem Unternehmen nutzt man GitHub vielleicht,
00:15:36um dort seinen Quellcode zu haben,
00:15:40damit Teammitglieder an diesem Quellcode
00:15:43mittels Pull Requests und so weiter zusammenarbeiten.
00:15:46Und dann ist GitHub sehr oft
00:15:50auch Teil der CI/CD-Pipeline,
00:15:52wobei zum Beispiel ein neuer Push in den Main-Branch
00:15:54eine CI/CD-Pipeline auslöst.
00:15:57Das könnte mit Hilfe von GitHub Actions geschehen,
00:15:59obwohl dieses Produkt seine eigenen Probleme hat.
00:16:02Aber es könnte natürlich auch dazu dienen, eine Pipeline
00:16:05bei jedem anderen CI/CD-Anbieter auszulösen.
00:16:08GitHub spielt also natürlich eine sehr wichtige Rolle
00:16:12für klassische, traditionelle Entwicklungsarbeit.
00:16:16Aber Microsoft hat eben entschieden, dass es
00:16:20eine KI-gestützte Entwicklerplattform werden soll,
00:16:24nicht nur eine einfache Entwicklerplattform.
00:16:27Und das passt hier irgendwie nicht ganz zusammen.
00:16:31Entwickler wollen den Copilot nicht unbedingt
00:16:33in jedem Aspekt von GitHub haben.
00:16:37Ich schätze, Nutzer von Microsoft-Produkten im Allgemeinen
00:16:41wollen GitHub nicht in all ihren Produkten haben,
00:16:43aber das ist eine andere Geschichte.
00:16:46Und GitHub hat die Kernfunktionen vernachlässigt,
00:16:48die für Entwickler wichtig sind.
00:16:49Nehmen wir zum Beispiel die Open-Source-Entwicklung.
00:16:53Maintainer von Open-Source-Projekten ertrinken
00:16:56in KI-generierten Issues und Pull Requests.
00:17:00Das Problem hier ist natürlich die Asymmetrie.
00:17:03Es ist einfach, KI zum Erstellen von Code oder Issues zu nutzen.
00:17:07Es ist viel schwieriger, all das zu überprüfen –
00:17:10also diesen generierten Code und diese Issues zu reviewen.
00:17:14Und das ist etwas, das jeder Entwickler weiß,
00:17:19der jemals mit KI gearbeitet hat.
00:17:24Man kann leicht drei oder mehr KI-Agenten starten
00:17:26und sie an seinen Projekten arbeiten lassen,
00:17:27völlig außerhalb von GitHub.
00:17:30Das geht auf dem eigenen Rechner mit Codex, Claude Code usw.
00:17:32Aber wenn man nicht den Weg des „blind Codens" geht –
00:17:33was man meiner Meinung nach nicht tun sollte –,
00:17:35muss man diesen Code irgendwann überprüfen.
00:17:36Und das kostet Zeit.
00:17:39Und es macht nicht besonders viel Spaß, zumindest mir nicht.
00:17:41Wenn man also drei Agenten einsetzt,
00:17:44muss man den Output von drei Agenten prüfen.
00:17:45Man kann die Anzahl reduzieren, wenn es zu viel wird
00:17:48und man merkt, dass man so nicht wirklich produktiv ist.
00:17:51Als Open-Source-Maintainer auf GitHub jedoch
00:17:54ertrinkt man in KI-generierten Inhalten
00:17:57und hat im Grunde zwei Hauptoptionen.
00:17:59Man kann sie ignorieren, was natürlich den Zweck verfehlt,
00:18:00Oder du versuchst, dich durch sie hindurchzuarbeiten
00:18:03Oder man versucht, sich durchzuarbeiten
00:18:07und brennt aus, weil es einfach zu viel ist,
00:18:09denn anders als bei der eigenen privaten Arbeit
00:18:13kann man die Menge der eingehenden Issues
00:18:16und Pull Requests nicht einfach drosseln.
00:18:18Bei sich selbst kann man weniger Agenten nutzen,
00:18:21wenn man merkt, dass man nicht effektiv arbeitet.
00:18:25Bei öffentlichen Repositories geht das nicht.
00:18:29Man kann nicht kontrollieren, wie viele Leute KI-generierte
00:18:30Issues posten oder Pull Requests mit einem teilen.
00:18:33Das ist also ein riesiges Problem für Open-Source-Maintainer,
00:18:36weshalb die gesamte Open-Source-Szene
00:18:38und die Philosophie dahinter
00:18:41wegen der KI gerade in großen Schwierigkeiten stecken.
00:18:45Und GitHub hilft dabei nicht.
00:18:49Stattdessen tun sie das Gegenteil.
00:18:53Sie machen es aktiv einfacher, diesen „KI-Slop" zu verbreiten.
00:18:56Was Maintainer und Entwickler bräuchten,
00:18:59wären effektivere Werkzeuge, um mit all diesen
00:19:04KI-generierten Inhalten umzugehen.
00:19:06Aber GitHub arbeitet nicht daran.
00:19:08Es ist wohl nicht Teil ihrer Strategie.
00:19:13Vielleicht wird sich das ja ändern.
00:19:15Der offizielle Post von GitHub, den ich vorhin erwähnte,
00:19:18spricht primär über Zuverlässigkeit und Uptime-Probleme
00:19:22und darüber, dass sie transparenter sein wollen.
00:19:25Aber sie erwähnten auch ihre Verpflichtung,
00:19:27Entwickler zu unterstützen.
00:19:29Wir werden sehen; ich bin nicht allzu optimistisch,
00:19:30da es letztlich Teil von Microsoft ist
00:19:35und die ihre ganz eigene Strategie verfolgen.
00:19:39Aber was bedeutet das dann für GitHub?
00:19:41Ist es Zeit für eine Migration?
00:19:44Ich habe hier und da auf X Stimmen gehört,
00:19:46dass es jetzt Zeit für eine GitHub-Alternative sei.
00:19:49Ich weiß, dass einige Projekte bereits migriert sind.
00:19:52Zig ist vielleicht das prominenteste Beispiel.
00:19:55Sie sind im November 2025 von GitHub zu Codeberg gewechselt.
00:19:59Aber seien wir mal realistisch.
00:20:02Zum einen würde die Menge an Traffic,
00:20:05die GitHub trifft, auch jeden Konkurrenten überwältigen.
00:20:08Wahrscheinlich sogar noch mehr als GitHub,
00:20:12da diese nicht Teil von Microsoft sind.
00:20:15Wahrscheinlich sogar mehr als GitHub
00:20:20Und während einige einzelne Projekte,
00:20:22besonders Open-Source-Projekte, GitHub verlassen mögen –
00:20:24aus Gründen, die ich absolut nachvollziehen kann –,
00:20:28werden all diese Firmen und Einzelentwickler
00:20:31wahrscheinlich nicht abwandern.
00:20:32GitHub bietet trotz aller Probleme
00:20:35eine funktionsreiche Plattform mit Features,
00:20:40die fester Bestandteil vieler Workflows sind.
00:20:42Besonders für Unternehmen ist es natürlich
00:20:45nicht einfach, GitHub mal eben durch
00:20:48einen anderen Anbieter zu ersetzen.
00:20:52Auch wenn die Zuverlässigkeitsprobleme
00:20:54natürlich auch für Firmen ein riesiges Thema sind,
00:20:57werden sie bereit sein, noch viel mehr Schmerz zu ertragen,
00:21:02bevor sie einen Wechsel überhaupt in Erwägung ziehen.
00:21:06Da bin ich mir sicher.
00:21:08GitHub ist einfach eine zu wichtige Plattform.
00:21:11Es ist die Plattform, um seinen Git-Code
00:21:13in die Cloud zu bringen und dort zusammenzuarbeiten.
00:21:15Ich bin also sicher, dass es nicht verschwinden wird,
00:21:18selbst wenn die Situation noch schlimmer würde.
00:21:23Natürlich würden die Leute irgendwann gehen,
00:21:25wenn GitHub gar nichts unternehmen würde,
00:21:26aber das tun sie ja offensichtlich,
00:21:30zumindest was die Uptime und Zuverlässigkeit angeht.
00:21:35Was die Open-Source-Arbeit und den „KI-Slop" betrifft,
00:21:39müssen wir abwarten.
00:21:43Doch selbst dort glaube ich, dass GitHub zu wichtig ist
00:21:45und zu viele Vorteile für Maintainer bietet,
00:21:47als dass alle einfach so gehen würden.
00:21:49Aber ich verstehe absolut, wenn einzelne Projekte
00:21:50GitHub den Rücken kehren; das mag passieren.
00:21:55Aber für Unternehmen und GitHub im Allgemeinen
00:21:58wird es erst einmal so bleiben.
00:22:01Trotzdem kann man nur hoffen, dass diese Situation
00:22:07vielleicht ein Weckruf für Microsoft ist.
00:22:10Vielleicht setzen sie wieder einen CEO für GitHub ein.
00:22:14Vielleicht verstehen sie die Bedeutung der Plattform.
00:22:17Vielleicht verstehen sie, dass es eine Entwickler-
00:22:20und Entwicklungsplattform ist, keine reine KI-Plattform.
00:22:23Aber ja, man kann nur hoffen.
00:22:24Ich weiß nicht, ob und wann das passieren wird.
00:22:28Aber ja, das ist die aktuelle GitHub-Situation.
00:22:33Sie ist schlecht, wirklich schlecht.
00:22:38Und das wird sie in naher Zukunft auch bleiben,
00:22:41aber zumindest die Zuverlässigkeit wird hoffentlich
00:22:45später in diesem Jahr besser werden.
00:22:49Wir werden sehen.
00:22:55Wir werden sehen, schätze ich.