Warum ich einen Teil meiner Projekte zu Codeberg verschoben habe, GitHub aber noch nicht loswerde

Seit einiger Zeit verschiebe ich einen Teil meiner Open-Source-Projekte zu Codeberg. Nicht, weil ich GitHub von heute auf morgen abschaffen will und auch nicht, weil ich glaube, dass ein anderer Git-Host plötzlich alle Probleme löst. Der eigentliche Grund ist viel banaler: Ich möchte nicht, dass mein kompletter Entwicklungsworkflow davon abhängt, dass eine einzige proprietäre Plattform der unausgesprochene Standard für fast alles ist.

GitHub ist nicht das eigentliche Problem

GitHub funktioniert für sehr viele Dinge gut. Genau das ist gleichzeitig Teil des Problems. Deployments, Preview-Umgebungen, Review-Dienste, Webhooks, Bots und unzählige Entwicklerwerkzeuge gehen häufig einfach davon aus, dass ein Repository auf GitHub liegt. Selbst wenn Git selbst dezentral ist, wird die Infrastruktur darum herum dadurch erstaunlich zentral.

Mir geht es dabei ausdrücklich nicht um Copilot. Den mag ich ohnehin nicht besonders. Viel interessanter ist für mich, wie viele unabhängige Dienste GitHub als Integrationspunkt voraussetzen. Ein Repository kann technisch problemlos woanders liegen und trotzdem landet man für irgendeinen Teil des Workflows wieder bei GitHub.

Warum Codeberg?

Codeberg passt deutlich besser zu dem, was ich von einem Zuhause für freie Software erwarte. Die Plattform wird von einem gemeinnützigen Verein getragen, ist gemeinschaftsorientiert und basiert auf Forgejo. Forgejo wiederum ist freie Software und kann selbst gehostet werden. Damit ist nicht nur das Repository offen, sondern auch ein großer Teil der Infrastruktur, auf der es liegt.

Das heißt nicht, dass Codeberg magisch oder grenzenlos ist. Die Plattform wird mit deutlich anderen Ressourcen betrieben als GitHub. Bei CI gibt es beispielsweise Woodpecker sowie Forgejo Actions mit eigenen Runnern; gehostete Actions sind nur eingeschränkt verfügbar. Auch automatische Pull-Mirrors von anderen Code-Hosts sind aus Ressourcengründen nicht einfach als Dauerlösung vorgesehen. Das ist für mich aber eher ein ehrlicher Trade-off als ein Ausschlusskriterium.

Und dann kommt die Realität

Die schwierigste Stelle bei einem Wechsel ist nicht Git. Clone, Push, Branches und Pull Requests sind nicht das Problem. Es ist das Ökosystem. Manche Dienste unterstützen Forgejo oder Codeberg direkt, andere lassen sich über Webhooks anbinden, und wieder andere zeigen beim Login oder beim Import schlicht nur den GitHub-Knopf.

Deshalb behalte ich für einzelne Projekte weiterhin GitHub-Mirrors. In diesen Fällen ist Codeberg der Ort, an dem ich das Projekt eigentlich haben möchte, während GitHub als Kompatibilitätsschicht für Werkzeuge dient, die noch keine andere Forge verstehen. Schön ist das nicht, aber es ist praktischer als so zu tun, als könnte ich das bestehende Entwicklerökosystem ignorieren.

Mein aktueller Kompromiss

Mein Ziel ist deshalb nicht „Codeberg statt GitHub um jeden Preis“. Ich möchte Abhängigkeiten reduzieren, ohne mir aus Prinzip den eigenen Workflow kaputtzumachen. Freie Projekte können dort liegen, wo eine freie und gemeinschaftlich betriebene Forge sinnvoll ist. GitHub bleibt dort im Spiel, wo Integrationen es faktisch noch verlangen.

Langfristig fände ich es gesünder, wenn Entwicklerwerkzeuge weniger selbstverständlich davon ausgingen, dass Open Source an eine bestimmte Firma gebunden sein muss. Git ist dezentral. Unsere Werkzeuge darum herum könnten es ruhig ein bisschen mehr sein.