Zig verlässt GitHub wegen Microsofts KI-Besessenheit

 (theregister.com)
6 Punkte von GN⁺ 2025-12-04 | 1 Kommentare | Auf WhatsApp teilen
  • Die Zig-Programmierstiftung verließ GitHub aufgrund von Qualitätsproblemen bei GitHub und der KI-zentrierten Ausrichtung von Microsoft und beschloss den Umzug zu Codeberg
  • In GitHub Actions wurde ein über Jahre vernachlässigter Bug in safe_sleep.sh zum Fall eines stillgelegten CI-Systems
  • Die Zig-Seite kritisiert, dass GitHub seine Technische Qualität zugunsten einer KI-zentrierten Strategie opfert
  • Jeremy Howard, Mitgründer von Fast.AI, wies ebenfalls auf mangelhafte Bug-Bearbeitung und sinkende Codequalität bei GitHub hin
  • Der Trend, dass Open-Source-Projekte GitHub verlassen, nimmt zu, während der Widerstand gegen eine plattformpolitische KI-Kommerzialisierung wächst

Hintergrund des GitHub-Ausstiegs der Zig Foundation

  • Die Zig Software Foundation, die die Programmiersprache Zig betreut, beschloss, GitHub zu verlassen und zu Codeberg, einem gemeinnützigen Git-Hosting-Dienst, zu wechseln
    • Der Grund: Die Einschätzung, dass GitHub sich nicht mehr der Ingenieurskunst verschreibt
  • Andrew Kelly nannte den in GitHub Actions gefundenen safe_sleep.sh-Endlosschleifen-Bug als prominentes Beispiel
    • Das Skript nahm 100 % der CPU ein und lief unendlich weiter
    • Dadurch kam der CI-Runner von Zig über mehrere Wochen zum Stillstand

Technische Probleme von GitHub Actions

  • Ursache war eine Codeänderung im Februar 2022, bei der der POSIX-Befehl sleep durch das safe_sleep-Skript ersetzt wurde
    • Das Skript gelangt in eine Endlosschleife, wenn es ein bestimmtes Sekunden-Timing verpasst
  • Der Bug wurde erst am 20. August 2025 behoben, der zugehörige Issue blieb jedoch bis zum 1. Dezember offen
  • Ein weiterer CPU-Überlastungs-Bug ist weiterhin ungeklärt

Reaktion von Community und Experten

  • Jeremy Howard (Mitgründer von Fast.AI) bezeichnete den Zustand von GitHub Actions als „offensichtlich mangelhaft“
    • Er kritisierte, dass ein Code, der 100 % CPU beanspruchte, ein Jahr lang unbeachtet blieb
    • „Ein sauber geführtes Unternehmen kann sich diese Kette von Fehlern nicht immer wieder leisten“
  • Kelly entschuldigte sich später dafür, dass seine Aussagen zu hart gewesen seien, betonte aber weiterhin die Qualitätsprobleme bei GitHub

Abwanderungsbewegung anderer Projekte

  • Auch Rodrigo Arias Mallo, der Gründer des Dillo-Browser-Projekts, kündigte an, GitHub zu verlassen
    • Er kritisierte die JavaScript-Abhängigkeit, mögliche Denial-of-Service-Szenarien sowie einen LLM- und generativ-ki-zentrierten Betrieb
    • Er sagte, dass „generative KI das offene Web zerstöre“
  • Seit Januar 2025 ist die Zahl der Unterstützer-Mitglieder bei Codeberg von 600 auf über 1.200 mehr als verdoppelt

KI-zentriertes Geschäftsmodell von GitHub

  • Microsoft-CEO Satya Nadella berichtete im Ergebnis zum zweiten Quartal 2024
    • Er nannte über 1,3 Millionen zahlende GitHub Copilot-Abonnenten, ein Anstieg von 30 % zum Vorquartal
  • 2024 machten rund 40 % der 2 Milliarden US-Dollar Jahresumsatz von GitHub Copilot-Abonnements aus
  • Im dritten Quartal 2025 meldete GitHub über 15 Millionen Copilot-Nutzer, viermal so viele wie im Vorjahr
  • GitHub gibt weiterhin keine Zahlen zu zahlenden Nutzern preis und hebt stattdessen die auf Copilot basierte Umsatzstruktur hervor

Fazit

  • Die Fälle von Zig und Dillo zeigen, dass eine Plattform mit Fokus auf KI-Kommerzialisierung das Vertrauen der Entwicklerinnen und Entwickler untergräbt
  • Eine KI-fokussierte Strategie von GitHub bei gleichzeitig mangelnder Qualitätskontrolle hat die Abwanderung aus der Open-Source-Community ausgelöst
  • Das Wachstum von alternativen, gemeinnützigen Plattformen wie Codeberg beschleunigt sich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-04
Hacker-News-Kommentar

  • Die Änderungshistorie der Bekanntmachung des Zig-Teams ist ziemlich interessant.
    Zunächst wurde das GitHub-Team als „fehlerverseuchtes JS-Framework von inkompetenten Zurückgebliebenen“ angegriffen, später wurde die Formulierung jedoch abgeschwächt.
    In der finalen Version wurde es darauf reduziert, dass GitHubs „technische Exzellenz“ verschwunden sei.
    Frühe Version (11/27 02:10) → Zwischenstand (11/27 14:04) → Endversion (11/28 09:21)

    • Im vorherigen HN-Thread gab es viel Feedback in Richtung „nehmt die politischen Emotionen raus“, und es scheint, als hätte das Zig-Team das angenommen.
      Beeindruckend ist, dass sie für die Community ihren Stolz zurückgestellt und nachgebessert haben.
    • Die Besessenheit und Wut, die Kelly in Bezug auf „technische Exzellenz“ zeigt, wirkt eher wie ein Hinweis auf Zigs gute Zukunft.
      Ich halte es für ein gutes Zeichen, wenn eine technische Führungskraft über Mittelmaß wütend ist.
    • Ein Vorwurf wie in der ersten Fassung, schlechte Software sei „absichtlich“ so, geht zu weit.
      In Wirklichkeit ist sie nur das Ergebnis von begrenzten Rahmenbedingungen und Fähigkeiten.
    • Wut trübt das Urteilsvermögen.
      Ich glaube, dass mit Liebe entwickelte Software, also mit Zuneigung zu Technik und Menschen, zu besseren Ergebnissen führt.
    • Mit der Formulierung „bloated, buggy JS framework“ kann ich mich identifizieren.
      Riesige Unternehmen pumpen Geld hinein, um solche Frameworks am Leben zu halten, und Hunderte Millionen Menschen benutzen sie, ohne sie überhaupt deaktivieren zu können.
      Wenn ich GitHub nutze, lasse ich überhaupt kein JS ausführen und lade per Proxy-Regeln nur die Raw-Dateien herunter. 
      http-request set-path %[path,regsub(/blob/,/raw/,g)] if { hdr(host) github.com }
http-request set-path %[path,regsub(/releases/tag/,/releases/expanded_assets/,g)] if { hdr(host) github.com }
      So funktioniert es gut.

  • GitHubs Stärke ist das Ökosystem.
    PR-System, Issue-Management, CI-Actions, Sponsoring — alles ist an einem Ort gebündelt.
    Die AI-Besessenheit ist beunruhigend, aber ich halte es immer noch für das bequemste Werkzeug für Entwickler.

    • Sehe ich anders. GitHubs wahre Stärke ist der soziale Netzwerkeffekt.
      Kennzahlen wie Stars, Forks und Follower-Zahlen dienen als Qualitätssignale.
      Letztlich vertrauen Entwickler dem „Blick der Community“.
    • Ich habe früher Gerrit benutzt und fand GitHub-PRs nicht besonders besser.
      Actions ist so komplex und so häufig gestört, dass man fast von YAML-Hölle sprechen kann.
      Trotzdem ist der wichtigste Grund, dass es „der Ort ist, den alle benutzen“.
    • Ich kann der Aussage nicht zustimmen, dass das CI-System gut gebaut sei.
      Actions ist bequem, aber ein schreckliches Produkt.
    • Ich würde lieber den Advent of Code in brainfuck lösen.
      GitHub Actions zu debuggen ist pures Leiden.
    • Mich stört, dass GitHub nie bestritten hat, private Repositories für AI-Training verwendet zu haben.
      GitLab hat das klar verneint, und dieser Unterschied untergräbt das Vertrauen.

  • Ich war neugierig auf die Infrastruktur von Codeberg und habe nachgeschaut.
    Laut offiziellem Blogpost
    läuft der Dienst auf drei Servern (1× Gigabyte, 2× Dell R730/R740), wobei die Wiederverwendung gebrauchter Hardware betont wird.
    Es gibt sogar den Versuch, ein kaputtes MacBook als CI-Runner wiederzuverwenden.
    Es kommt gelegentlich zu Performance-Einbrüchen, die sich aber wohl per Neustart beheben lassen.
    Das hat etwas von der DIY-Atmosphäre eines Hackerspaces.

    • Auf der Statusseite sieht man eine geringe Verfügbarkeit.
      In den letzten 24 Stunden lag die Uptime bei 89 %, der 14-Tage-Durchschnitt bei 98 %, aber die Hauptseite ist oft langsam.
    • Codeberg ist keine Plattform für Unternehmen, sondern nur für FLOSS.
      Das Ziel ist nicht, einen kommerziellen Dienst anzubieten.
    • Ich selbst habe mit 20 schon größere Cluster betrieben.
      Allein der Strom hat mich mehr als 600 Dollar im Monat gekostet — bei dem Niveau könnte ich wohl auch einen kostenlosen Dienst aufmachen.
      Wer Ideen hat, soll mir mailen.

  • Wenn man sich Zigs Umgang mit GitHub-Issues ansieht, wirkt die Entscheidung etwas emotional.
    Bugs gibt es überall, und bei GitHubs Größenordnung ist das unvermeidlich.
    Der Wechsel zu Codeberg wirkt nicht besonders gründlich diskutiert.
    Zig ist technisch hervorragend, aber eine reife Führungsstruktur scheint sich noch nicht ganz etabliert zu haben.

    • Das Problem sind weniger die Bugs als vielmehr die Gleichgültigkeit großer Konzerne.
      Ein Unternehmen wie Microsoft kümmert sich nicht darum, wie unzufrieden Kunden sind.
      Deshalb hofft man beim Wechsel auf eine kleinere Plattform auf Support, der stärker am Kundenerfolg interessiert ist.
      CI-Skripte sollte man möglichst als reine Skripte halten, damit die Portabilität hoch bleibt.
    • Dass jemand „Codeberg nicht kannte“, ist ein persönliches Problem.
      Es gibt auch keinen Beleg dafür, dass es keine internen Diskussionen gab.

  • Ich teile die Kritik an GitHub, aber Codeberg ist oft nicht verfügbar.
    Laut Statusseite lag die Uptime in den letzten zwei Wochen nur bei etwa 95 %.

    • GitHub Actions hat ebenfalls häufig Ausfälle, daher fühlt sich der Unterschied gar nicht so groß an.
    • Wenn einem das Service-Level wichtig ist, ist selbst gehostetes Forgejo die bessere Wahl.
      Dann hängt man nicht wie bei GitHub an einem Single Point of Failure.
    • Auch auf Reddit gab es Beschwerden, dass Codebergs Bot-Verifizierungsprozess umständlich sei.
      Trotzdem ist selbst hostbares Forgejo attraktiv.
    • Codeberg wird häufig Ziel von DDoS-Angriffen.
      Auf dem Mastodon-Account wird die Lage transparent kommuniziert.
      Dass es angegriffen wird, könnte auch ein Zeichen dafür sein, dass es relevant genug ist, um aufzufallen.
    • Codeberg ist eine reine Open-Source-Plattform.
      Für kommerzielle Projekte oder persönliche Backups ist es ungeeignet.

  • Ich habe das Gefühl, dass das Wort AI inzwischen zu einem Marketingbegriff verkommen ist.
    In zwei Jahren werden AI-Funktionen wohl in den meisten Apps weiter existieren, aber Slogans wie „AI-first“ dürften verschwunden sein.

    • So war es in den letzten 15 Jahren immer.
      Der Einschätzung stimme ich trotzdem zu — inzwischen wirkt AI-Werbung einfach peinlich.
    • Es sind nur Schlagworte wie „Big Data“ und „Machine Learning“, die sich ausgetauscht haben.
      Personalisierte Werbung ist weiterhin da, auch wenn das Konzept selbst unerquicklich ist.

  • GitHubs Umbau des Dashboard-Feeds war eine Katastrophe.
    Auch in dieser Diskussion gibt es viel Unmut.

    • Mit einem aktuellen Update wurde der Fokus auf Listen mit jüngsten PRs und Issues gelegt, und das fühlt sich für mich eher wie eine Verbesserung an.
      Ich nutze es tatsächlich häufig.
    • Ehrlich gesagt nutze ich das Dashboard selbst gar nicht.
      Meist arbeite ich direkt von den Projektseiten aus.
    • Ich nutze die Benachrichtigungsseite ebenfalls als Startseite.
      Dank Browser-Autovervollständigung reicht schon „not“, um direkt dort zu landen.

  • Zigs Grund für den Wechsel ist nicht einfach nur Misstrauen gegenüber Microsoft.
    Zig ist schon immer eine Community mit starken Meinungen gewesen.
    Auch GitLab ist nicht wirklich zufriedenstellend, und es gibt nicht viele Alternativen.
    Das eigentliche Problem ist die monopolartige Struktur großer Konzerne, und AI verschärft dieses Problem noch.

    • Mich würde interessieren, wie es Bitbucket heutzutage geht.
      Es wirkt inzwischen fast bedeutungslos.

  • Der Vorteil von Codeberg ist die Ladegeschwindigkeit der Seiten.
    GitHub wirkt oft langsam und schwergewichtig.

    • Gerade in instabilen 4G-Umgebungen ist GitHub schrecklich.
      Im Vergleich zu Diensten wie Linear ist der Unterschied groß.
    • In meinen Tests war Codeberg dagegen langsamer. 
      $ time curl -L 'https://codeberg.org/'  → 3.06s  
$ time curl -L 'https://github.com/'    → 1.35s
      Hängt vermutlich von der Umgebung ab.

  • Ich möchte Fossil SCM empfehlen.
    Das ist ein Werkzeug vom SQLite-Macher, das in einer einzigen 6-MB-Binärdatei Funktionen auf GitHub-Niveau integriert.
    Mehr dazu auf fossil-scm.org.

    • Es hat allerdings kein Code-Review-System.
      Das liegt daran, dass der Gründer fast keine externen Beiträge annimmt.
      Für Ein-Personen-Projekte ist es großartig, für Zusammenarbeit aber ungeeignet.
    • Für persönliche Projekte ist es trotzdem hervorragend.
      Ich würde es beim nächsten Side-Project unbedingt ausprobieren.