Why I'm Ditching GitHub for Codeberg: The 346-Point Discussion That Changed My Mind

Last Tuesday, I stumbled across a Hacker News thread titled "Why I'm leaving GitHub." Nothing unusual there—developers love a good platform migration story. But this one had several hundred upvotes and counting, and as I scrolled through the comments, I felt that uncomfortable recognition you get when strangers perfectly articulate something you've been trying not to think about.

Those weren't just upvotes. They were receipts.

My GitHub Dependency Audit: What I Actually Found

I decided to map out what I was actually using GitHub for. The numbers were more extensive than I'd admitted to myself: 47 repositories, 12 organizations, three years of accumulated issues and pull requests. But the real surprise was everything else I'd forgotten about.

My deployment pipeline ran entirely on GitHub Actions. My documentation lived on GitHub Pages. I was using GitHub Packages for container registries, GitHub Projects for task management, and GitHub Discussions for community questions on open source projects. At some point, without really noticing, I'd built my entire development workflow around GitHub's ecosystem.

The git repositories were just the tip of the iceberg. I'd been thinking I owned my code when really I was renting workflow space in someone else's infrastructure and calling it mine.

The Policy Changes I Never Voted On

Going through my email history, I found the notifications I'd mostly ignored. The AI training policy rollout that made my public code fair game for training data—not necessarily wrong, but implemented without any real consent mechanism. The interface changes that broke years of muscle memory. I still click in the wrong place on the new issues page.

Then there was the subscription tier shuffle. Features I'd relied on getting moved around, pricing changes that didn't affect me directly but signaled where things were heading. Each change individually reasonable, collectively adding up to something I hadn't signed up for when I first pushed code to GitHub in 2018.

The uncomfortable truth: I'd been treating GitHub like infrastructure when it was always a product. Products evolve according to business priorities, not user preferences.

What "Code Ownership" Actually Means

This got me thinking about what I actually owned versus what I was borrowing. My git repositories? Those I could clone locally, push elsewhere, maintain control over. But everything built on top of that—the continuous integration workflows, the project management, the issue history, the collaboration patterns—that was all platform-specific.

I'd conflated version control with platform services. Git is decentralized; my workflow had become surprisingly centralized.

The mental model shift was jarring. I thought I owned my development process, but I'd been renting it. The repositories were mine, but the infrastructure that made them useful was someone else's, subject to their policy changes, their interface decisions, their business model evolution.

The Codeberg Migration: Week One Reality Check

I started with a single repository migration to Codeberg, more as an experiment than a real move. The actual git migration was trivial—clone, add remote, push. What broke was everything else.

GitHub Actions workflows obviously didn't transfer. Some integrations I'd forgotten about stopped working. But there were unexpected improvements: faster clone times, a cleaner interface that felt more focused on the actual work, and something harder to quantify—a sense of control returning.

The most interesting discovery was muscle memory. How many times per day was I typing github.com without thinking? How many bookmarks, how many saved searches, how many shortcuts had I built around one platform?

The Broader Development Stack Question

This audit made me realize the migration question extends far beyond git hosting. My entire development pipeline had grown around GitHub's ecosystem: CI/CD, issue tracking, documentation hosting, package management, even some deployment strategies.

Each piece individually made sense. GitHub Actions was convenient. GitHub Pages was simple. GitHub Packages integrated nicely. But collectively, they'd created a dependency web I hadn't fully mapped until I tried to imagine extracting myself from it.

The irony struck me: we talk about vendor lock-in as this obvious thing to avoid, but I'd built my own lock-in gradually, one convenient integration at a time.

What I'm Still Figuring Out

Three weeks into this experiment, I'm discovering which gaps actually matter versus which ones just feel unfamiliar. The missing integrations fall into two categories: things that break my workflow and things that just break my habits.

Network effects are the hardest loss to quantify. GitHub's social coding features—stars, follows, contribution graphs—create discoverability and connection patterns that don't exist elsewhere. Am I optimizing for control at the cost of community?

There's also the sustainability question. Is this migration solving a real problem or just satisfying some abstract principle about platform independence? The difference matters, because maintaining multiple hosting strategies has its own costs.

I keep coming back to why it took several hundred strangers on Hacker News to make me examine something as fundamental as where my code lives. What other dependencies have become invisible infrastructure in my development practice? The GitHub audit turned into something larger: a recognition that convenience and control exist in tension, and that the choices we make by default aren't always the choices we'd make deliberately.