Bram Wiepjes, CEO and co-founder of Baserow, published this on 6 March 2026. For several years Baserow was one of the ten most-starred open-source projects on GitLab. In November 2025 primary development moved to github.com/baserow/baserow. The GitLab project is still there, as a read-only mirror.
The GitLab → GitHub playbook is the general import. Baserow’s write-up is a community decision, a CI rewrite, and a test import on an empty repo.
Why GitHub
GitLab matched the team. GitLab is open source, and they already knew it. Issues, merge requests, CI, and releases all lived there.
Bram says the deciding factor was visibility and the size of the developer ecosystem. Most developers already have GitHub accounts, and a lot of tooling assumes GitHub. He compares star counts as a scale picture: GitLab itself, the most-starred project on GitLab, had around 7,000 stars, and freeCodeCamp on GitHub had 438,000 or more. Those are his figures from the post.
After the move, Baserow picked up more than 1,000 GitHub stars in about three months. On GitLab, the same thousand usually took well over a year. That is also his count.
The community had already asked. A forum thread opened on 26 January 2023. The first post argues that primary development on GitLab was hiding the project, and it mentions a mirror under Bram’s personal account. Bram says that thread ran for almost two years and ended in the switch.
How they moved it
A GitHub mirror had lived for a long time as bram2w/baserow, because it was only a mirror. They moved that repo to the baserow organization so it could be the official home.
CI was the long job. GitHub Actions did not map one-to-one onto their GitLab pipelines, so they rebuilt them and cleaned them up while they were in there. He links the old .gitlab-ci.yml and the new .github/workflows/ci.yml.
Issues and open merge requests went through a slightly modified node-gitlab-2-github. That project describes itself as a migrator for issues, milestones, and similar GitLab data. They ran the whole import against an empty repository before they touched the real one.
Then they switched. GitLab’s pages, where they could edit them, say the project is a read-only mirror and that development happens on GitHub.
Review habits changed in the same breath. GitLab labels such as “In progress” and “Ready for review” were replaced, after a team discussion, with GitHub’s own review actions.
What they say they gained
More community contributions showed up. Some of them look AI-generated, and some arrive with little explanation. He reports both.
Actions workers have better specs than the machines they used before, and pipelines feel faster. Third-party tools tend to support GitHub first. He names GitLens, and Copilot during review. Pages load quickly, and a large repo is easier to click through when you jump between many issues and pull requests.
What they miss
Review on GitHub feels clumsy to them. You cannot finish a review (approve, request changes) without going back to the main code view. Starting a conversation from a pull-request comment is harder. It is unclear who is reviewing. A strict review process has no single progress view.
Comments collapse together, which makes a specific comment hard to find. Commit order is the reverse of GitLab.
They also miss three GitLab habits. A branch named with an issue number linked itself to that issue. The UI showed how far a branch sat behind its target. “Merge when CI passes” was a button they used. Review threads were easier to follow.
What I would copy
If the project is open source and contributors already live on GitHub, Bram’s result is the star pace and the extra contributions, including the noisy ones. He says that if they started today they would start on GitHub.
Move the mirror into the org before you call it the official repo. bram2w/baserow was the wrong front door.
Rebuild CI as its own project. He says that was most of the work, and there was no mechanical translation.
Import issues into an empty repo first. Their confidence came from that dry run, using a modified node-gitlab-2-github.
Leave GitLab up as a read-only mirror and say so on the old project, or people will keep opening merge requests in the wrong place.