Why we're building a Github alternative

Something is shifting. Over the last year, projects I respect have packed up and left GitHub, not quietly, and not without explaining why.

Ghostty announced it was leaving. Zig migrated to Codeberg. Plenty of individual developers have written their own version of the same story. These aren't fringe holdouts; they're some of the most thoughtful people building software today, and they've decided the place we've all called home for nearly two decades is no longer where they want to do serious work.

I think they're right. And I think the reasons they left point at something bigger than GitHub: a gap that none of the obvious replacements are filling. So we're building Plain to fill it.

The exodus is already happening

You don't have to take my word that something's wrong. The people leaving have been specific.

Mitchell Hashimoto kept a journal of GitHub outages for a month while working on Ghostty. His conclusion was blunt:

This is no longer a place for serious work if it just blocks you out for hours per day, every day.

On a single bad day he noted: "I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage." Almost every day in the journal had an X next to it.

The Zig team, moving to Codeberg, described a platform that had lost its edge:

the engineering excellence that created GitHub's success is no longer driving it

They pointed at GitHub Actions specifically: "inexcusable bugs" in a system that felt "completely neglected," to the point where it "started 'vibe-scheduling'; choosing jobs to run seemingly at random."

And in one developer's account of moving to a self-hosted Forgejo, the real reason wasn't even the downtime:

This decision wasn't primarily driven by GitHub's outages, but rather by the deeper implications of ownership and control over my work.

Why people are leaving

Read enough of these and three themes separate out.

Reliability. GitHub now logs hundreds of incidents a year. Its own SLA commits to 99.9% uptime on paid tiers, which sounds great until you do the maths and realise that's nearly nine hours of allowed downtime a year, and that's the promise, not the record. When the tool that gates every merge and every deploy is down for two hours in the middle of your day, "99.9%" stops being an abstraction.

Ownership. GitHub is now part of Microsoft's CoreAI division. Its CEO stepped down. For a lot of people, the question stopped being "is it up?" and became "whose priorities does this serve, and what happens to my work if they change?"

Stalled innovation. This is the quietest complaint but maybe the most damning. The product that felt magical in 2012 feels, as the Zig team put it, "sluggish and often entirely broken." It hasn't meaningfully reimagined how we build software in years. It's just gotten bigger.

Everyone's "alternative" is just GitHub again

So people leave. Where do they go? GitLab, Bitbucket, SourceHut, Gitea, Codeberg, Forgejo, Radicle.

Some of these are genuinely good, and the self-hostable open-source ones solve the ownership problem cleanly. That's a real achievement and not one to wave away.

But look at what you actually get. Every one of them is, fundamentally, a faithful reconstruction of GitHub. Repos, issues, pull requests, a CI bolt-on. They answer "what if GitHub, but you owned it?" or "what if GitHub, but open source?", and those are good questions.

They just aren't the interesting question. None of them ask what a forge should look like if you designed it in 2026 instead of porting the 2012 design. None of them ship what we now take for granted everywhere else: instant, sub-50ms interactions, offline-first sync, and AI woven into the work rather than stapled to the side.

We've been so busy escaping GitHub that nobody stopped to build something better than it.

The real problem: everything lives in a different tool

Here's the thing the GitHub-clones miss entirely.

Building a product doesn't just mean writing code. It means code and the issues that describe what to build, and the docs that explain how it works, and the CI that proves it works, and the artifacts you ship at the end. Five surfaces, minimum.

Today those live in five different tools. Code in GitHub, issues in Linear, docs in Notion, CI in some YAML you'd rather not look at, artifacts in yet another registry. We spend an absurd amount of effort wiring these together with integrations and webhooks and bots, and the wiring is exactly where the friction lives. Context falls into the gaps between tools. The issue doesn't know about the commit. The doc doesn't know about the release. Nothing knows about anything else without a plugin.

Y Combinator recently put out a request for startups describing this exact disease at the company level: knowledge "scattered across emails, Slack, tickets, and databases," keeping organisations in "open loops." Their framing is sharp: fragmentation makes a company illegible to AI. You can't automate across tools that don't share a model of the world.

Plain is the developer-tooling version of that idea. Put the five surfaces in one system, with one model underneath, and integration stops being something you build. It's just how the thing works.

Why now: AI changes what a forge can be

There's a reason this is worth building now and wasn't five years ago.

AI agents have finally gotten good enough to be a first-class primitive: not a chatbot bolted onto a sidebar, but something that can actually act across your code, your issues, your docs, your builds. A forge designed around that capability is a genuinely different shape of product. It couldn't have existed in 2015 because the agents didn't.

But "AI-first" has earned a bad name, and the migration stories show why. One of the things that pushed the Zig project out was AI being forced on them: Copilot promotion that repeatedly ran over their explicit no-LLM policy. That's not AI as a tool. That's AI as something done to your repo without consent.

Plain's bet is the exact opposite. AI you direct, not AI done to you:

• Agents are explicitly triggered, by an event, a schedule, or a chat. They don't act unless you wire them to.
• Every run has a full audit trail and a rollback. You can see exactly what an agent did and undo it.
• They're a primitive you compose, the same way you compose a CI pipeline, not a feature switched on in your settings by someone else.

The Zig story isn't an argument against AI in a forge. It's an argument for building the kind that respects the person using it. That's the kind we're building.

What Plain actually is

Plain puts all five surfaces in one integrated platform:

• Git: a host that keeps up with you, with globally mirrored conflict-free replication, stacked diffs and inline review, signed commits and protected branches by default.
• Issues: sub-50ms, fully keyboard-driven, offline-first with seamless reconnect, and auto-linked to the commits and PRs that resolve them.
• Docs: a block editor that lives next to the code, versioned alongside every release, backlinked to issues, code, and builds.
• CI: zero cold-start, always-warm runners, an org-wide shared build cache, pipelines defined as composable code.
• Artifacts: content-addressed, deduplicated storage, edge-cached installs worldwide, signed provenance on everything you ship.

And tying them together: Agents, the first-class primitive from the section above, acting across all five surfaces with that audit trail and rollback.

The point isn't the feature list. The point is the line connecting it all. Because the issue, the commit, the doc, and the build live in one system, they actually know about each other, and the automations you can build on top are more powerful than anything you can duct-tape across five tools' APIs. That's also what makes the agents useful: they can finally see the whole picture.

And we're holding ourselves to a real reliability bar: 99.99% uptime, about 52 minutes of downtime a year, an order of magnitude tighter than GitHub's 99.9% promise. If the whole pitch is "this is where you do serious work," it had better be up.

That's the whole idea, and it's why the tagline on the site is the honest summary: the developer platform that finally feels whole.

The bet, and we might be wrong

I'll be straight about the obvious objection, because you're already thinking it.

GitHub is entrenched. Network effects are real: your open-source contributors, your CI integrations, your muscle memory all live there. Integrated all-in-one suites have been tried before and mostly didn't dislodge it. By the base rates, a new forge is a long shot.

We might be wrong. This is a bet, not a sure thing, and I'd rather say that plainly than pretend otherwise.

But here's why I think the bet is good. Every previous challenger competed on GitHub's own terms: same product, cheaper, or open source, or self-hosted. We're not doing that. The cracks the migrations exposed are real, the fragmentation tax is paid by every team every day, and AI agents have just made a genuinely new product shape possible for the first time. When the incumbent is faltering and the ground rules have changed, the maths on a long shot gets a lot more interesting.

That's the bet. We think it's worth making.

Where this goes

The five surfaces are where we're starting, not where we're stopping.

Think about what happens after you've built the thing. You deploy it onto compute. You wire up networking. You provision a database, point DNS at it, and watch it with telemetry. Today every one of those is, again, a separate tool with a separate model and another integration to maintain. It's the exact same fragmentation, just one layer down the stack.

The logic that makes Plain work for code, issues, docs, CI, and artifacts doesn't stop at the artifact. If your build, your release, and your runtime all share one model, then the thing you build in becomes the thing you run on. Compute, networking, databases, DNS, and telemetry are simply the next surfaces, and an agent that can already see your code and your CI can reach all the way through to what's actually running in production and act on it.

That's a long road, and I'm not going to pretend the first release covers it. But it's the direction, and it's why "an integrated forge" undersells what we think this becomes: one coherent platform for building and running software, instead of a dozen tools you glue together and hope stay in sync.

Come build with us

Plain launches in June 2026, and it isn't just a prototype: teams are already building on it, including PolicyStack and Auvia. We're building it in the open and we want the people who've felt this pain most to shape it.

Reserve your place in the first wave →

If you've got opinions about what a forge should be in 2026, especially if you've recently rage-quit one, I want to hear them.