+49 (0)5583 2829973 info(at)coders(dot)care
Shadow

Warum wir nach zehn guten Jahren den alten Fuchs gegen die flexible Katze getauscht haben

Coders.Care und unsere Firma Cybercraft GmbH haben seit nun fast 10 Jahren auf die Unterstützung von Gitlab als Plattform für unsere Open-Source-Repositories zählen können. Warum wir in Zukunft dennoch zu GitHub wechseln werden und was das für Euch als Nutzer und Sponsoren unserer Extensions bedeutet, wollen wir hier kurz beschreiben.

Geschätzte Lesezeit: 4 Minuten

 

GitLab. Unsere erste Wahl ist der Fuchs!

Die Details machten den Unterschied

Seit der Umstellung des Versionierungssystems des TYPO3-Kerns von SVN auf Git gehört eine entsprechende Plattform zum Verwalten der dafür verwendeten Repositories zum grundlegenden Werkzeugkasten aller TYPO3-Entwickler. Von Anfang an waren für uns dabei nicht die Anzahl der Repositories oder der Nutzer weltweit ausschlaggebend für die Wahl unserer DevOps-Plattform, sondern vor allem die Verfügbarkeit bestimmter Dienste.

Insbesondere bei der Bereitstellung von CI/CD-Funktionen wie Pipelines oder Actions aber auch bei anderen Funktionen war GitLab trotz des niedrigeren Verbreitungsgrads daher für uns immer erste Wahl, weil diese auch ohne die Buchung eines kostenpflichtigen Pakets verfügbar waren. Dies war für unsere Open-Source-Projekte insbesondere deswegen wichtig, weil wir dafür nur relativ geringe Einnahmen haben, die gerade ausreichen, um die Entwicklungkosten zu decken.

GitHub kam deswegen lange Zeit für uns nicht in Frage, obwohl ein großer Teil der TYPO3-Entwickler auf diese Plattform setzt.

Crowdfunding und Early-Access

Warum wir private Repositories brauchen

Ein weiterer wichtiger Punkt war und ist die Verfügbarkeit von privaten Repositories mit Zugang nur für ausgewählte Nutzer mit entsprechenden Zugriffsrechten. Wir realisieren damit unser Early-Access-Programm für Sponsoren, die im Rahmen einer Crowdfunding-Kampagne ein Projekt unterstützt haben. Sponsoren erhalten damit einen geldwerten Vorteil im Gegenzug für ihre Unterstützung, während die Extensions für alle anderen Nutzer erst nach dem späteren Public-Release verfügbar sind.

Auch hier war GitLab lange Zeit erste Wahl für uns, weil solche Repositories bei GitHub nur in den bezahlten Paketen verfügbar waren.

Die Katze holt auf

Private Repositories auf GitHub

Nach der Übernahme von GitHub durch Microsoft gab es 2019 eine erste wichtige Änderung mit der Einführung von privaten Repositories für Open-Source-Projekte. Allerdings war die Anzahl der Collaborators wie die Teammitglieder auf GitHub heißen zunächst auf maximal 3 und die gesamte Teamgröße damit auf 4 beschränkt.

Im nächsten Schritt zog GitHub ein Jahr später mit GitLab gleich und hob auch diese Begrenzung für das nun GitHub Free genannte kostenlose Einsteigerlevel auf. Für uns war das dennoch kein Grund zum Wechseln, weil wir mit den Leistungen der GitLab-Plattform bis dahin sehr zufrieden waren und GitHub lediglich den Gleichstand erzielt hatte.

Der Fuchs schießt sich ins Knie

Beschränkungen für Open-Source-Projekte auf GitLab

Waren GitLab und GitHub bzgl. der für uns relevanten Features bis 2022 noch gleich auf, führte die letzte Änderung der Regeln für Open-Source-Projekte auf GitLab dazu, dass der Service für uns unbezahlbar wird. Die Regel lautet: Open-Source-Projekte können zwar kostenlos eine unbegrenze Anzahl an Team-Mitgliedern haben, es gibt aber keine privaten Repositories mehr, weil diese nicht als Open-Source betrachtet werden und damit den bezahlten Pakten vorbehalten sind.

Wären wir noch bereit gewesen, Pakete als solche angemessen zu bezahlen, so würde uns das dennoch nichts nützen, weil die Gebühren nicht pro Paket, sondern pro User abgerechnet werden. Für ein Projekt wie Gridelements würde beispielsweise eine Jahresgebühr von über 20.000 USD anfallen, was das gesamte Entwicklungsbudget bei weitem übersteigt. Auch beim Self-Hosting hätten wir übrigens dieselbe Gebühr zahlen müssen, weswegen wir letztlich auf GitHub wechseln müssen, um weiterhin den Early-Access-Service bieten zu können.

Die Folgen

Was bedeutet das für unsere Nutzer und Sponsoren?

Wir sind bereits jetzt dabei, sämtliche relevanten Projekte von GitLab zu GitHub zu verschieben. Dabei wird es noch Anpassungen an den CI/CD-Pipelines geben müssen, die bei GitHub über CI/CD-Actions laufen, um z. B. Code-Sniffer und andere Tests zu fahren.

Sobald dieser Prozess abgeschlossen ist, werden wir bei öffentlichen Projekten Nutzer wie bisher auf Anfrage jederzeit annehmen. Bei privaten Early-Access-Repositories werden die bisherigen Sponsoren der aktuellen Versionen 9, 10 und 11 angeschrieben und gebeten, uns ihre GitHub-Accounts zu schicken, damit wir sie ins Team aufnehmen können.

Wer seine Projekte über Composer oder das TYPO3-Extension-Repository verwaltet, braucht nichts weiter zu tun, weil wir die URLs der Repositories auf Packagist und im TER entsprechend anpassen werden. Wer allerdings manuell Pfade zu Early-Access-Repositories z. B. in der composer.json Datei eingetragen hat, muss diese spätestens bis September 2022 entsprechend nachziehen, weil wir über GitLab keine Redirects anbieten können.

TL;DR - Fazit

Katze schlägt Fuchs!

Private Repositories mit einer größeren Anzahl an Nutzern sind auf GitLab für Open-Source-Projekte nicht mehr bezahlbar. Wir stellen daher auf GitHub um und passen alle Einträge im TER und auf Packagist entsprechend an. Wer bisherige GitLab-Repository-URLs manuell eingebunden hat, muss diese bis September 2022 auf GitHub umstellen. Sponsoren mit Early-Access-Zugriff auf aktuelle Extension-Versionen erhalten diesen wieder, sobald sie uns einen GitHub-Account geschickt haben.

Coders.Care