From GitLab to GitHub
Why the quick and flexible cat jumped above the lazy fox after 10 good years
Coders.Care and our company Cybercraft GmbH have counted on the support of Gitlab as a platform for our open source repositories for almost 10 years now. However, we would like to briefly describe why we will switch to GitHub in the future and what this means for you as users and sponsors of our extensions.
Estimated time to read: 4 minutes
GitLab. Our first choice is the fox!
The details made the difference
Ever since the versioning system of the TYPO3 core was switched from SVN to Git, a corresponding platform for managing the repositories used for this purpose has been part of the basic toolbox of all TYPO3 developers. From the very beginning, it was not the number of repositories or users worldwide that was the decisive factor in our choice of such a DevOps platform, but above all the availability of certain services.
Particularly for the provision of CI/CD functions such as pipelines or actions, but also for other functions, GitLab was therefore always our first choice, despite the lower degree of distribution, because these were also available without booking a paid package. This was especially important for our open source projects because we have relatively low revenues for them, which are just enough to cover the development costs.
GitHub was therefore out of the question for us for a long time, even though a large part of the TYPO3 developer community relies on this platform.
Crowdfunding and early access
Why we need private repositories
Another important point was and is the availability of private repositories with access only for selected users with appropriate permissions. This way we are realizing our early access program for sponsors who have supported a project as part of a crowdfunding campaign. Sponsors thus receive a monetary benefit in return for their support, while the extensions are only available to all other users after the later public release.
Here, too, GitLab was our first choice for a long time, because such repositories were only available in the paid packages at GitHub.
The cat catches up
Private repositories on GitHub
After the acquisition of GitHub by Microsoft, there was a first important change in 2019 with the introduction of private repositories for open source projects. However, the number of collaborators was initially limited to a maximum of 3, and the total team size was thus limited to 4.
In the next step, GitHub caught up with GitLab a year later and also lifted this limitation for the entry level, now called GitHub Free. For us, however, this was not a reason to switch, because we were very satisfied with the performance of the GitLab platform until then and GitHub had only achieved the tie.
The fox shoots itself in the foot
Restrictions for open source projects on GitLab
While GitLab and GitHub were still on par in terms of features relevant to us until 2022, the latest change in the rules for open source projects on GitLab made the service unaffordable for us. The rule is that while open source projects can have an unlimited number of team members for free, there are no more private repositories because they are not considered open source and are thus reserved for paid packages.
If we had still been willing to reasonably pay for packages as such, it still wouldn't do us any good because the fees are not charged per package, but per user. For example, a project like Gridelements would incur an annual fee of over $20,000, far exceeding the total budget for further development. By the way, we would have had to pay the same fee for self-hosting as well, which is why we ultimately have to switch to GitHub to continue offering the early access service.
The Consequences
What does this mean for our users and sponsors?
We are already in the process of moving all relevant projects from GitLab to GitHub. This will still require adjustments to the CI/CD pipelines that run on GitHub via CI/CD actions, for example, to run code sniffers and other tests.
Once this process is complete, for public projects we will accept users on request at any time, as we have in the past. For private early access repositories, previous sponsors of current versions 9, 10, and 11 will be contacted and asked to send us their GitHub accounts so we can add them to the team.
Those who manage their projects via Composer or the TYPO3 extension repository don't need to do anything else, because we will adjust the URLs of the repositories on Packagist and in the TER accordingly. However, if you have manually entered paths to early access repositories, e.g. in the composer.json file, you will have to change them accordingly by September 2022 at the latest, because we cannot offer redirects via GitLab.
TL;DR - Conclusion
Cat beats fox!
Private repositories with a larger number of users are no longer affordable on GitLab for open source projects. We are therefore switching to GitHub and adjusting all entries in TER and on Packagist accordingly. Those who have manually included previous GitLab repositoriy URLs must migrate them to GitHub by September 2022. Sponsors with early access to current extension versions will get it back as soon as they send us a GitHub account.
Latest Tweets
Recent Tweets
Testimonials
Coders.Care is the logical progression of the cooperation between providers of TYPO3 extensions and their users. Especially the point of communication during the preparation of a project will be optimized thereby. The developers can focus on their strenghts, while Coders.Care deals with questions, answers and management. In the consequence there will be clear statements about maintenance and further development of TYPO3 extensions, so the trust in TYPO3 and the projects implemented with it will be strengthened. As a TYPO3 agency we can only benefit of such a service.
© Copyright 2024 Cybercraft GmbH