If I Could Make My Own GitHub
Source: Hacker News
My Billion‑Dollar Forge Idea
My friend and I have a game where we talk about what we’d do if we were rich. Not “paid off the mortgage” rich. Rich like a man who owns a submarine he’s never been inside. Rich like a man whose third wife has a skincare line. Tech‑titan rich — the kind of money that buys you a compound in Wyoming and the confidence to wear the same gray T‑shirt to congressional testimony.
One of mine, for a long time, has been the dream of making a new forge. I was prompted to write this after reading the good post about Ghostty leaving GitHub, but it’s something I’ve written and talked about for a few years. Given how bad GitHub has become at its core job, it seemed like a fun opportunity to try and write up what my billionaire‑folly of a forge would look like. This folly would have fewer “penile rockets” filled with aging celebrities.
What are the problems with modern forges?
GitHub, GitLab, and Gitea (the three I’ve used the most) are all modeled on effectively the same design. There are differences, but you can tell that GitHub sets the pattern for the industry and then those features are ported over to the other two with varying levels of success. The issue with all of these is that they’re designed to add things Git doesn’t do that you need.
Git is great at what it is designed to do, but what it is designed to do isn’t the way most people are using it. Git is a perfect tool for kernel development. It is a decentralized, distributed version‑control system that relies on the idea of patches being sent to maintainers over email. You trust those maintainers to maintain their sections and merge in the stuff that makes sense and not merge in the other stuff. It’s a pretty high‑trust environment that places very few restrictions on how online a specific contributor is or what system they are using. If you have a laptop from 2010 that connects to the Internet once a week, you can still be a meaningful contributor to a project with these workflows.
However, in most jobs, Git is effectively just the way I pull and push from a centralized repository stored in a forge. All the important stuff happens inside the forge, and very little of it happens on my client.
- Pull Requests are how I enforce the four‑eyes principle.
- GitHub Actions are how I run my tests and linting on those Pull Requests to ensure they are functional and meet my organizational requirements.
- The user’s identity in relation to that forge is how I verify who they are.
- I track issues with my code through Issues and cut releases for users to download through Releases.
There isn’t a lot of Git in this workflow; it’s mostly placed on top of Git.
Below are the primary issues I see with modern forges that I would love to solve.
| # | Problem | Desired Improvement |
|---|---|---|
| 1 | Stuff happens in the wrong order – feedback comes after a commit, not before. | Enforced pre‑commit hooks that run jobs remotely on the forge and provide feedback before the push. |
| 2 | PR approval is too Boolean – a PR is either approved or not. | A middle ground (e.g., “weak approve”, “needs follow‑up”) like Gerrit’s model, allowing maintainers to flag a PR for later review. |
| 3 | PRs are too inflexible – every change must pass a four‑eyes check, even when LLMs can safely assess risk. | Customizable approval policies: if the author is a maintainer and an LLM deems the change low‑risk, allow it to merge automatically. |
| 4 | Stacked PRs are just better – they’re easier to review and understand. | Make stacked PRs a first‑class citizen, not an add‑on tool external to the VCS. |
| 5 | A forge shouldn’t do everything – issue tracking is fine, but Kanban boards, wikis, etc., often become low‑quality cruft. | Keep the core lean; avoid “feature creep” that forces users to maintain unwanted components forever. |
| 6 | The standard unit of hosting is too large – GitHub Enterprise and GitLab require heavyweight infrastructure. | Offer small, composable hosting units that can be linked together to form an organization (e.g., “these 12 Raspberry Pis are my org”). |
| 7 | Local clone should represent the entire repo, not just the code. | Allow users to approve PRs and browse issues from the same local VCS view they use to check in code. |
| 8 | Don’t force constant storage costs – I need to be online all the time, but I shouldn’t pay for full history on every clone. | Clone a shallow history by default; lazily fetch deeper history on demand via a background worker. |
| 9 | Actions need to be signed, SHA‑hashed, and usable offline – reproducibility and security are essential. | Provide a mechanism for signed, deterministic actions that can run without a live connection to the forge. |
…and the list continues.
These are the pain points I’d like to address in a next‑generation forge that respects both the power of Git and the realities of modern development workflows.
# Action Tarballs and a Self‑Hosted Forge
I should be able to get tarballs of all my actions, stick them in the repo, and tell my system “don’t go anywhere for checkout action, that’s right here.”
If I say **latest**, have that work like Dependabot does now—opening a PR to put the latest tarballs in my repo. Actions are critical, and they should be runnable on my local machine through the same VCS if I want to.
### Well Y Does Some Of That
Absolutely. There are a lot of tools that do parts of this. I want someone to take them, put them all together, and fit them up. I want **JJ** as the VCS, I want this as the forge, and I want the expectation that I, as a user, could live happily with a Raspberry Pi as a forge for a long time. I want those forges designed around modern concepts like object storage, shallow clones, and getting constantly hammered by LLM bots.
Now, in a universe where GitHub was doing a good job, I wouldn’t even bother writing this up. GitHub is the default, and talking to people about overcoming the default is usually a waste of time. Heinz is the default ketchup; when I order a Coke I don’t want a Pepsi. If I’m going to use a forge up until 2026, there would have to be an amazing reason for me not to choose the one that everyone uses. Up until recently, other forges have been like sweet‑potato french fries—that is, never the thing you actually want.
But we live in a world where the monolithic forge is breaking down and nobody has built the replacement. The people with the money are busy with the rockets. The people with the taste are busy with their day jobs. And the rest of us are opening PRs titled “asdfasdf” at midnight, waiting for a robot to check them, wondering when the tool we spend our whole working lives inside stopped being built for us.
If I ever get the submarine money, I’ll let you know.