DHH 应该将 Rails 从 GitHub 上移除
DHH Should Move Rails Off GitHub

原始链接: https://cameronwestland.com/dhh-should-move-rails-off-github/

GitHub正面临来自新兴工具的日益增长的挑战,这些工具正在挑战其在工作流、CI,甚至核心git托管方面的统治地位。作者详细描述了个人从GitHub Actions转向Blacksmith的转变,体验到更快速、更廉价的构建——强调GitHub即使在计算发生在其他地方时,也通过对Actions控制平面收费而可能存在的“寻租”行为。与此同时,像Linear这样的工具正在以更优的用户体验颠覆GitHub的“Issues + PRs”工作流。 虽然商业团队可以负担采用这些替代方案,但开源项目却被锁定,缺乏迁移的资源。Zig最近的举动,理由是不稳定的CI和不受欢迎的AI集成,表明了日益增长的沮丧。 David Heinemeier Hansson (DHH) 和 Rails 提供了一个关键的机会。Rails从GitHub迁移到Codeberg/Forgejo等平台将会具有颠覆性,迫使替代工具成熟,并为其他开源项目效仿铺平道路。这并非关于当前的准备情况,而是关于*创造*准备情况,充当一个更开放和更具竞争力的开发者生态系统的催化剂。最终,作者认为开源需要一个冠军来加速这一转变,而DHH/Rails则处于独特的位置来领导。

```Hacker News新帖 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交登录[标记]camwest 12小时前 | 隐藏 | 过去 | 收藏 LorenDB 11小时前 [–] 闻起来像AI垃圾。allanmacgregor 11小时前 | 父评论 [–] 根据结构和流畅度很容易判断,有一些老套的短语“发生了什么”。100% AI垃圾。 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系 搜索:```
相关文章

原文

TL;DR — GitHub is trying to charge rent on the Actions control plane while better tools peel away workflow and CI. Commercial teams can route around that. Open source can’t. Rails can.

I didn’t set out to leave GitHub. I just wanted faster CI.

A few months ago, I stumbled across Blacksmith on X. Someone was bragging about their build times dropping by ~50%. I’m a sucker for performance gains, so I tried it.

Here’s what happened: our builds got faster and cheaper. Not “faster but you pay for the speed.” Faster, therefore cheaper. Same tests, less time, lower bill.

That’s when something clicked.

GitHub Actions bills by minutes. But if your compute isn’t running on GitHub’s hardware (Blacksmith runs the machines), what exactly is GitHub charging you for?

The YAML parser? The UI? The orchestration layer?

GitHub has a name for it now: the Actions cloud platform charge. They announced it, and then immediately got slapped by the community and backed off (for now).

Call it what it is: rent-seeking. The moment you can swap out the compute, the only thing left to monetize is the chokepoint.

And once you see it, you can’t unsee it.

Meanwhile, Linear Is Eating Their Lunch

Around the same time, my team at Tilt was drowning.

GitHub Issues here, Notion there, backlogs scattered across three tools. Classic startup entropy.

Someone suggested Linear. Within a week, everyone had switched. Not because we mandated it—because it was that much better. The thing just works: fast, opinionated, beautiful.

Then I started wondering: why am I context-switching back into GitHub for code reviews? Why isn’t the PR right here, next to the issue, in the tool we actually live in?

Turns out, Linear’s been thinking the same thing. They shipped PR reviews (alpha) back in January 2025.

This is the wedge.

Linear doesn’t need to host your git repos. They just need to make GitHub’s “Issues + PRs” bundle feel increasingly vestigial. Death by a thousand cuts.

The Squeeze Is Real

GitHub is getting attacked from both directions:

  • Workflow / DevEx: GitHub Issues + PR UI → Linear
  • Compute: GitHub-hosted runners → Blacksmith (and friends)
  • Control plane: GitHub Actions → increasingly a taxable substrate
  • Git hosting: GitHub → Forgejo / Codeberg / self-hosted Git

And Microsoft is clearly orienting GitHub around AI as the “next platform.” That may pay off long-term, but it creates a window where the core product can stagnate.

Incentive alignment matters:

  • Blacksmith makes money when your builds get faster.
  • Linear makes money when your workflow gets better.
  • GitHub… increasingly makes money when you can’t leave.

If you want the deeper version of this incentives obsession (especially how it shows up in review workflows and AI-era externalities), here are two related posts:

Commercial Teams Have Luxuries

Here’s the thing about my story: I work at a startup.

We can pay for Blacksmith. We can pay for Linear. We can stitch together better tooling because better tooling makes us faster, and faster means we ship more.

Commercial teams are the early adopters who can afford to optimize.

Open source doesn’t have that luxury.

Open Source Is Stuck

If Rails wanted to leave GitHub tomorrow, what would they use?

Git hosting: Codeberg (running Forgejo) is the most credible “public, community-first” destination. But it’s a nonprofit running on limited resources.

CI: Codeberg offers Woodpecker and Forgejo Actions, but their own docs are explicit about resource limits and recommend self-hosted agents for heavier workloads. Rails-scale CI would require real infrastructure.

Issue tracking: Linear doesn’t fit. On the free plan, once you’re over ~250 issues you can’t create new ones. That’s a non-starter for Rails (and for most large OSS projects). And Linear isn’t designed for public contributor workflows.

So the honest take is: the tooling isn’t there yet. Not at Rails scale.

The Canary Just Died Anyway

Last month, Zig moved off GitHub.

Andrew Kelley didn’t write a polite migration post. He wrote a fed-up one. One line in particular is telling:

“GitHub Actions started ‘vibe-scheduling’…”

His point wasn’t “CI is slow.” It was “CI is unreliable enough that a major language can’t consistently validate its own master branch.”

They also cite a different problem: GitHub’s aggressive Copilot push was nudging contributors into violating Zig’s strict no-AI policy. GitHub’s strategy was actively degrading contribution quality for a project that explicitly doesn’t want it.

And Zig didn’t just move code hosting. They’re asking donors to move off GitHub Sponsors to Every.org.

When project leads are this publicly furious, it gives permission to everyone else.

DHH as Accelerant

You know who’s watched all of this? DHH.

There’s a small irony here: GitHub itself is a Rails app — a Ruby on Rails monolith since the beginning. It was the Rails success story.
(GitHub’s own write-up)

Now that same platform increasingly feels slow and enterprise-first, and more willing to tax the chokepoints (like the Actions control plane) than to stay aligned with the community that built it.

DHH doesn’t just complain about platform lock-in. He builds exits and drags his company along with him.

Over the last year he’s done a very public OS journey—macOS → Windows → Ubuntu → Arch. Along the way, he built:

Linux distros were supposed to be settled. DHH made “Year of the Linux Desktop” actually happen—at least at 37signals.

And he didn’t stop at “a fun side project.” He went all in:

Moving Rails off GitHub would be the same playbook, but bigger.

The Forcing Function

A Rails move wouldn’t just be a protest. It would be a forcing function.

If github.com/rails/rails became codeberg.org/rails/rails, suddenly:

  • Forgejo gets real funding and real attention
  • CI solutions appear to handle Rails-scale workloads
  • The docs get written
  • The path gets paved for everyone else

That URL is in tens of thousands of blog posts, tutorials, and Stack Overflow answers. Moving it would be painful.

That’s exactly why it would matter.

Five years ago, leaving GitHub was mass suicide for an open source project. Today, Zig just did it and their community followed. But Zig is still niche.

Rails isn’t niche. Rails is infrastructure.

Rails moving would make leaving thinkable.

Open Source Needs Champions

Commercial teams like mine can pay our way to better tools. We have Linear. We have Blacksmith. We can stitch together a workflow that’s better than GitHub alone.

Open source projects don’t have that luxury. They need someone to go first—someone who can absorb the pain of immature tooling and force it to mature.

DHH has done this before:

GitHub is getting squeezed. The alternatives are emerging but immature. Open source needs a champion to accelerate the transition.

DHH should move Rails off GitHub.

Not because the tooling is ready—it isn’t.

But because moving Rails would make it ready.

联系我们 contact @ memedata.com