FOSS Git Forges
FOSS Git Forges
Contents
If you have spent any time at all in the Linux, BSD, or wider open-source world, you will have noticed a quiet but steady exodus taking place. Developers, maintainers, and entire distribution projects have been packing their bags and moving away from proprietary code hosting towards something rather more in keeping with the spirit of the software they build: git forges that are themselves free and open source. This is not a fad. It is a considered, principled shift, and it is reshaping how the community collaborates, tests, and ships software.
This article takes a friendly, practical look at the leading FOSS git forges available today, what genuinely sets them apart, how you go about migrating a project onto one, and how to pick the right one for your circumstances, whether you are a solo hobbyist tinkering with a window manager theme or a corporate team running critical infrastructure.
What Makes a Git Forge Genuinely FOSS?
Before comparing platforms, it is worth pausing on what "FOSS git forge" actually means, because the term gets used rather loosely. A git forge is simply a service built around Git that adds a web interface, issue tracking, pull or merge requests, wikis, and usually some form of continuous integration on top of the raw version control system. What makes a forge FOSS is twofold: the underlying software that powers it must be released under a free and open-source licence, and ideally the organisation running the public instance should operate in a manner consistent with those same values, transparency, community governance, and no vendor lock-in chief among them.
This distinction matters more than it might first appear. A forge can be self-hosted using free software while still being run by a company with closed commercial add-ons layered on top, and a hosted instance can call itself community-driven while quietly steering decisions in a direction that favours a single commercial backer. Readers who care about digital sovereignty, GDPR compliance, or simply not waking up one day to find a beloved feature has vanished behind a paywall will want to look closely at both the code licence and the governance model before committing a project's history to any given home.
There is a formative case study that illustrates precisely why this distinction matters, and it concerns the very software many of today's leading forges are built on. Gitea began life in 2016 as a lightweight, community-driven fork of an earlier project called Gogs, prized for being fast, easy to self-host, and refreshingly free of bloat. In October 2022, two of its maintainers founded a for-profit company, Gitea Limited, with plans to offer hosting services and, in time, specialised closed-source variants alongside the original MIT-licensed codebase. This came without the wider community being consulted beforehand, and an open letter asking the project owners to reconsider went unanswered. In response, Codeberg, one of the largest public instances running Gitea at the time, forked the project entirely, creating Forgejo as a community-governed alternative with its long-term custody placed in the hands of a non-profit association rather than a commercial entity. Both Gitea and Forgejo remain very much alive and actively developed today, but the split is a useful reminder that "open source" and "community controlled" are not always the same promise, and that governance deserves just as much scrutiny as the licence file.
There is a second, quieter dimension to "genuinely FOSS" worth flagging too: what happens to your data, and to the community around it, if the operator of a public instance ever runs into financial difficulty or changes direction. A forge built on free software can, in principle, always be self-hosted elsewhere using the same codebase, which is precisely the safety net that a fully proprietary platform cannot offer. That portability is not merely theoretical; it is the exact mechanism that allowed the Codeberg and Forgejo community to walk away cleanly when Gitea's governance shifted, taking their code, their history, and their workflows with them rather than being trapped.
With that context in mind, let us look at where the community has actually landed.
Meet the Major Players
Codeberg, running on Forgejo, is very much the standard-bearer for the ethically-minded FOSS crowd. It is operated by Codeberg e.V., a registered non-profit association based in Berlin that was founded in 2018, and it takes a firm stance on privacy: no tracking, no third-party cookies, no selling of user data, and everything run on infrastructure the association controls itself. Membership of the association is entirely optional, and the platform is funded through donations and member fees rather than by monetising user data or gating features behind a paywall. Alongside straightforward Git hosting, Codeberg offers Codeberg Pages for static site hosting, integration with the Weblate localisation platform, and continuous integration through both Woodpecker CI and the newer built-in Forgejo Actions, which is designed to be broadly compatible with GitHub Actions workflow syntax. For anyone whose priority is a values-aligned, EU-hosted, thoroughly FOSS home for their project, with an interface that will feel instantly familiar to anyone coming from GitHub, Codeberg is very hard to beat.
GitLab, by contrast, is best understood as a full DevSecOps platform rather than a simple code host. GitLab.com is operated by GitLab Inc., a US-headquartered company, and while the underlying Community Edition remains open source, the hosted service and several advanced capabilities sit behind commercial tiers. What you get in return is genuinely comprehensive: source code management, issue boards and epics for project planning, deeply integrated CI/CD pipelines, and built-in security scanning covering static application security testing, dependency scanning, container image scanning, and infrastructure-as-code checks for tools like Terraform. GitLab has also been investing heavily in AI-assisted development through its Duo Agent Platform, which now spans code suggestions, code review, and agentic workflows across the software lifecycle, with administrators able to choose which model providers power those features and to exclude sensitive files from being used as context. For teams that want project management, CI/CD, and security tooling under one roof without stitching together several separate services, and who are comfortable with a partly open-core model, GitLab remains the heavyweight option.
Gitea occupies the middle ground: lightweight, fast, and famously easy to self-host, right down to running comfortably on something as modest as a Raspberry Pi. The core project is released under the MIT licence and continues to be developed by hundreds of community contributors alongside Gitea Limited, the company that now holds the trademark and sells hosted Gitea Cloud and Gitea Enterprise offerings on top of the free base. A common misconception is that Gitea's built-in CI/CD, Gitea Actions, remains a bare-bones afterthought; in reality it has matured considerably since its introduction and is now considered stable enough for production use, running the workflows for Gitea's own repositories, supporting YAML syntax compatible with GitHub Actions, and giving access to a large existing library of reusable actions. Gitea also supports more than twenty types of package registry, from Cargo and npm to Maven and PyPI, and works across Linux, Windows, macOS, and even FreeBSD. For personal projects, small teams, or anyone who simply wants a forge that installs in minutes and stays out of the way, Gitea is an excellent fit.
It is also worth saying a word about scale and community size, since this often matters more in practice than any feature comparison chart. Codeberg's community has grown steadily since its 2018 founding and now counts well over a thousand paying association members alongside a much larger population of everyday users, run on a comparatively modest operating budget and, until recently, a very small paid staff, which is a genuinely remarkable achievement for infrastructure serving thousands of active projects. GitLab, by contrast, operates at a completely different scale as a publicly known DevSecOps vendor with enterprise customers, dedicated support channels, and a continuous release cadence, currently on a monthly cycle, that has in the last year pushed hard into agentic AI tooling for code review and workflow orchestration. Gitea sits somewhere between the two in terms of visible community size, but its self-hosted install base is enormous precisely because so many small teams and individuals run their own private instance rather than using a shared public one, which makes raw user counts for Gitea rather harder to pin down than for Codeberg or GitLab.
Beyond these three, several smaller but well-regarded FOSS hosts deserve a mention. SourceHut, styled sr.ht and created by developer Drew DeVault, takes a deliberately minimalist and unapologetically old-school approach, built around the email and patch-based contribution workflow that Git itself was originally designed around, using tools such as git send-email rather than web-based pull requests. Its entire codebase is open source under AGPL and MIT licences, it includes its own CI service in the form of builds.sr.ht, and it appeals strongly to developers who value a lightweight, JavaScript-free, standards-based way of working. GNU Savannah, run by the Free Software Foundation, exists specifically to host official GNU and wider free software projects rather than general-purpose repositories, making it less of an everyday option but an important piece of FOSS infrastructure in its own right. NotABug.org, built on the Gogs codebase, offers a smaller, privacy-focused alternative for those who prefer an even lighter footprint.
Making the Move: Migrating From GitHub
Moving a project off GitHub tends to follow a broadly similar pattern regardless of which FOSS forge you choose, though the details differ slightly between platforms.
The general steps look like this. First, generate a GitHub personal access token scoped to the repository you intend to move, since most forges use this to authenticate the import on your behalf. Second, use the destination forge's built-in "Import from GitHub" tool, which Codeberg, Gitea, and GitLab all provide in one form or another, with GitLab additionally offering bulk import options via its command-line tooling for organisations migrating many repositories at once. Third, once the import has completed and you have verified that code, issues, wiki pages, and releases have all come across intact, update your local clones with git remote set-url origin <new-url> so that future pushes go to the right place. Finally, it is good practice to archive the original GitHub repository with a clear "moved to" notice and a link to the new home, left in place for a reasonable period, commonly around six months, so that anyone arriving via an old link or search result can find you.
There are, inevitably, a few things that do not transfer automatically and need deliberate attention. GitHub Actions workflows will need to be rewritten rather than simply copied, since each forge uses its own execution engine even where the syntax is designed to be familiar: Codeberg and other Forgejo instances use Forgejo Actions or Woodpecker CI, GitLab uses its own GitLab CI/CD pipeline syntax, and Gitea uses Gitea Actions. Certain GitHub-specific features also have no direct equivalent elsewhere and will need a rethink, most notably GitHub Discussions, the newer Projects v2 boards, and GitHub Sponsors.
A useful checklist for a single-repository move runs as follows. Before you begin, create your GitHub personal access token with repository scope, let contributors know a migration is coming so nobody is caught out mid-review, and take a full backup with git clone --mirror <github-url> as a safety net regardless of how smooth you expect the process to be. During the move itself, run the import, carefully verify that code, issues, wiki content, and releases have all arrived correctly, convert your CI workflows to the new platform's syntax, and update the README with the new canonical URL. Afterwards, archive the old GitHub repository, update any external documentation or package manager listings that still point at the old address, re-add collaborators with the appropriate permissions on the new forge, and give the CI pipeline a proper test run before declaring the migration complete.
It is worth noting that this is not only a decision made by individual hobbyist projects; entire distribution ecosystems have been going through exactly this process. Fedora, one of the most established Linux distributions and a project long associated with Red Hat, spent much of 2025 and 2026 working through precisely this kind of migration at considerable scale. Fedora's own git forge, Pagure, had served the project faithfully for many years, but the Fedora Council ultimately decided to consolidate source code management, issue tracking, and project hosting onto a single Forgejo-based platform, now known as Fedora Forge, running on Fedora's own infrastructure. The stated aims were to fix long-standing workflow pain points, reduce the burden of maintaining bespoke, homegrown tooling, and bring package source repositories, previously hosted separately on src.fedoraproject.org, into the same modern, actively maintained forge. The final cutover took place around Flock to Fedora 2026, after which pagure.io became a static, read-only historical archive, with the Pagure service itself decommissioned at the end of July 2026 and the project's own maintainers openly acknowledging that a small number of stragglers, including at least one repository everybody in the project quietly depends on, needed extra attention before the switch could be considered complete. It is a genuinely instructive real-world example: even a mature, well-resourced distribution project finds forge migration to be a multi-year undertaking involving careful planning, a published migration guide, generous transition windows, and no small amount of patience, all lessons well worth bearing in mind before you assume your own move will be a quick afternoon's work.
Choosing the Forge That Fits You
With the landscape and the mechanics of migration covered, the practical question remains: which forge should you actually choose?
If your priority is FOSS ethics combined with a genuinely familiar, GitHub-like experience and hosting firmly rooted in the EU under GDPR, Codeberg is the natural starting point, particularly for individual maintainers and community-run distribution projects who want their home to reflect their values without a steep learning curve.
If you need the maximum breadth of features, integrated project management, mature CI/CD, and enterprise-grade security tooling all under one roof, and you are comfortable with an open-core commercial model sitting alongside the free tiers, GitLab is difficult to match, especially for larger teams or organisations with compliance obligations.
If simplicity, speed, and ease of self-hosting matter most to you, whether because you want full control over your infrastructure or because you are working with genuinely limited hardware, Gitea remains an excellent, low-friction choice, and its CI/CD tooling has matured to the point where it is a realistic option for production workloads rather than a token feature.
And if you are drawn to a more radically minimalist, standards-first way of working, or your project is closely tied to the GNU project specifically, SourceHut and GNU Savannah each offer something genuinely distinct that the larger platforms do not attempt to replicate.
A few practical questions can help narrow things down further. Ask yourself who else needs to use the forge day to day: a solo maintainer or a small volunteer team will feel very differently about administrative overhead than a corporate department with a dedicated platform engineer. Consider where your data needs to legally reside, since organisations bound by GDPR or similar regional data protection regimes may find Codeberg's EU-based, non-profit hosting considerably simpler to justify to a compliance team than a service headquartered elsewhere. Think about your existing CI/CD investment too; if you already have a substantial library of GitHub Actions workflows, Gitea and Forgejo's close syntax compatibility will smooth the transition considerably more than rewriting everything for GitLab's own pipeline format, though GitLab's integrated security scanning may well be worth that extra effort for organisations with formal compliance requirements. Finally, do not underestimate the pull of community: a forge that already hosts the wider ecosystem your project belongs to, whether that is other BSD tools, independent distributions, or GNU software, brings genuine discoverability and cross-pollination benefits that a feature comparison alone will never capture.
There is, refreshingly, no single wrong answer here. The health of the FOSS git forge ecosystem lies precisely in this diversity: multiple credible, actively maintained, values-aligned options exist, and Git's own distributed nature means that moving between them, should your needs or your community's needs change, is far less painful than it would be with a proprietary, tightly coupled platform.
A Brief Word to Close
The FOSS git forge landscape has never been healthier, and that is genuinely good news for anyone who cares about open, sovereign, community-governed infrastructure for open-source development. Whichever platform you land on, Codeberg, GitLab, Gitea, or one of the smaller specialists, you are choosing to keep your project's development history in the hands of tools built on the same principles as the software you are writing. That is worth celebrating, and worth taking a little care over.
Disclaimer: All product names, logos, and trademarks referenced in this article, including Codeberg, Forgejo, GitLab, Gitea, GitHub, SourceHut, GNU Savannah, NotABug, Fedora, and Pagure, are the property of their respective owners, and are used here for identification and informational purposes only. The Distrowrite Project has made every reasonable effort to ensure the accuracy of the information presented, drawing solely on official sources, but details of fast-moving software projects can change after publication, and readers are encouraged to verify current specifics directly with the relevant official sources before making decisions. This article is published for educational purposes only, does not endorse or promote any activity involving malware, viruses, unauthorised access, or any other conduct that could compromise the integrity, security, or availability of networks, devices, or infrastructure, and readers are expected to use any tools or platforms discussed here responsibly and in accordance with all applicable laws and terms of service.
References
▓▓▓▓▓▓
Comments
Post a Comment
Hello and welcome to The Distrowrite Project! We appreciate your engagement and value diverse perspectives. Our community thrives on respectful and constructive discussions. Please ensure your comments align with our guidelines: no hate speech, personal attacks, or spam. Let us foster a positive environment where everyone feels comfortable to share their thoughts and insights. Kindly direct any complaints and suggestions for any software/hardware directly, clearly and politely to the respective developer(s). Thank you for being a part of our community!