gitdot Is Building a GitHub Alternative, and They Are Not Trying to Match It

The Macro: GitHub Won, and That Is the Problem

GitHub has three billion repositories. It is the default. Every developer has an account. Every company uses it. And almost nobody is happy about what it has become.

The platform has grown in every direction. Copilot. Actions. Packages. Codespaces. Security scanning. Project management. Discussions. It is not a code hosting platform anymore. It is a sprawling developer ecosystem that tries to be everything to everyone. And in doing so, it has become mediocre at serving the people who built its early reputation: open-source maintainers.

I talk to open-source maintainers regularly. The complaints are consistent. Pull request review workflows are clunky. The notification system is broken in ways that have been documented for years. Issue triage at scale is painful. CI/CD through Actions works but is weirdly unreliable for something backed by the resources available to its parent company. Stars are a vanity metric that tells you nothing about code quality but dominates how projects are evaluated.

GitLab exists. Bitbucket exists. Sourcehut exists. Codeberg exists. None of them have made a serious dent. GitLab comes closest but has positioned itself as an enterprise DevOps platform, not a home for open-source maintainers. Sourcehut is philosophically aligned with the hacker ethos but has a tiny user base and a deliberately spartan interface. Codeberg is a Gitea instance run by a nonprofit. These are all valid projects. None of them are building specifically for the maintainer experience.

The core tension is this: GitHub optimizes for the broadest possible user base. That means features that serve casual users, enterprise buyers, and AI product strategy. Open-source maintainers are still on the platform because the network effects make leaving expensive, not because the product serves them well.

The Micro: College at Twelve, Rust Git Server, No Stars

Paul Bae and Mikkel Kim founded gitdot out of Y Combinator’s Summer 2025 batch. Bae attended college at age twelve. Kim’s stated philosophy is “always be building.” The team is two people.

Here is what I find interesting about their approach. They are not trying to achieve feature parity with GitHub. They said so explicitly on their site. They are building what they call “an opinionated tool for quality open-source software.” That word, opinionated, is doing a lot of work. It means they are making choices that will alienate some users on purpose.

The technical foundation is a Git server written in Rust. If you know anything about Git server performance, you know why that matters. Git operations at scale are CPU and memory intensive. GitHub’s own infrastructure has dealt with performance issues at the server level for years. A Rust implementation should be meaningfully faster and more memory-efficient than anything written in Ruby, Go, or Java.

The CI/CD platform is designed to be secure by default and testable locally. That second part is important. One of the persistent frustrations with GitHub Actions is that you cannot easily run your workflows locally to debug them. You push, wait, watch it fail, read the logs, fix, push again. It is a slow feedback loop for something that should be fast. gitdot is building CI/CD that you can run on your machine before pushing to the server.

Their issue tracker is designed around the maintainer’s experience, not the submitter’s. That is a philosophical distinction. GitHub issues optimize for making it easy to submit issues. That sounds good until you are a maintainer with 500 open issues and no way to efficiently triage them. gitdot is flipping the priority.

No AI copilot. No vanity stars. No free private repositories. Public repos are free. Private repos cost money. That pricing model is a statement: this platform is for open-source work, and if you want private repos, you are paying for the infrastructure.

The planned launch date is March 31, 2026. The founders have committed to publishing weekly developer logs explaining their design decisions. That kind of transparency is unusual and smart. It builds an audience before the product ships.

The Verdict

I think gitdot is the most interesting challenge to GitHub’s dominance that I have seen in years, and I think it will succeed or fail based on one thing: whether enough high-profile open-source maintainers migrate their projects early enough to create network effects.

The product decisions are all correct, in my view. Rust for performance. Opinionated design for maintainers. Local CI/CD testing. No feature bloat. These are the choices you would make if you actually listened to what open-source maintainers want rather than what enterprise procurement teams ask for.

The risk is obvious and existential. GitHub’s network effects are enormous. Every developer already has an account. Every hiring manager looks at GitHub profiles. Every open-source project gets discovered through GitHub search and trending pages. gitdot does not need to beat those network effects entirely. But they need enough critical mass that using gitdot feels like a signal of quality rather than an inconvenience.

Thirty days, I want to see the March 31 launch land cleanly and which early adopters show up. Sixty days, whether any projects with more than a thousand contributors migrate or mirror to gitdot. Ninety days, the question is whether the developer logs and opinionated design philosophy have built enough of a community to sustain momentum. If ten well-known open-source projects make gitdot their primary home in the first quarter, the flywheel starts. If it is mostly solo developers experimenting, the GitHub gravity wins.