Discussing the GitLab migration from 6 years ago.

For those unaware, Composr moved its development from GitHub to GitLab in 2019. The announcement post cited the following reasons for this:
 

• GitHub was acquired by Microsoft ~1 year before Composr's migration.
• GitHub isn't open-source as a platform.
• GitLab is (or was) a "really excellent platform."
• GitLab allows (or allowed) free private repositories, which was useful to ocProducts.

I'll cut to the chase, understanding this would take some planning by Chris/Patrick/etc and isn't something that would be done on a whim: I'd like to start a discussion about whether GitLab is still the best home for Composr and whether moving back to GitHub might make sense.
 

Reflecting on GitLab's Selling Points

First of all, we all know that ocProducts is (at least on paper) no longer the steward of Composr, so GitLab allowing private repositories when everything the Composr Foundation does is public is no longer a benefit to Composr. We can strike point 4 out on that basis. Even if we didn't, GitHub also offers free private repos now.

Regarding point 3, it's true that GitLab showed promise in the days of Microsoft's GitHub acquisition. One source of promise was GitLab's greater feature set, including things like CI without having to hook into third-party services (GitHub now has an equivalent offering with Actions), more social components like wikis and project boards (which GitHub now has), and an enterprise-friendly incident tracking system (which Composr isn't utilizing). Another tangible benefit was that it's open-source, which practically translated into being self-hostable without having to pay for an Enterprise subscription, although Composr never self-hosted a GitLab instance.

While GitHub's basically caught up with (or surpassed) GitLab's former feature advantages, GitLab itself has arguably stagnated, especially after their IPO four years ago. GitLab's been having financial troubles as a company for the past few years. GitLab has become known as an option for large enterprises to self-host with lots of in-house automation and integrations, but on the consumer (and open-source) side, it has not replaced GitHub as a platform.

One particular pain point for me with GitLab's usability is search. GitLab's search is simply not very good. I've been hacking on my website again over the last month, and when I go to search for a function name or the like on GitLab, I often either don't get results or find myself having to scroll through pages and pages of translation files to find a relevant result. Instead, I often find myself returning to the six-year-old archive of Composr's GitHub page and searching there instead, then checking the specific file out either locally or on GitLab to see if it's been changed since then. GitLab's official answer is to use a third-party search plugin (such as Elasticsearch) with your self-hosted instance, or to pay for their "Advanced Search" feature, neither of which is possible with the free hosted GitLab website.
 

Community Interest

Both Chris and Patrick have been calling for greater community developer involvement for the better part of a decade at this point. GitHub has over 100 million active users, while GitLab has less than a third of that at around 30 million registered (not active) users as of their last public report. The ecosystem of GitHub is objectively larger than that of GitLab, and GitHub thus offers greater discoverability and less friction for potential contributors.

Don't get me wrong– I understand why Composr went to GitLab. After Microsoft bought GitHub, I created all of my own code repos on GitLab first and mirrored them to GitHub. However, the only contributions I've ever gotten to my personal projects have been on GitHub, where I've manually applied the commits from forks back to GitLab myself. I work for a company that directly competes with Microsoft; we still use GitHub as a cornerstone of our infrastructure. It's totally natural that someone making a niche, smaller, FLOSS project like Composr would want to support a niche, smaller, FLOSS project like GitLab; however, at its current size, Composr's certainly not buoying GitLab. On the contrary, Composr at this moment needs every potential contributor it can get, and it needs to minimize friction with any part of the development process.

Git is git, so the repo can always be moved again in the future if Microsoft really does destroy GitHub, but for the time being, GitHub as a platform is simply a fact of the industry. With all of this in mind, any thoughts from the developers on whether moving the canonical repo back to GitHub (or at the very least, setting up an active mirror instead of just an archive) would be in the cards, if only for the sake of helping Composr's survival?

While I can understand your points, which are great points, migrating to GitHub at this time is not practical for two big reasons:

* I am looking for a job. I need to maintain my commit and development history with Composr to show employers. I don't believe there is an easy way to migrate the entire repository and commit history to GitHub (please correct me if I'm wrong; I'm not familiar with this).

* I live in an apartment complex which apparently shares the same IP address (I think). I have troubles all the time with GitHub's rate limits as a result, and thus I frequently get locked out of the site.

Additionally…

* GitHub is still run by big tech. GitLab isn't much better given they are also run by a company, but at least they are (more) open-source and FOSS friendly than GitHub. Honestly, neither platform is good for FOSS anymore by my standards. But migrating to a git platform other than GitHub or GitLab will come at the cost of even more community support, since all other git source sites are not as popular.

* GitHub trains your code on AI (Copilot) without your consent, and often without acknowledging your license or giving back as royalties, donations, or contributions. They've improved a bit on this; Copilot now prompts you to cite the source of code it recommends. But AFAIK this is optional, and they still train without consent.

* I don't have the time right now to spend migrating not just Composr's repositories but also the repos of all my clients over to GitHub. That will take many hours which I must instead spend on job searching and earning money to pay my bills.
 

---

I am *very* reluctant for these reasons to migrate back to GitHub (at least for the time being). But I will keep my mind open to any thoughts from the community.

Most likely, this will be left to a community vote as per our new voting system in the Constitution.

---

Thanks for your reply, Patrick. A couple of points you brought up:

PDStig said

* I am looking for a job. I need to maintain my commit and development history with Composr to show employers. I don't believe there is an easy way to migrate the entire repository and commit history to GitHub (please correct me if I'm wrong; I'm not familiar with this).

From “Post #8477”, 13th May 2025

This is an important concern, but should actually be extremely easy. The commit history is part of the git repo, and isn't tied to the hosting provider. If I `git clone [email protected]:composr-foundation/composr.git`, then all of your development history (all commits, etc) is on my local machine. If I `git remote set-url origin [email protected]:some-org/composr.git` and `git push`, then all of your development history would be on GitHub. The friction to migrate the entire repo between Git providers is extremely low from a technical standpoint.

The friction when migrating Git hosts normally has to do with non-repo metadata such as issues, wikis, PR/MR comments, etc. Composr has a separate issue tracking system anyway, Composr's docs are in the git repo (not in a GitLab wiki), and Composr doesn't seem to be actively using GitLab MRs since the last one was 2 years ago and there are only <40 total.

PDStig said

* GitHub is still run by big tech. GitLab isn't much better given they are also run by a company, but at least they are (more) open-source and FOSS friendly than GitHub. Honestly, neither platform is good for FOSS anymore by my standards. But migrating to a git platform other than GitHub or GitLab will come at the cost of even more community support, since all other git source sites are not as popular.

From “Post #8477”, 13th May 2025

Again, based on news and forum posts from you & Chris, it simply doesn't appear from my outside perspective that Composr is in a state strong enough to place ideological concerns like "big tech" over its own survival. Again, I completely get where you're coming from philosophically. But you're correct that migrating from GitLab to something even more obscure (like, say, a self-hosted Gitea instance) would cost even more community support. It's the same factor that would potentially boost community support going back to GitHub.

The AI training isn't necessarily ideal, but I view it in the same vein. And Microsoft can already clone your public GitLab repo anyway if they want to train their AI on Composr's source code.

---

The rate limit issue would be a valid concern. Personally, I can only recall hitting GitHub rate limits when doing things unauthenticated (i.e. a fresh system where I hadn't yet added my GitHub account key, or a command that used https:// instead of git@). I'm not sure exactly what situations you've seen that happen in.

I can understand that an actual migration would take planning and time (that you don't currently have). Do you think a live mirror from GitLab to GitHub would be something more feasible in the short-to-medium term? I've got it set up for all of my GitLab repos, and it takes just a few minutes. In the GitLab repo, you just have to go to Settings -> Repository, expand the `Mirroring repositories` section, click `Add new`, and then fill in the details of the corresponding GitHub repo. On the GitHub side, you just need to create the repo, and generate an access token with metadata Read and code Read/Write access (this serves as the password you use when putting your details into GitLab). GitLab will then send the full history of all branches of the git repo over to GitHub and sync it whenever there are changes in GitLab.

For example, my bookmark manager Nilamark lives in a GitLab repo but is mirrored to a GitHub repo. I'm even able to accept pull requests on GitHub, like this one, by going into my GitLab repo, doing a `git remote add-url fork [email protected]:user/fork` and `git fetch fork`, then cherry-picking (or otherwise merging) the PR's commit into my main branch before pushing it to GitLab (this keeps authorship information intact, so the GitHub PR still shows as merged and the author's name is still on the commit).

This is an important concern, but should actually be extremely easy...

That seems reasonable. I knew logs were within git, but I didn't know if there was an easy way to transfer them between sites. My concern is the attribution / author; I have different usernames on GitLab versus GitHub (and I believe different e-mail addresses as well). So I'm not sure if that will work.

Correct (for now). Chris intended for us to start using GitLab issues at some point. But there is no easy way to use them with our sponsorship system. So that's why we're still using Mantis. For CI/CD, I used to have tests auto-trigger for commits, but the local repos kept getting corrupt, so I deemed it too high maintenance to continue (since we have to run the full test suites between each release manually anyway). 

 

While I understand where you're coming from, the whole premise of v11 was supposed to be centered around being anti big-tech, or rather an alternative to it. I'll send off a message to Chris and see if he can give his thoughts because I think he would have a bigger say in this than me (since he made the switch to GitLab). 

 

I've been getting them (on the site) regardless of whether I'm logged in or not. I'm not sure about git commands since I have no active repositories on GitHub right now.

 

That's actually a good idea. I hadn't thought of it until you mentioned it. I think it would. I'll have to run it with Chris first, and we may still want a community vote on it.

PDStig said

My concern is the attribution / author; I have different usernames on GitLab versus GitHub (and I believe different e-mail addresses as well). So I'm not sure if that will work.

From “Post #8480”, 14th May 2025

I've got separate email addresses for my day job and my side business, which I use when making commits on my work and personal computers, respectively. How GitHub does it is by associating any validated email address on your account with your GitHub username. So e.g. if you currently use a different email address for your GitLab account than your GitHub account (and assuming that one's what you currently have configured for use when you make commits in git), you'd just want to add that email address to your GitHub account (can be secondary/not receive notifications) if you want commits from that email address to show up on your GitHub profile.

The name would always show up (as with the email address) when browsing commits manually, regardless of accounts on either website, of course.

Another nice thing about a live mirror would be that it'd let everyone involved see how using GitHub could work in terms of accounts, integrations, etc. without having to really commit. Switching the primary from GitLab to GitHub later (if it's ever wanted) would be as simple as switching the direction of the mirroring and changing where you push to.

Very well argued/explained points Jacob.

When I moved Composr to GitLab I was trying to make the project reflect its ideals in what it associates with. But there are a few problems with that:

1. Boycotts generally do not work in general, and have not worked in this case.
2. As argued the project is at this point losing out on a lot of functionality GitHub has since added.
3. At a base level Git itself is Open Source, so being principled over a UI layer is a bit extreme.
4. You could make a strong argument we should just focus on applying principles to what we do, rather than in all our associations. Trying to be perfect leads to endless distraction, splintering, and general kookiness. Think FSF vs OSI. Think any number of people in history who the world just moved on from. If the FOSS community wants to displace GitHub, let it make a better GitHub by competing in a way Microsoft won't, for example; eventually FOSS will catch up, but that's someone else's chosen battle not ours.

Setting up an automatic mirror sounds like a great idea for the short term; if that can be done purely from GitHub's end it wouldn't even need a vote to get it going. If someone were to volunteer to do the work to make the mirror the main repo - update all the links on the homesite etc, and make sure the right people can get access to the new home, I'd likely vote for it.

GitHub should (as far as I understand) automatically associate commits with GitHub accounts by the email addresses attached to those commits. It trusts that the commits have legitimate metadata, which is completely reasonable as if they don't there'd be a much bigger problem.
EDIT: Ah. Jacob covered it.

I can't speak for IP address blocking other than having an option to use a VPN with multiple locations if needed.

It shall be done, then.

Chris granted me access to the old GitHub. I will mirror the GitLab repos over (or at least attempt to) when I can. I have some other priorities at the moment, however, so it may be a little bit of time. I will make a soft announcement when it has been done.

Additionally, I will add the ability to log in to composr.app with GitHub.

IDEA TEMPORARILY REJECTED; TECHNICAL ISSUES

I've attempted multiple times to get git mirroring to work, but GitHub repeatedly throws permission denied errors despite following the instructions correctly for setting up a mirror repository on GitLab and adding a deploy key on GitHub with write access.

In my current extremely-limited capacity for Composr development, I do not have the time or resources to debug this further. Therefore, for now, the idea has been rejected, and Composr will not be mirrored to GitHub.

When I have the economic capacity to spend time on this, I will investigate further. 

Good news, I was able to work out the issue with help from Chris Graham. We now have the GitHub repository mirrored.

https://github.com/composr-ecosystem/composr