We moved one of the most-starred projects on GitLab to GitHub

TL;DR

• Baserow was one of the most-starred open-source projects on GitLab, but in November 2025 we moved our primary development to GitHub.
• The main reason wasn’t missing features, but discoverability and the size of the developer ecosystem.
• The migration required rebuilding our CI/CD pipeline and moving issues and merge requests to GitHub.
• Since the move, we’ve seen faster community growth and more contributions.
• Both platforms have strengths, but for open-source projects the community size can make a big difference.

For several years, Baserow was one of the top 10 most-starred open-source projects on GitLab.

When we started building Baserow, GitLab felt like the natural choice. It aligned well with our values, GitLab itself is open source, and our team already had experience with it, so it became our main platform for issues, merge requests, CI pipelines, and releases.

In November 2025, we moved our primary development to GitHub. The GitLab repository still exists, but now is a read-only mirror.

Many discussions about GitHub vs GitLab focus on features, but in our case the deciding factor was visibility and community reach.

GitHub is where much of modern software development happens today. Most developers already have GitHub accounts, their tooling is built around GitHub, and their workflows assume GitHub. We felt that not being there as our main platform could limit how easily developers discover Baserow or contribute to the project.

The scale difference between the platforms is huge:

• The most starred project on GitLab (GitLab itself) has around 7k stars
• The most starred project on GitHub (freeCodeCamp) has 438k+ stars

We noticed this ourselves after the move. Baserow received more than 1,000 stars on GitHub in about three months. On GitLab, reaching the same number usually took us well over a year.

Even our community raised this topic and suggested the move in our forum. That discussion continued for almost two years and eventually led us to make the switch.

If you’d like to see the original discussion, we shared an earlier version of this post on Reddit.

How we moved Baserow from GitLab to GitHub

In November 2025, we moved Baserow’s primary development from GitLab to GitHub. The migration itself took a lot more work than just flipping a switch.

The first step was moving our existing GitHub mirror repository. For a long time, it lived under my personal account as bram2w/baserow, because it originally existed only as a mirror of the GitLab project. As part of the migration, we moved it to baserow/baserow so it could become the project’s official home.

We also had to rebuild our CI pipeline from scratch. This ended up being by far the biggest part of the migration work. GitHub Actions works differently enough that there wasn’t a simple one-to-one migration path. We had to rethink and rebuild it in a way that fit GitHub’s actions model. That took quite a bit of time, but it also gave us the opportunity to clean things up along the way.

Before and after the migration:

• Before: https://gitlab.com/baserow/baserow/-/blob/develop/.gitlab-ci.yml?ref_type=heads
• After: https://github.com/baserow/baserow/blob/develop/.github/workflows/ci.yml

For issues and open merge requests, we used a slightly modified version of node-gitlab-2-github to handle the migration. Before doing that on the real repository, we first tested the whole process on an empty repository to make sure everything behaved as expected. That gave us more confidence before making the final move.

Once everything was ready, we were able to officially switch the project over. On GitLab, we updated the repository wherever possible to clearly explain that it had become a read-only mirror and that primary development now happens on GitHub.

After the migration was complete, we still had to figure out how to collaborate on GitHub. On GitLab, we had labels like “In progress” and “Ready for review”. After a brainstorm session with the development team we decided to adopt the native features from GitHub.

What we like about GitHub so far

Several things stood out after moving development to GitHub.

More community contributions

We’ve already seen more community contributions since the move, although some of them look AI-generated and don’t include much explanation.

GitHub Actions

GitHub Actions are flexible. Several developers on the team mentioned this quickly. The workers tend to have better specs than what we previously used, and pipelines run noticeably faster.

The ecosystem

We also noticed that third-party integrations usually support GitHub first. Tools like GitLens work well with GitHub, and we have access to tools like Copilot during reviews.

Speed

GitHub generally feels faster. Pages load quickly, navigation is responsive, and large repositories are easy to browse. Developers often jump between many issues and pull requests, and that speed actually makes a difference in day-to-day work.

Things we don’t like about GitHub

Code review workflow

The code review experience on GitHub can feel clunky:

• You can’t complete a review (approve, request changes, etc.) without switching back to the main code view of the pull request
• It’s harder to start conversations based on comments in a pull request
• It’s not always obvious who is currently reviewing a pull request
• If you follow a strict code review process, GitHub doesn’t give a clear overview of the review progress

UI organization

GitHub is fast, but the interface can feel disorganized at times:

• Comments in pull requests can be collapsed together, which makes searching for a specific comment difficult
• Reversed commit order compared to GitLab

Some GitLab features we miss

There are also several workflow details we appreciated in GitLab:

• Naming a branch with an issue number automatically links the branch to the issue
• A clear indicator showing how far a branch is behind the target branch
• “Merge when CI passes”
• Easier conversation threads during code reviews

If we were starting today, we would probably begin on GitHub. At the same time, after working with GitLab for many years, we clearly see that both platforms still have things that could be improved, and there are areas where they could learn from each other.

If you’re comparing GitLab vs GitHub for open source projects, our experience shows that community reach can sometimes matter more than platform functionality.

We hope this post helps if you’re deciding where to start an open-source project, or if you’re considering a similar move.

Today, community reach is often a stronger factor than functionality or values. That’s something we realized along the way.

⭐️ If you’re curious, you can find Baserow on GitHub.