Git ist von Haus aus dezentral — aber die Art, wie wir damit zusammenarbeiten, ist es längst nicht. Pull Requests, Issues, Reviews: All das lebt auf zentralen Plattformen, die das Protokoll selbst gar nicht braucht. Radicle holt diese Kollaborationsschicht zurück ins dezentrale Modell, und genau deshalb ziehe ich gerade nicht nur mein Lab, sondern alle meine Repos dorthin um — und das sind einige, überwiegend die Quellen meiner Container-Images.
Was Radicle anders macht
Radicle ist eine peer-to-peer-Git-Forge. Es gibt keinen zentralen Server, der die Wahrheit hält; stattdessen wird ein Repository — inklusive seiner Patches und Issues — als signierte git-Objekte zwischen den Knoten eines P2P-Netzes repliziert. Die Forge-Daten sind damit Teil des Repos selbst, nicht der Metadaten-Datenbank eines Anbieters.
Für die Open-Source-Welt ist das mehr als eine technische Spielerei. Es bedeutet:
- Keine Plattform-Abhängigkeit. Ein Repo überlebt das Verschwinden jedes einzelnen Hosts, solange irgendein Knoten es repliziert. Kein „die Plattform hat das Projekt gelöscht“ mehr.
- Souveräne Identität. Beiträge sind kryptografisch signiert; die Identität gehört dem Autor, nicht einem Plattform-Account.
- Zensurresistenz. Es gibt keinen zentralen Punkt, an dem ein Projekt abgeschaltet oder ausgesperrt werden könnte.
Das ist für freie Software ein zutiefst passendes Modell — die Werkzeuge der Zusammenarbeit sind genauso frei und verteilt wie der Code, den sie verwalten.
Wie sich das anfühlt
Im Alltag ist der Umstieg überraschend vertraut. Ein Patch ist Radicles Pull Request, und er entsteht mit nichts als git:
git checkout -b my-change
git commit -am "fix: beschreibe die Änderung"
git push rad HEAD:refs/patches # öffnet den Patch
rad sync --announce --replicas 1 # verteilt ihn ins Netz
Issues ersetzen bei mir die klassische TODO.md — der Backlog des Labs lebt jetzt in rad issue list. Mein Repo ist öffentlich über einen eigenen Seed-Knoten (seed.this-is-fine.io) erreichbar, und die Branches main und next sind geschützt: Es wird nie direkt committet, alles läuft über Patches.
Schön ist auch, wie nahtlos sich das in den Rest des Labs fügt: Mein GitOps-Setup deployt weiterhin aus main, und ZeroClaw schlägt seine Änderungen als Radicle-Patches vor — Mensch wie Agent nutzen denselben, dezentralen Weg.
Den vollständigen Workflow — die Patch- und Issue-Konventionen, die Seed-/Sync-Details und die ZeroClaw-Integration — pflege ich konsequenterweise direkt im Repo selbst. Wer es im Detail nachlesen möchte, findet das unter docs/RADICLE.md im Radicle-Repo — passenderweise selbst über Radicle ausgeliefert.
SourceHut bleibt großartig
Der Umzug ist ausdrücklich kein Frust-Wechsel. SourceHut ist und bleibt ein wunderbarer, kompromisslos schlanker Laden — werbefrei, JavaScript-arm, herrlich fokussiert. Bis heute hostet SourceHut den kanonischen Mirror meines Repos und vor allem die Build-Pipeline, die meine Images baut und signiert.
Denn hier liegt das eine fehlende Puzzleteil: Radicle ist eine Forge, aber kein CI-System. Die Patches und Issues sind dezentral — was noch fehlt, ist ein Build-Workflow, der ebenso gut zum P2P-Modell passt. Genau daran arbeite ich gerade: eine selbst-gehostete CI-Umgebung, die auf Radicle-Events reagiert und meine Pipeline aus SourceHut zu sich holt. Solange die nicht steht, bleibt SourceHut der pragmatische CI-Unterbau — die beiden schließen sich nicht aus.
Fazit
Radicle fühlt sich an wie das, was Git eigentlich schon immer hätte sein sollen: Zusammenarbeit ohne Mittelsmann. Der Umzug ist im Gange, der CI-Teil noch eine offene Baustelle — aber die Richtung steht fest. Eine Forge, die niemandem gehört, passt einfach besser zu einem Lab, das auch sonst niemandem gehört außer mir.