GitHub verlassen und zu Forgejo wechseln

 (jorijn.com)
1 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der unmittelbare Anlass, GitHub zu verlassen, ist nicht der Ausfall im April 2026, sondern die Frage des Eigentums an Code und Workflows, die auf GitHub ausgeführt werden
  • GitHub wurde nach August 2025 ohne eigenen CEO in die CoreAI division von Microsoft eingegliedert, und der Code fällt damit unter die Microsoft-AI-Organisation
  • Bei Copilot Free, Pro und Pro+ wurde ab April 2026 auf ein Opt-out-Modell umgestellt, bei dem Interaktionsdaten standardmäßig als Trainingsdaten verwendet werden
  • GitHub und Microsoft sind US-Unternehmen und unterliegen daher FISA 702 und dem CLOUD Act; eine EU Data Residency allein löst das Problem nicht
  • Forgejo v15 LTS läuft auf code.jorijn.com auf einem einzelnen NUC; Runner sind durch KVM, gVisor, wöchentliche Rebuilds und Egress-Filter isoliert

Warum ich GitHub verlasse: nicht wegen Ausfällen, sondern wegen Eigentum

  • Der Ausfall im April 2026 war für Entwickler zwar gravierend, aber der Hauptgrund, GitHub zu verlassen, ist nicht der Ausfall selbst, sondern das Eigentum an Code und Workflows, die auf GitHub laufen
  • Am 27. April 2026 startete das niederländische Innenministerium seine selbst gehostete Forgejo-Instanz für staatlichen Quellcode, code.overheid.nl, im Soft Launch
    • Projektmanager Boris Van Hoytema erklärte, dass die Plattform aus der Anforderung heraus entstanden sei, dass Ministerien Quellcode an einem Ort veröffentlichen müssen, den sie rechtlich „besitzen“
    • Forgejo wurde gegenüber GitLab bevorzugt, weil es vollständig Open Source ist und die für digitale Souveränität notwendige Freiheit bietet
  • Auch der Standard-Git-Host für persönlichen Code wurde zu code.jorijn.com verlagert; dort läuft Forgejo v15 LTS in einer gehärteten Konfiguration auf einem einzelnen NUC
    • Ein Teil der Repositories wurde bereits migriert, der Rest steht noch aus
    • Nach Abschluss der Migration sollen die öffentlichen GitHub-Repositories archiviert werden und jeweils auf den neuen Standort verweisen

Ausfälle und AI-Last

  • Am 23. April 2026 setzte der Squash-Merge-Codepfad der Merge Queue nach einem unvollständigen Rollout hinter einem Feature-Flag bereits gemergte Commits in 658 Repositories und 2.092 Pull Requests stillschweigend zurück
    • Unternehmen wie Modal und Zipline stellten die Daten manuell wieder her
    • Vier Tage später fielen Pull Requests, Issues und Packages wegen eines überlasteten Elasticsearch-Clusters für mehr als sechs Stunden aus
  • Allein im Februar 2026 wurden 37 Incidents verzeichnet, darunter auch ein Ausfall von 3 Stunden und 40 Minuten, bei dem Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot und Pages gleichzeitig nicht verfügbar waren
  • Am 1. Oktober 2025 kam es zu einem 10-stündigen Ausfall der macOS-Runner
  • Laut der Erfassung von IncidentHub verzeichnete GitHub von Mai 2025 bis April 2026 257 Incidents und 48 größere Ausfälle, mit insgesamt rund 112 Stunden Downtime
  • GitHub-CTO Vlad Fedorov entschuldigte sich am 28. April und erklärte, dass zur Bewältigung der Last durch das seit Dezember 2025 gewachsene „agentic AI workflow growth“ eine 30-fache Kapazitätserhöhung nötig sei
    • Die Zuverlässigkeitsprobleme werden als Folge des Ausbaus der AI-Funktionen interpretiert
    • GitHub treibt die AI-Funktionen weiter voran, statt sie zu bremsen
  • The Pragmatic Engineer weist darauf hin, dass GitLab, Bitbucket, Vercel, Linear und Sentry im selben Jahr nichts Vergleichbares erlebt haben
    • Auch sie stehen unter dem Druck der Entwicklernachfrage, daher wirkt das Ausfallmuster wie ein GitHub-spezifisches Problem

Organisatorische Veränderungen bei GitHub

  • Am 11. August 2025 trat Thomas Dohmke als GitHub-CEO zurück, und Microsoft setzte keinen Nachfolger ein
  • GitHub wurde in Microsofts CoreAI division eingegliedert
  • Umsatz, Engineering und Support von GitHub berichten an die Microsoft Developer Division unter Julia Liuson
    • Der GitHub-CPO berichtet an den VP der Microsoft AI Platform
    • Die Marke bleibt bestehen, aber die unabhängige Führung ist verschwunden
  • Die Einschätzung, dass Microsoft GitHub von 2018 bis 2024 mit einer gewissen Distanz betrieben habe, war faktisch zutreffend; seit August 2025 lässt sich diese Annahme jedoch kaum noch aufrechterhalten
  • Code auf github.com zu pushen bedeutet heute, Code an eine Einheit innerhalb von Microsofts AI-Organisation zu pushen

Änderung der Standardwerte für Copilot-Trainingsdaten

  • GitHub kündigte am 25. März 2026 eine Änderung der Datenschutzrichtlinie an, die ab dem 24. April gilt
    • Interaktionsdaten von Copilot-Free-, Pro- und Pro+-Nutzern, insbesondere Eingaben, Ausgaben, Code-Snippets und relevanter Kontext, werden zur Schulung und Verbesserung von AI-Modellen verwendet, sofern Nutzer nicht widersprechen
  • Die entscheidende Änderung ist, dass es sich nicht um Opt-in, sondern um Opt-out handelt
    • Nutzer von Copilot Free, Pro und Pro+ tragen zur Modellschulung bei, wenn sie dies nicht auf der Copilot-Einstellungsseite deaktivieren
  • Es gibt keine Sperre auf Repository-Ebene
    • Administratoren können GitHub nicht vorgeben, Interaktionen innerhalb bestimmter Repositories nicht für das Training zu verwenden
    • Das Opt-out ist eine Einstellung pro Nutzerkonto, daher muss jeder Beitragende selbst entscheiden
    • In der Praxis kann eine Codebasis zum Trainingsmaterial werden, sobald Copilot-Free-/Pro-/Pro+-Nutzer mit dem Repository arbeiten, unabhängig von der Lizenz
  • Die Ausnahme für private Repositories gilt nur eingeschränkt
    • GitHub sagt, dass „at rest“-Inhalte aus privaten Repositories nicht für das Training verwendet werden
    • Allerdings werden „code snippets and interaction context“, die bei der Nutzung von Copilot innerhalb privater Repositories entstehen, erfasst
    • Die Grenze zwischen „ruhenden Codebeständen“ und „während der Bearbeitung erzeugten Ausschnitten“ ist unscharf
  • Kunden von Copilot Business und Copilot Enterprise sind ausgenommen, da für sie separate Data Protection Agreements gelten
    • Wer genug bezahlt, dessen Interaktionen werden nicht zu Trainingsdaten; ansonsten werden sie zu Trainingsdaten
  • GitHubs strategisches Interesse an Nutzerinteraktionsdaten ist damit nicht länger ein optionales, sondern ein strukturelles Element

Jurisdiktionsrisiken lassen sich nicht durch den Datenstandort lösen

  • GitHub Inc. und Microsoft Corp. sind US-Unternehmen, und die von ihnen gehaltenen Daten fallen in den Geltungsbereich von US-Gesetzen, darunter FISA Section 702 und der CLOUD Act von 2018
    • Beide Gesetze können unabhängig davon gelten, wo sich die Daten physisch befinden
  • Section 702 wurde im April 2024 für zwei Jahre erneut genehmigt und gilt durch eine Ende April 2026 unterzeichnete 45-Tage-Verlängerung weiter
    • Sie erlaubt US-Geheimdiensten die Sammlung von Daten über Nicht-US-Personen über in den USA ansässige Anbieter elektronischer Kommunikationsdienste
  • Der CLOUD Act kann Unternehmen mit Hauptsitz in den USA dazu zwingen, Daten herauszugeben, die irgendwo auf der Welt gespeichert sind
  • GitHub kündigte im Oktober 2024 die allgemeine Verfügbarkeit der EU-Datenresidenz für Enterprise Cloud an
    • Das behandelt das Problem des Datenstandorts, löst aber nicht das Jurisdiktionsproblem
    • Die Exponierung gegenüber dem CLOUD Act folgt nicht dem geografischen Ort, sondern der Unternehmensstruktur
  • Ein Anwalt von Microsoft antwortete im Juni 2025 unter Eid bei einer Anhörung im französischen Senat, dass er nicht garantieren könne, dass französische Daten, die in europäischen Microsoft-Rechenzentren gespeichert sind, vor stillem Zugriff der US-Regierung sicher sind
  • Solange sich Code auf github.com befindet, liegt dieser Code im rechtlichen Wirkungsbereich der USA
    • EU-Datenresidenz kann beruhigend wirken, ist aber keine Lösung

Die Wahl von code.overheid.nl durch die niederländische Regierung

  • Der rechtliche Hintergrund dieser Entscheidung der niederländischen Regierung ist die seit 2020 geltende Politik „Open, tenzij“
    • Mit öffentlichen Mitteln entwickelte Software wird standardmäßig Open Source, sofern nicht Sicherheit oder Vertraulichkeit dagegensprechen
    • Um das einzuhalten, brauchten die Ministerien einen Ort, an dem sie Code veröffentlichen können, den sie tatsächlich kontrollieren
  • Die Europäische Kommission betreibt seit September 2022 das selbst gehostete, auf GitLab basierende code.europa.eu
  • Deutschlands openCode basiert ebenfalls auf GitLab
  • Frankreichs code.gouv.fr ist keine eigene Forge, sondern ein Aggregator, der anderswo gehostete Repositories indiziert
  • Die niederländische Regierung entschied sich bewusst für Forgejo statt für GitLab
    • Laut OSOR lag der Grund darin, dass Forgejo vollständig Open Source ist, keine Open-Core-Aufspaltung hat und alle für digitale Souveränität nötigen Freiheiten bietet
    • Van Hoytema ergänzt, dass die Forgejo-Roadmap deutlich stärker „way more aligned“ gewesen sei als die der Alternativen
  • Die niederländische Regierung wollte nicht nur eine souveräne Forge, sondern eine souveräne Forge, die nicht hinter den Premium-Tiers eines kommerziellen Anbieters eingeschlossen ist
  • Auch Regierungen sehen dieselbe Problemlage und treffen dieselbe Entscheidung; die Wahl von Forgejo ist damit kaum noch als Randentscheidung zu betrachten

Warum Forgejo gewählt wurde

  • GitLab wurde ebenfalls ernsthaft geprüft
    • Selbst gehostetes GitLab CE ist eine bekannte Option und verfügt über ein größeres kommerzielles Ökosystem sowie eine stärker ausgereifte UI

  • Lizenz

    • GitLab verfolgt ein Open-Core-Modell
      • Die Community Edition steht unter der MIT-Lizenz, aber viele Funktionen, die man im Betrieb tatsächlich will, liegen im Enterprise-Tier unter nicht-freien Lizenzen
    • Forgejo geht den entgegengesetzten Weg
      • Seit v9.0 im August 2024 wurde es von MIT auf GPLv3+ umlizenziert
      • Das ausdrückliche Ziel ist, Copyleft zu bewahren und eine künftige kommerzielle Vereinnahmung der Codebasis zu verhindern
    • Der Grund dafür, dass Forgejo im Dezember 2022 von Gitea geforkt wurde, war ebenfalls, dass Gitea Ltd Markenname und Domain ohne Zustimmung der Community kontrollierte
      • Diese Lehre spiegelt sich in der Lizenzwahl wider

  • Governance

    • Forgejo steht unter Codeberg e.V.
      • Codeberg e.V. ist ein seit September 2018 in Berlin eingetragener gemeinnütziger Verein
      • Er hat einen von den Mitgliedern gewählten Vorstand, ein offenes Budget und mehr als 300.000 Repositories auf der Hosting-Instanz
    • Die Mitglieder stimmen jedes Jahr über das Budget ab
      • Der Plan für 2025 wurde mit 88 Ja-Stimmen, 0 Nein-Stimmen und 1 Enthaltung angenommen

  • Releases und Reifegrad

    • Forgejo v15.0 LTS wurde am 16. April 2026 veröffentlicht
      • Es ist das 100. Release des Projekts
      • Der Long-Term Support läuft bis zum 15. Juli 2027
    • Forgejo Actions erreichte in v15 das benötigte Niveau
      • Enthalten sind ephemeral runner, OpenID Connect und reusable workflow expansion
    • Seit dem Fork erscheinen Releases kontinuierlich, auch die Monatsberichte sind rege

  • Grenzen des kommerziellen Ökosystems

    • Ein kommerzielles Ökosystem für Forgejo existiert, ist aber dünn
    • Das derzeit sauberste kommerzielle Produkt ist Codey by VSHN
      • Es ist ein in der Schweiz gehostetes Managed-Forgejo-Angebot, das im März 2025 auf Servala gestartet wurde
      • Es beginnt bei 19 CHF pro Monat
    • Ein Enterprise-Support-Abo nach Art von Red Hat gibt es nicht
    • Wer 24/7-Telefonsupport und einen haftenden Anbieter braucht, muss es selbst aufbauen oder warten

Aufbau von code.jorijn.com

  • code.jorijn.com läuft auf einem einzelnen Intel NUC im Homeoffice
    • Der RAM beträgt 64 GB
    • Forgejo v15 LTS, Postgres 17 und Traefik laufen in Docker
    • Eine von Incus verwaltete KVM-VM betreibt daneben den Forgejo-Actions-Runner
  • Wichtiger als das eigentliche Deployment von Forgejo, Postgres und Reverse Proxy ist die Konfiguration des Runners

Der Runner ist der riskanteste Teil

  • Bei einer selbst gehosteten Forge ist die Forge selbst der einfache Teil; schwierig ist die Umgebung, in der CI-Jobs ausgeführt werden
  • Der Runner muss nach dem täglichen Renovate-Zeitplan npm install, composer install und pip install ausführen
    • Ziel sind Lockfiles, die im eigenen Repository erzeugt wurden
    • Das bedeutet die Ausführung von lifecycle scripts
    • Jeder Job kann potenziell nicht vertrauenswürdigen Code ausführen
  • Es besteht dasselbe Risiko wie bei jüngsten npm-Würmern und Supply-Chain-Angriffen auf axios, die über Dependency-Bots liefen, die innerhalb einer Stunde automatisch mergen
  • Die Aufgabe des Runners ist nicht, Code auszuführen, sondern den laufenden Code zu isolieren
    • Das Design geht davon aus, dass eine einzelne Verteidigungsschicht versagen kann, und sorgt dafür, dass die nächste Schicht den Ausfall abfängt

Verteidigungsschichten für Runner

  • Persistente KVM-virtuelle Maschinen

    • Der Runner befindet sich nicht in einem Container auf dem Host, sondern in einer separaten KVM-VM
    • Die Arbeitsumgebung teilt sich nicht den Host-Kernel
    • Damit eine Linux-Kernel-CVE innerhalb des Runners den NUC erreicht, müsste zuerst die KVM-Grenze durchbrochen werden

  • Verwendung von gVisor als Standard-Docker-Runtime innerhalb der VM

    • Arbeits-Container laufen unter runsc
    • runsc reicht Systemaufrufe nicht direkt an den Host-Kernel weiter, sondern fängt sie im Userspace ab
    • Für einen Container-Escape müssten sowohl gVisor als auch die umgebende KVM-Schicht durchbrochen werden

  • Wöchentliche destruktive Rebuilds

    • Jeden Montag um 02:00 UTC wird die komplette VM gelöscht und aus einem neuen Ubuntu-Base-Image neu erstellt
    • Auch eine neue persistente Runner-Registrierung für Forgejo wird dabei erneut ausgestellt
    • Das Base-Image wird am Sonntag neu gebaut, daher übernimmt die neue VM die apt- und Kernel-Patches dieser Woche
    • Persistenter Zustand kann nicht länger als 7 Tage erhalten bleiben

  • nftables-Egress-Filter auf der Runner-Bridge

    • Der Runner kann öffentliche Ziele auf :443, :80, :22 und :53 erreichen
      • Dazu gehören npm, pypi, ghcr sowie das eigene Forgejo, das über Hairpin NAT unter einem öffentlichen Hostnamen erreichbar ist
    • Auf 192.168.0.0/16, 10.0.0.0/8 und 172.16.0.0/12 kann nicht zugegriffen werden
    • Ein kompromittierter Job kann das LAN nicht scannen und weder die Router-Admin-Oberfläche noch andere Dienste des Hosts erreichen

  • Bereichsgebundene Runner-Tokens

    • Die beiden persistenten Runner-Registrierungen sind jeweils an einen einzelnen Benutzerbereich und einen einzelnen Organisationsbereich gebunden
    • Für die Verwaltung wird der PAT-Umfang write:user,write:organization verwendet
    • Ein geleakter Token kann keinen Runner außerhalb seines Bereichs registrieren und auch keine Aufgaben mit Admin-Scope ausführen
    • Die Schichten sind absichtlich so aufgebaut, dass sie sich überlappen
    • Jede Schicht ist ein Zaun, zusammen bilden sie eine tief gestaffelte Grenze
    • KVM-Isolation, gVisor, wöchentliche Rebuilds und scope-gebundene Runner-Registrierung sind alles Komponenten, die von Forgejo und Incus standardmäßig unterstützt werden

Dinge, auf die ich verzichtet habe

  • Auffindbarkeit und Social Graph

    • GitHub ist der Ort, an dem Beitragende Repositories finden
    • Wer kleine Änderungen an einem öffentlichen Repository senden möchte, erwartet, auf github.com zu arbeiten und nicht auf einer unbekannten Domain
    • Nach Abschluss des Umzugs ist geplant, jedes öffentliche GitHub-Repository zu archivieren und das README auf code.jorijn.com verweisen zu lassen
    • Der Auffindungspfad bleibt erhalten
      • Menschen finden das Repository weiterhin auf GitHub, sehen den Archiv-Hinweis und wechseln dann zum kanonischen Zuhause
    • Das ist noch nicht abgeschlossen; nur einige Repositories liegen bereits auf code.jorijn.com, der Rest wartet noch

  • Fragile Kompatibilität des GitHub-Actions-Ökosystems

    • Forgejo Actions zielt nicht auf Kompatibilität, sondern auf Vertrautheit
    • Das meiste funktioniert, manches aber nicht
    • Workflow-weite permissions:-Blöcke werden stillschweigend ignoriert
    • actions/checkout@v6 hat Anfang 2026 den authentifizierten Checkout auf Non-GitHub-Runnern kaputtgemacht, daher bleibt es bei v5 festgesetzt
    • actions/upload-artifact@v4 benötigt einen von Forgejo gehosteten Fork
    • OIDC funktioniert, verwendet aber nicht GitHubs permissions: id-token: write, sondern einen anderen Workflow-Key namens enable-openid-connect: true
    • Wenn Workflows stark von GitHub-spezifischen Funktionen abhängen, wird die Migration nicht an einem Abend erledigt sein, sondern zu einem Projekt werden

  • Fehlendes Dependabot

    • Forgejo hat kein Dependabot
    • Renovate läuft im 3-Stunden-Takt auf demselben selbst gehosteten Runner
    • Es erfüllt dieselbe Rolle, erfordert aber mehr Einrichtung, und die Konfiguration hat einen Tag gedauert

  • 24/7-Vendor-Support

    • GitHub Enterprise bietet eine Telefonnummer und ein SLA
    • Forgejo bietet einen Issue-Tracker und einen Chatraum
    • Für einen Ein-Personen-Betrieb reicht das aus, für eine Organisation mit 200 Engineers möglicherweise nicht

Wann sich ein Umzug nicht lohnt

  • Wenn dem Team jeglicher Wille oder jede Fähigkeit fehlt, Infrastruktur zu betreiben, ist ein Umzug zu selbst gehostetem Forgejo eher nicht ratsam
    • Managed Forgejo wie Codey oder Codeberg für FOSS schließt den Abstand größtenteils, aber die Migrationskosten bleiben bestehen
  • Wenn stark in GitHub-spezifische Funktionen wie GitHub Apps Marketplace, Codespaces, Copilot Workspace oder Advanced Security investiert wurde, passt es nicht
    • Forgejo ist eine Forge, nicht developer-platform-as-a-service
  • Wenn die Contributor-Basis am GitHub-Social-Graph hängt, kann Auffindbarkeit wichtiger sein als Eigentümerschaft
    • Dann kann man dort bleiben, wo die Beitragenden sind, oder den Umzug trotz Reibung abschließen, danach die öffentlichen GitHub-Repositories archivieren und auf den neuen Ort verweisen und später erneut entscheiden
  • Wenn es keine belastbare operative Antwort für Runner gibt, ist ein Umzug schwierig
    • Das ist der Bereich, der am ernsthaftesten behandelt werden muss
    • Wer nicht bereit ist, sich mit KVM-Isolation, gVisor, nftables und wöchentlichen Rebuilds auseinanderzusetzen, sollte CI-Jobs lieber auf einem Managed-Runner-Host ausführen oder bei GitHub bleiben
  • Auch die niederländische Regierung hat nicht alles auf einmal umgezogen
    • code.overheid.nl ist eine Plattform mit Soft Launch, damit Ministerien Open-Source-Code teilen können, und kein vollständiger Austausch von allem, was sie nutzen
    • Auch die Konfiguration von code.jorijn.com folgt diesem Muster
      • Forgejo ist der kanonische Host und GitHub ist der Mirror; über den Mirror kann später erneut entschieden werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Hacker-News-Kommentare

  • Es wirkt, als würden alle GitHub verlassen und dabei den eigentlichen Geist von git vergessen.
    git war ursprünglich als dezentral gedacht; das Problem ist, dass GitHub sauberer, besser skalierbar und besser verwaltet war, sodass sich das gesamte Tooling rund um git auf GitHub zentralisiert hat.
    Trotzdem wäre es gut, weiterhin einen Mirror zu haben, der automatisch mit GitHub synchronisiert wird. Ich habe über Jahre hinweg erlebt, wie Projekte auf Self-Hosting oder Nischen-Hosting umgezogen sind, dann der GitHub-Mirror veraltet oder gelöscht wurde und das Projekt am Ende in der Zeit verschwand.
    git ist dezentral, und GitHub ist nur einer von vielen Orten, an denen man Code hosten kann; man kann auf mehrere Remotes pushen.

    • Nicht, dass ich den Geist von git vergessen hätte, aber ich erinnere mich auch daran, dass GitHub den ersten Copilot mit allen öffentlichen Repositories trainiert hat, ohne irgendwem Bescheid zu sagen.
      Deshalb committe ich dort keinen persönlichen Code mehr.
      An sozialen Funktionen wie Auffindbarkeit, Sternen oder von AI-Bots überschwemmten Issues habe ich kein Interesse. So wie es jetzt ist, reicht es mir.
      Und man sollte sich auch an „Open Source is not about You“ erinnern.
    • Stimmt, aber GitHub ist mehr als git.
      Der wichtigste Aspekt der Plattform, den alle vergessen, ist die soziale Komponente: dass sie ein dauerhaftes externes Repository geschaffen und die Zusammenarbeit zwischen Repositories sehr einfach gemacht hat.
    • Forgejo arbeitet intensiv daran, auch die Tools selbst zu dezentralisieren.
      Es nutzt offene Protokolle und Standards, um selbst gehostete Forges miteinander zu verbinden.
    • Nicht alle benutzen git, weil sie vom „Geist von git“ begeistert sind.
      Nur sehr wenige haben es im ursprünglich gedachten E-Mail-Patch-Modell verwendet, und die meisten anderen haben vermutlich auch kein Interesse, das zu lernen.
      Die Leute nutzen git im Grunde, weil GitHub es nutzt, oder wohlwollender gesagt: weil es gut funktioniert, wenn es mit einem zentralen Host wie GitHub gekoppelt ist.
      Attraktiv ist das Modell, lokal Code zu entwickeln und Issues sowie Patches in einem Webportal zu besprechen; der Anteil davon, den git selbst liefert, ist gering.
    • Stimme zu. Ein git-Repository zu verschieben ist leicht, aber die gesamte Oberfläche eines Projekts zu migrieren ist schwer.
      Issues, Releases, CI, Dokumentation, Security Advisories sowie Suche und Auffindbarkeit binden sich mit der Zeit alle an GitHub.
      Für ein Open-Source-Projekt scheint mir ein gutes Modell zu sein, Self-Hosting als Source of Truth zu nutzen und zugleich einen schreibgeschützten GitHub-Mirror zu pflegen, damit die Leute es tatsächlich finden können.

  • Was die Lage wirklich verändern würde, wäre ausgereifte Föderationsunterstützung.
    Deshalb spende ich an Forgejo und Codeberg und empfehle allen, mehr Zeit und Ressourcen beizutragen, damit das Forgejo-Team das richtig umsetzen kann.
    Ein weiterer guter Kandidat ist Radicle, das auf Git aufsetzt und vollständig dezentral ist.
    https://codeberg.org/forgejo-contrib/federation/src/branch/m...
    https://liberapay.com/forgejo
    https://donate.codeberg.org/
    https://radicle.dev/
    https://radicle.network/nodes/seed.radicle.dev

    • Föderation ist das schlechteste Dezentralisierungsmodell. Die Zusammenarbeit ist viel zu lose.

  • Ich habe mein git-Repository ebenfalls auf einen selbst gehosteten NUC umgezogen.
    Ich habe noch kein HTTP-Frontend angebunden, das ich mit der Welt teilen könnte, weil ich AI-Scrapern keine Inhalte liefern will und mich auch nicht damit beschäftigen will, sie zu blockieren.
    Es ist beschämend, dass Firmen, die von Open Source profitiert haben, die Branche so verschmutzt haben.

    • Ich nutze Gitea auf einem NUC, auf gebrauchter Hardware für etwa 50 Pfund.
      Es läuft jetzt seit drei Jahren. Wenn man es auf Zugriff nur aus dem LAN beschränkt und nicht ins Internet stellt, fühlt es sich robust und langlebig an.
    • Ich betreibe selbst gehostetes Forgejo auf einem Pi als GitHub-Mirror, aber vermutlich nicht mehr lange.
      Repositories werden ein paar Wochen lang sauber gespiegelt und bleiben dann stehen. Ich habe ein nicht ablaufendes PAT-Token eingetragen, aber es behauptet trotzdem, es sei abgelaufen, obwohl das Token anderswo getestet normal funktioniert.
      Manchmal steht nichts im Log, manchmal ist die Datenbank gesperrt. Forgejo ist das Einzige, was die Datenbank benutzt.
      Bisher konnte ich nicht unterscheiden, ob das ein Forgejo-Problem ist, ob die schlechte SD-Karten-I/O des Pi die Datenbanksperren verursacht oder ob Forgejo einfach nicht als Mirror taugt.
    • Open Source und die OSI sind eine Konstruktion, die von der Branche gepflanzt wurde. Man muss nur schauen, wer sie finanziert.
      Monopolistische Hyperscaler bekommen Gratisarbeit und bauen damit die Welt, die wir hassen: Tracking- und Überwachungsnetze, Smartphones, auf denen man nicht installieren kann, was man will, Geräteattestierung und eine Browser-Monokultur ohne Ad-Blocking.
      Google hat dafür gesorgt, dass Menschen BSD/MIT lieben, und man sieht, wohin das geführt hat.
      Einer der typischen Tricks ist „das gehört jetzt uns“. Wenn ein Vendor so etwas wie Elasticsearch oder Redis baut, nehmen Hyperscaler es als ihr eigenes Monopolprodukt, ziehen den gesamten Gewinn daraus und lassen den ursprünglichen Autor und die Firma verhungern.
      Ein anderer Trick ist „embrace, extend, extinguish“. Man nimmt Open-Source-Projekte wie KHTML oder Linux, baut eine eigene Version, wirft sie auf den Markt, drängt die Konkurrenz heraus, platziert das eigene Produkt mit wettbewerbswidrigen Mitteln vor aller Augen und sobald man Marktanteile hat, fügt man Tracking hinzu und nimmt Freiheiten weg.
      Open Source sollte durch „Freiheit für Menschen, Unternehmen müssen zahlen“ ersetzt werden. Wir brauchen quelloffenes Shareware mit Zähnen gegen Hyperscaler.
      Nicht einmal Richard Stallmans Lizenzen sind stark genug; ich halte CC BY-NC-SA für besser.
      „Reine“ Open Source war Corporate Welfare und ein Fehler. Wir haben den Riesen erlaubt, uns mit unserem eigenen Seil aufzuhängen.
    • Wenn jemand seine Arbeit freiwillig als Open Source bereitstellt und AI sie lesen und daraus Wissen ziehen kann, um später mehr Programmierern zu helfen, verstehe ich nicht, warum man dort eine Grenze ziehen sollte.
      Ich wünsche mir ausdrücklich, dass AI meinen Code liest.

  • Im Abschnitt „What I gave up“ des Artikels erwähnt der Autor seinen sozialen Graphen; mit GitSocial kann man den sozialen Graphen und die Kollaborationshistorie mitnehmen.
    Es ermöglicht forge-übergreifende Pull Requests zwischen beliebigen git-Hosts und funktioniert komplett ohne Abhängigkeiten von Dritten.

    • GitHub ist ein soziales Netzwerk, und git-Hosting ist nur eine kleine Funktion davon.
      Deshalb können sich solche Alternativen kaum durchsetzen.

  • Bei der Stelle „Der CTO hat sich öffentlich entschuldigt und gesagt, man müsse die Kapazität um das 30-Fache erhöhen, um AI-bedingte Last zu bewältigen“ hoffe ich, dass GitHub nicht beginnt, normale Nutzung zu bepreisen.
    Aber wenn ich sehe, wie manche Vibe-Coder Tausende Commits pro Tag erzeugen, werde ich zunehmend skeptisch.
    Es wäre wirklich schade, wenn man Code nicht mehr kostenlos teilen und gemeinsam daran arbeiten könnte.

    • Man könnte einfach nach einer bestimmten Anzahl die Anzahl der Commits pro Tag berechnen. Problem gelöst.
    • Ehrlich gesagt glaube ich, dass LLMs sogar dabei helfen könnten, dieses von ihnen selbst geschaffene Problem zu lösen.
      Erfahrene Leute erkennen in Sekunden, wenn ein Repository solche Probleme hat, also sollte ein abgestimmtes System ebenfalls möglich sein.
      Der schwierige Teil wäre, rechtliche Bedingungen zu formulieren, mit denen sich Vibe-Quoten durchsetzen lassen.
      Anthropic macht das bei Claude Code bereits so, und GitHub und GitLab dürften wohl Ähnliches tun. Der Preis wäre der Hass von Twitter-Entwicklern und einigen kleinen Subreddits, aber das wäre es wahrscheinlich wert.
      Andererseits erstaunt es mich oft, wenn ich in /r/vibecoding Leute sehe, die 200 Dollar pro Monat zahlen, um Hobbyprojekte oder etwas nahe an Spielzeug-Websites zu bauen.
      Ich habe schon dumme Ausgaben gemacht, wenn ich sie mir leisten konnte, aber das fühlt sich anders an.
      Vielleicht bezahlt man da Bedeutung und Sinn als Dienstleistung für 2400 Dollar im Jahr. Wenn man ungefähr in den Vierzigern erkennt, dass man weder reich noch berühmt wird, könnte das im Vergleich zu anderen Alternativen ein tragbarer Preis sein.

  • Ich habe auch von Tangled gehört, einem dezentralen Dienst, der wie Bluesky auf dem AT Protocol aufbaut.
    Dort gibt es tatsächlich nützliche Funktionen wie das Stapeln von Pull Requests, die GitHub so lange verschleppt hat, dass Firmen entstanden sind, die genau diese Funktion für GitHub anbieten.
    Mich würde interessieren, ob es jemand benutzt hat.
    https://tangled.org/

    • Ich habe kürzlich selbst gehostetes Knot eingerichtet, konnte aber noch nicht viele andere Funktionen ausprobieren.
      https://tangled.org/h14h.com/knot
      Insgesamt wirkt die Plattform recht vielversprechend. Die Art, wie AtProto persönliche Datenserver, Relays und AppView trennt, erscheint mir als sinnvoller Kompromiss.
      Man kann git-Repositories als headless, rein datenorientierten Server hosten, daher ist Self-Hosting fast schmerzfrei.
      Im Vergleich zu einer ActivityPub-Lösung wie Forgejo ist das angenehm, weil mir Datenkontrolle wichtig ist, ich mir aber die Mühe sparen will, eine komplette Web-App zu hosten und zu skalieren.
      Seit der Ersteinrichtung bestand die laufende Wartung nur darin, die knot-server-Version zu aktualisieren und neu auszurollen. Wenn tangled.org auf einer alten Version läuft, wird ein Warnbanner angezeigt.
      Ich würde Tangled gern in anderen Projekten stärker nutzen und mehr Funktionen testen, besonders die native Unterstützung für jj und gestapelte PRs.
    • Es ist definitiv Alpha-Software, aber für Open-Source-Zwecke benutzbar.
      Es gibt auch interessante Experimente wie tack, um maßgeschneiderte CI anzubinden.
      Wenn ATProto einmal private Daten unterstützt, könnte es irgendwann auch private Repositories unterstützen, aber das dürfte noch dauern.
      https://tangled.org/mitchellh.com/tack
    • Das Projekt hat gerade eine große VC-Finanzierung bekommen.
      Von einem Geschäftsmodell war bisher keine Rede, deshalb bin ich wirklich gespannt, was daraus wird.
    • Ich würde es wegen der jj-Kompatibilität und der sauberen CI-Implementierung gern nutzen, aber ich brauche private Repositories, daher passt es für mich noch nicht.
    • Für meinen Geschmack ist es zu stark dezentralisiert.
      Ich würde stattdessen eher radicle.xyz verwenden.

  • Fossil ist ebenfalls einen Blick wert.
    Es bündelt den vollständigen Repository-Zustand in einer einzigen Datei, einschließlich Code-Historie, Wiki, Tickets und Forum, und dieser Zustand wird repliziert.
    Wenn man den Hosting-Anbieter wechseln muss, verliert man bei Fossil deshalb keine Daten.
    https://fossil-scm.org/

    • Ich mag Fossil. Irgendetwas an seinem eigenwilligen Workflow passt zu meiner Denkweise.
      Aber die Netzwerkeffekte sind das Problem. Ich kann mein Team nicht zu Fossil bringen.
      Das Team muss Code mit anderen Leuten und anderen Abteilungen teilen, und alle, praktisch mehr als 99 %, verwenden git.
      Fossil aufzuzwingen fühlt sich eher schädlich an, und das ist ein Dilemma.
      Das ist wie vieles andere im Tech-Bereich: wenn man Mitentwickler zu funktionalen Idiomen bewegen oder Unveränderlichkeit erzwingen will.
      Es wirkt, als müsste etwas Großes wie ein Facebook- oder Google-Projekt die Community zwangsweise in Bewegung setzen.
    • Ich habe Fossil vor einigen Jahren angeschaut und fand es wirklich großartig. Dass alles integriert ist, ist hervorragend.
      Philosophisch gefällt mir Fossil aber nicht. Es gibt keine Möglichkeit, die Historie aufzuräumen; alles wird unverändert bewahrt.
      Wenn man genau das will, ist es super, aber in meinem git-Workflow probiere ich gern Dinge aus und räume dann vor dem Pushen meine Commits auf und strukturiere sie.

  • Die Leute rufen ständig nach Dezentralisierung.
    Aber in der Realität werden die meisten Systeme am Ende doch zentralisiert.
    Vielleicht suchen Menschen, wenn sie Dezentralisierung fordern, in Wahrheit nur ein neues Zentrum, in dem sie selbst die neuen Pioniere sein können.
    Wenn sie das Gefühl haben, nach den bestehenden Regeln nicht gewinnen zu können, scheint Dezentralisierung als Vorwand zu dienen, das Spielbrett umzustoßen.

    • Es hätte gereicht, nur die erste Zeile direkt unter dem Titel zu lesen: „I moved my code from GitHub to a self-hosted Forgejo“
    • Dezentralisierung bedeutet, dass es kein einzelnes Zentrum gibt.
      Die Leute wollen das, weil diese eine zentrale Verwaltung aus verschiedenen Gründen nicht ausreicht.
      Zwischen „die Leute rufen danach“ und „sie wollen es tatsächlich“ gibt es keinen Widerspruch.
    • Die Leute wollen die Vorteile von Dezentralisierung, aber sie wollen nicht den Preis dafür zahlen.
      Noch schlimmer ist, dass zentralisierte Systeme die meiste Zeit hervorragend funktionieren und der Schmerz nur kurz, aber sehr heftig auftritt, etwa bei einer Übernahme oder einer plötzlichen Preiserhöhung.
      Dezentralisierung tut immer ein bisschen weh, schenkt dafür aber große Freude in den seltenen Momenten, in denen die zentralisierte Alternative zusammenbricht.
    • Man sagt als Entwickler eben Dezentralisierung.
      Im Alltag würde man eher von einem Boykott sprechen. Niemand sagt: „Snacks sind zu stark bei Nestlé zentralisiert, wir müssen Snacks dezentralisieren.“
    • Ich denke, die eigentliche Antwort auf das, was die Leute brauchen, ist nicht Dezentralisierung, sondern Portabilität.

  • Ich bin gerade zu Tangled am Umziehen, das auf dem AT Protocol basiert und deshalb denselben Account wie Bluesky usw. verwendet.
    Bisher gefällt es mir ziemlich gut.
    https://vale.rocks/micros/20260511-0440

  • Ich bin vor einem Jahr in meinem Homelab auf selbst gehostetes Gitea umgestiegen und habe den öffentlichen Zugriff blockiert.
    Es gibt auch kein HTTPS, Registrierungen sind deaktiviert und die Repositories sind nicht öffentlich.
    Ich überlege, eine öffentliche Instanz mit HTTPS zu betreiben und die Angriffsfläche dabei minimal zu halten, und wäre besonders an Empfehlungen zu Gitea/Forgejo interessiert.

    • Ich habe das so gemacht. Auf einem fly.io-Proxy laufen nginx und fail2ban, die dann in mein Tailnet weiterleiten, wo Caddy auf die eigentliche Instanz auflöst.
      Wichtig ist, lokale Registrierungen zu deaktivieren. Ich verwende in meinem Fall authentik als IdP, das nur aus dem Tailnet erreichbar ist. Alternativ kann man erst seinen eigenen Account anlegen und dann die Registrierung abschalten.
      Über robots.txt habe ich bestimmte Bereiche wie einzelne gerenderte git-Commit-Ansichten blockiert. Sonst geraten Scraper in eine Endlosschleife.
      Ich habe auch den Zugriff auf die Forgejo-Paket-Registry strikt gesperrt, weil ich private Pakete habe und die Granularität der Berechtigungen dort noch nicht meinem Bedarf entspricht.
      Ich beobachte das weiter, aber bisher gab es keine größeren Probleme. Mehr Details stehen auf docs.eblu.me, und wenn du willst, kann ich auch direkt auf den Infrastruktur-Code verlinken.
    • Ich habe das früher gemacht und betreibe auch jetzt noch eine interne/LAN-Forgejo-Instanz, aber derzeit keine öffentliche.
      Damals hatte ich eine öffentliche schreibgeschützte Instanz aufgesetzt, die meine interne Instanz spiegelte, und genau eine Reverse-Proxy-Verbindung vom internen zum öffentlichen System eingerichtet, damit die öffentliche Seite die git-Daten ziehen konnte.
      Danach lief es im Wesentlichen von selbst, und wenn ich intern in Forgejo etwas geändert habe, wurde die öffentliche Seite ebenfalls aktualisiert.
      Issues, CI usw. konnten vollständig privat im LAN bleiben.
    • Ich habe Forgejo eingeführt, weil mir die politischen Auseinandersetzungen rund um Sicherheitsprobleme nicht gefallen haben, die Forgejo bei Gitea gemeldet hatte und die Gitea ignoriert haben soll.
      Deshalb frage ich mich, warum du weiterhin Gitea benutzt. Ich überlege inzwischen, ob ich Gitea statt Forgejo noch einmal ausprobieren sollte.