Theo Explores GitHub Alternatives and the Cost of Leaving

GitHub has been home for my code and community for years, but outages and reports of unexpected merge behavior have made me consider alternatives. GitLab, Bitbucket, Gitea, Forgejo and Codeberg all offer different answers. The question is not simply where a Git repository can live, but what else we lose or gain when we move.

First, establish the requirements: a remote Git repository, a pull-request workflow, and continuous integration and delivery. I also value community features such as profiles, contribution histories and stars. Reliability, open source and self-hosting are attractive, as are tools designed for agent-driven development.

GitLab is the obvious alternative many people mention. I have wanted an open, self-hostable alternative to GitHub, but I find GitLab’s user experience frustrating. These are my observations and reactions to particular examples, not a controlled comparison of every installation or release.

A demonstration shows repository information disappearing during back navigation and loading in layers. When a site makes me question whether the content is complete, I spend time refreshing instead of working. GitHub has its own loading frustrations; this example did not give me confidence that GitLab would improve the experience.

Jason Cox’s examples highlight a README placed far down the project page and release links competing for attention with many equally weighted numbers. For someone trying to understand a project or download a release, the most useful information should be easy to find.

Finding an old commit also looks awkward in the demonstrated interface if you do not remember its author or message. Slowly scrolling through history is not a satisfying substitute for filtering by date. A local clone can provide other ways to search, but the hosted browsing experience still matters.

On the release page, the displayed milestone completion percentage is prominent while the release date is much farther down. I want to understand when a release appeared and what changed between versions. The example makes those questions harder than I expect them to be.

A commit page exposes its parent, but the demonstrated view does not give me an obvious way to move forward to a subsequent commit. The interface also hesitates when opening a list of branches containing a commit. Small navigation problems accumulate when this is a tool I use all day.

I inspect the size of GitLab’s repository and see millions of Git objects and a very large codebase. My point is that an open license does not make a complex, mature application easy for any individual to redesign. A line count includes different kinds of files and is not a direct measure of quality or maintainability.

GitLab does offer self-hosting and enterprise control, and I have heard favorable things about its CI, though I did not independently test that claim here. My overall preference remains GitHub’s user experience. Teams may weigh control, cost, support and reliability differently from me.

I think about developer products in generations. In my telling, Sublime Text, Atom, VS Code and Cursor developed a family of extensible editor experiences, while agent-oriented interfaces such as the Codex app and my own T3 Code represent a different interaction model. This is a way to organize my preferences, not a strict history of editors.

By analogy, GitHub, GitLab and Bitbucket largely compete in an established generation of hosted source-control products. A later generation might reorganize the workflow around agents rather than reproduce the same interface. That future product category was still taking shape when I recorded the video.

GitLab’s enterprise appeal includes hosting control and commercial terms, even though I do not enjoy using its interface. Bitbucket, meanwhile, prominently markets its integration with Jira and its cost comparison against GitHub. That may appeal to an organization already invested in Atlassian tools.

I am skeptical of choosing a developer platform primarily to save a small monthly amount per engineer. Atlassian’s displayed comparison also depends on the GitHub security and support add-ons it includes. Compare the features, usage and support your own organization needs rather than treating a marketing multiplier as universal.

The Bitbucket page also mentions security features, support, service levels and build-minute plans. Those details can matter, particularly for teams already using Jira, but bundled minutes and extra usage should be checked against the actual plan and workload. My dismissive reaction is a preference, not a universal recommendation.

Gitea is another self-hosted forge. I point to its free MIT-licensed edition and separate commercial offering, and notes that a governance dispute contributed to the creation of Forgejo. The existence of commercial offerings does not mean that the open-source edition itself ceased to be open source.

Forgejo began as a fork after a for-profit company took over the Gitea project. Forgejo describes itself as free software developed under the umbrella of the nonprofit Codeberg e.V.; its project governance is independent of Codeberg’s. Codeberg.org is a hosted service using Forgejo, while Forgejo can also be self-hosted.

I created an account to try Codeberg and expected to dislike the experience. Initial loading and a CAPTCHA were rough, but the Forgejo repository itself looked actively maintained. Its project was substantially smaller than the GitLab repository I had just inspected, though size alone does not establish performance or security.

The release tab immediately gives me useful information, including the date and a route to the commits associated with a release. The interface has themes, and I like having an RSS feed for releases. It is not the prettiest presentation, but it puts important developer tasks within reach.

The README is still farther down than I would like. Issues and pull requests look familiar, images can be embedded, and the review interface is usable. Switching the diff layout triggers a full-page reload in my test, so the experience is not free of rough edges.

Forgejo’s own comparison emphasizes free-software governance, testing and development using Forgejo Actions. Some security comparisons mentioned there were not independently verified in the video. I was impressed enough to donate $1,200 and say I would contribute $400 a month going forward.

I want to try moving some projects and testing my CI setup. Forgejo Actions supports workflows similar to GitHub Actions, but compatibility is not necessarily perfect; individual actions, runners, secrets and integrations need testing. I use external CI services and would need to verify that they work with a new host.

Codeberg’s status page showed a hosted Actions problem during my visit, and I appreciated the public status updates. Self-hosting Forgejo is another option, but it transfers operational responsibility to you. The snapshot I viewed does not establish that either provider always has better uptime than the other.

I initially misunderstood a bring-your-own-machine option: in this context it concerns Actions runners, not hosting a whole Codeberg instance while remaining on its site. That distinction matters when planning a migration. Forgejo remains a credible option for someone who wants an open, self-hostable forge.

I briefly mention SourceHut, CodeCommit, Google Code, SourceForge and Phabricator, but do not conduct comparable hands-on evaluations of all of them. My more immediate recommendation after this exploration is to try Forgejo or Codeberg and decide whether their workflow fits.

Pierre had paused development of its full forge while working on underlying components. One is code.storage, a Git infrastructure service designed for programmatic access and high-throughput workflows. I see it as a potential building block for a future platform, not a complete replacement for issues, pull requests and community features.

Pierre reported storing nine million repositories in a 30-day period and a peak of 15,000 repositories per minute for three hours. I know the team and trust their report, but it is a company-reported workload, not a like-for-like independent reliability comparison with GitHub’s full product.

GitHub’s growth figures include much more than raw repository storage, such as pull requests and collaboration services. A storage backend can solve only part of that system. I suspect the services around Git are a major scaling challenge, but the exact causes of a particular outage require incident evidence.

I demonstrate GitHub’s interactive CLI for creating a repository from existing local code. During my attempt, an option-delete keyboard sequence repeatedly crashes the prompt, and the workflow asks many questions with loading pauses. This is a frustrating observed interaction, not proof that every CLI invocation or environment behaves the same way.

A code.storage example creates a repository with a programmatic call. It illustrates a different interface for software that needs to create repositories automatically, though a single API call is not directly equivalent to every step in an interactive setup. At recording time, access to the service required approval.

A viewer points out that Forgejo supports creating repositories by pushing to them. That capability depends on instance configuration and permissions; it should not be assumed enabled everywhere. It is nevertheless the kind of low-friction workflow I would like agents to be able to use.

Pierre also provides an open-source diff rendering library, @pierre/diffs, which T3 Code uses, and a file-tree rendering library. I like the strategy of building reusable pieces that other developers can assemble, even if the company’s complete GitHub alternative was paused.

Graphite approaches the problem through code review: stacked changes, navigation shortcuts, comments and feeds. In my experience it made review more pleasant, but it was heavily dependent on GitHub. I am friends with its founders, and my view of its potential reflects that relationship.

Graphite added repository mirroring so it could perform more work on its own infrastructure, then was acquired by Cursor. I suspect the combined team could eventually build a substantially different source-code workflow. I have no meaningful inside information about those plans, so that is a prediction rather than a product announcement.

Entire, founded by former GitHub CEO Thomas Dohmke, is another company I am watching; I am an investor and that matters to my perspective. Its initial CLI aims to preserve context from agent sessions alongside code. The aim is to retain more of the decisions and iteration behind a change, not just the final diff.

Zed is also exploring how to record and synchronize changes through DeltaDB, alongside Git interoperability. I do not know whether a future generation of collaboration tools will keep Git at the center or move beyond it. These projects are experiments, and their eventual direction is still uncertain.

The hardest part of leaving GitHub is the community. A profile can connect a person’s projects, contributions and discussions, and a repository often sits alongside its issues and the people who maintain it. That shared location makes discovery and collaboration unusually convenient.

If projects spread among hosted services and self-hosted instances, that shared view becomes harder to maintain. I worry about fragmented histories and weaker connections between maintainers. That is my prediction about a possible cost of migration, not a demonstrated fact that open-source community life has already ended.

An importer or aggregator may recover some data, but I am not convinced it can recreate the social experience of everyone meeting in one place. I compare it to friends graduating and moving away: they can stay in touch, yet the shared everyday setting changes. Others may reasonably be more optimistic about federation and interoperability.

I still hope GitHub improves, while supporting Forgejo and Codeberg and exploring newer tools. Try the alternatives for your own work, test the migration details, and remember that a code host is also a community. I expect to miss that shared home even as new possibilities emerge.