GitHub Is Cooked — But Its Alternatives Are Worse

My timeline last week was basically just developers having a collective breakdown. Not the fun kind — the kind where someone posts "GitHub just randomly reverted my merged PR" and sixty people reply "same" within the hour. Merges getting silently undone. Downtime measured in days. The replies were a mix of rage, dark humor, and that specific flavor of exhausted resignation that only comes after you've already refreshed the status page four times.

Theo (of t3.gg fame), who built his whole workflow around GitHub over the past decade-plus, dropped a ~50-minute video this week asking the question that's been living rent-free in the dev community's brain: okay but where do we actually go? He goes through GitLab, Bitbucket, Forgejo, Codeberg, and more. I watched the whole thing. Here's the honest summary: the situation is more trapped than you'd hope.

The checklist that sounds obvious but isn't

Before getting into the alternatives, Theo lays out what we're actually asking for — and it's worth sitting with because "just host my code" undersells it significantly. You need a Git remote with PR workflows. You need CI/CD that doesn't make you want to quit the industry. You need a community layer — profiles, stars, a social graph of what people are building — because that's where open source discovery actually lives. And ideally, you'd like a platform that stays online (novel, I know).

The community piece especially doesn't get enough credit. GitHub isn't just where code lives; it's where the culture of open source lives. Stripping that out doesn't give you a "simpler" tool — it gives you a less useful one.

GitLab: the bicycle nobody rides

GitLab is the first place everyone looks, and Theo's analogy for it is ruthlessly accurate: it's like a bicycle. Theoretically a great option. Practically, everyone just takes an Uber. And the people who do bike? They will absolutely tell you why biking sucks, in detail, unprompted.

I've poked at GitLab before when I was covering the GitHub Copilot drama a couple years ago. I remember thinking "huh, this is fine" — which, in retrospect, is what you think when you spend twenty minutes on a platform instead of twenty months. The actual daily-use experience, as documented by developer Jason Cox and surfaced in Theo's video, is a different vibe entirely.

The UX complaints are specific enough to be genuinely damning. The project README loads 75% down the page by default — they apparently moved it up after getting roasted on Twitter, which Theo correctly calls out as "Twitter-driven design changes" rather than actual product thinking. The releases page shows percentage completion numbers (88% complete? 94% complete?) with no dates and no explanation of what those numbers mean. Navigation between commits works in one direction only — you can go to a parent commit, but there's no "next commit" button. Navigating back and forth between pages causes content to disappear because the app doesn't re-fire API requests on back navigation.

As one developer put it in a post Theo references: "GitLab was designed by developers with no eye for design, but think they do. The UX is atrocious as if they never use their own product. I'd let GitHub lose another 5 to 10% uptime before I would consider switching to Bitbucket before I would consider switching to GitLab."

That's not a minor preference thing. That's daily-workflow broken.

Theo also live-clones the GitLab repository from GitLab itself to demonstrate the codebase complexity. Per that demo — and worth flagging these are his numbers from a live clone, not independently audited — the codebase runs somewhere around 12 million lines of code, including ~3.8 million lines of Ruby and over a million lines of JavaScript (not TypeScript). He counts roughly 528,000 commits. The takeaway: this is not a project you can "just fork and fix." It's a legacy codebase that's been accumulating technical debt since 2011.

The Azure comparison Theo makes here is mean but I think it's basically right: GitLab is like Azure as an alternative to AWS. Similar in shape, worse in almost every practical way, exists primarily because enterprises wanted a cheaper self-hosted option with more control. GitLab reportedly pulled in somewhere around $733 million in revenue in its most recent fiscal year (Theo cited "almost a billion" and "26% growth" — the actual figures vary by period, so treat those specifics as approximate). That's real money, made almost entirely from enterprises who want self-hosted control and don't need the product to feel good — just to work.

Bitbucket: a spreadsheet cosplaying as a dev tool

Okay this is where I lose the ability to be detached. Bitbucket's own marketing describes it as "Git solutions for teams using Jira." That's the pitch. That is what they led with. If you are a developer — someone who cares about your tools, who has opinions about your editor theme, who has strong feelings about tab width — this should make your eye twitch.

Their comparison page against GitHub Enterprise Cloud leans hard into price savings, including a "10x savings" claim that Theo notes is built by stacking every possible GitHub premium add-on (the $50/user security add-on, premium support, etc.) to inflate the baseline. So the comparison is: Bitbucket default vs. GitHub maximum. That's not a comparison, that's a marketing trick, and a lazy one.

The thing is, Bitbucket isn't pretending to be a developer-first product. It's a procurement decision. It's what you get when someone in finance notices that GitHub + security add-ons is costing a lot per seat and asks if there's a cheaper option that still works with Jira. The answer is: technically yes. But the people actually using it every day are not the ones who made that call, and they will not thank whoever did.

If your company switched to Bitbucket to save fifteen bucks a month per engineer, I have questions about every other infrastructure decision your company has made. This is not the mentality that ships good software.

The generational frame — which I think is mostly right, with one caveat

Here's where Theo's video gets genuinely interesting rather than just useful. He argues that GitHub, GitLab, and Bitbucket are all the same generation of product — Git hosting platforms that represent a leap forward from SVN-era source control, but not a leap forward from each other. The VS Code analogy: VS Code didn't beat Sublime by being a different kind of thing, it won by being the best version of the same kind of thing. GitHub won this generation. GitLab and Bitbucket are also-rans in it.

The implication is that a truly better alternative won't look like GitHub-but-improved. It'll look like something we don't quite have vocabulary for yet — the way AI-native coding tools don't really look like "better VS Code," they look like something else.

I find this framework genuinely useful, but I'd push back on one thing: Theo is somewhat dismissive of the self-hosted open source options (Forgejo, Gitea, Codeberg) without spending as much time on what they're actually good at. For a certain class of project — privacy-first, community-governed, small enough that the network effects of GitHub don't matter — those options might actually be fine. The framing of "is this a proper GitHub alternative" assumes the goal is to replicate GitHub at scale, which isn't everyone's goal.

Where this leaves us

The honest read from Theo's full breakdown: GitHub, for all its current dysfunction, is still the only platform where the code hosting, the community graph, and the CI/CD story actually work together without fighting you. That's a depressing conclusion when GitHub is actively reverting merges and staying down for days at a time.

The dev community right now is watching a platform they built careers on make increasingly bad reliability decisions, looking at the exit signs, and realizing the exits lead to... a bicycle that no one likes riding, a spreadsheet with a Jira plugin, or self-hosted options that work but require you to build your own community from scratch.

What actually breaks this open won't be one of the existing players getting better. It'll be something that treats AI-native development workflows as a first-class feature rather than a bolt-on — something that asks what source control even means when your code is increasingly written by agents running in parallel. That product doesn't exist yet in mature form.

Which means the most honest advice is the most annoying one: stay on GitHub, document everything locally, keep backups, and watch closely. The generation-three tool is coming. It's just not here yet — and betting on the current runners-up feels like picking Netscape because you're mad at Internet Explorer.

— Zara Chen, Tech & Politics Correspondent