Ich habe kurz nach dem 11. Mai 2026 von den Änderungen erfahren, die bei Gitlab als Organisation geplant sind. Diese Informationen lassen mir keine andere Wahl, als gänzlich auf das Produkt zu verzichten.

Ich verließ bereits vor einiger Zeit Github und Gitlab als Plattformen. Nun ist die Zeit gekommen, diesen Schritt auch in meinem privaten, self-hosted Labor zu tun.

Ich sah mich daher nach Alternativen um. Der erste Schritt in diesem Prozess war die Identifikation der benötigten Features einer alternativen Lösung - Schließlich wollte ich ein anderes Tool, aber falls möglich unter Beibehaltung des gewohnten Arbeitsablaufes...

Hier also eine Liste meiner Anforderungen:

• Markdown-Support
• PlantUML-Support
• Import von Gitlab (einschließlich geschlossener Issues, Tags und Kommentare)
• Attachments an Issues

Bei meiner Recherche stieß ich nicht nur auf die üblichen Verdächtigen wie forgejo und gitea, sondern auch auf das interessante Konzept der verteilten, auf Git basierenden Issue-Tracker. Beispiele dafür sind etwa git-pad oder git-native-issue oder auch gitbug.

Für solche Systeme formulierte ich noch weitere Anforderungen:

• Issues müssen auf allen Branches sichtbar sein
• Merge-Konflikte müssen minimal sein wenn man versucht, Kommentare unterschiedlicher Committer an dem gleichen Issue zusammenzuführen.

Mein Auswahlprozess startete dann zunächst mit etwas Literaturrecherche. Dabei flog OneDev sofort aus dem Kreis der möglichen Alternativen, weil sdchon auf der Startseite so Marketing-Bullshit prangte wie "Built-in AI for DevOps Intelligence" und "Workspaces for Vibe Coding". Gogs teilte dieses Schicksal, denn als ich auf der Startseite Features anklickte, landete ich irgendwo mitten in der Dokumentation zum Thema Authentifizierung. Auch forgejo schied beinahe sofort aus dem Kreis der Kandidaten aus: Dafür gibt es keinen PlantUML-Support und wird ihn auch nie geben, da man sich dort auf die Unterstützung von Mermaid festgelegt hat. Radicle hatte ich mir bereits früher einmal angesehen, aber damals festgestellt, dass ich den Use-Case zwar prinzipiell verstehe und mir auch vorstellen kann, dass es Leute gibt, die diesen Use-Case tatsächlich haben und lösen müssen - allerdings gehöre ich nicht dazu. Die Beschäftigung mit Radicle war aber der eigentliche Auslöser dafür, tiefer in die Welt der verteilten Issue-Tracker einzutauchen - hat mir also tatsächlich etwas gebracht!

Was die verteilten Systeme angeht, habe ich mich auf die zwei Alternativen git-bug (wegen seines Terminal User Interface) und git-native-issue (wegen der sehr durchdachten Architektur speziell in Bezug auf Konfliktresolution in Issues) festgelegt.

Natürlich würden diese Systeme einen eigenen dedizierten Git-Server benötigen, der bei den anderen Lösungen ja automatisch zur Verfügung gestellt wird.

Bei der Recherche lernte ich auch wieder viele Dinge über Git - wie etwa die Möglichkeit, Spezifische Dateien vorm Überschreiben während eines Merge zu schützen oder die Arbeit mit git notes.

Interessant war die Information, dass mein Plugin, das ich eigentlich für Gitlab entwickelt hatte und die PlantUML-Unterstützung wesentlich erweitert ungeändert auch in Gitea funktioniert - nachdem ich es zu meinem Docker-Zoo hinzugefügt hatte, war es dazu lediglich nötig, die Integration von PlantUML in Gitea ein wenig anzupassen.