It is also, read a certain way, the clearest argument for the opposite of what it concludes.

The history is accurate. The lesson is backwards.

Their timeline is worth repeating because it's correct.

Git shipped in 2005, designed for the Linux kernel: no central server, every clone a full replica, distributed to its core. By 2008, GitHub was founded on the observation that "despite Git's peer-to-peer nature, you actually needed a centralized way to host repositories." The next fifteen years were a sequence of increasingly clever attempts to make that centralization hold up. NFS, which broke on Git's filesystem assumptions. Block replication, an operational nightmare. Google's DHT experiment, defeated by the packfile protocol. Then Spokes, GitHub's three-node consensus system that became the industry standard, and whose ceiling, latency bound by the slowest replica, throughput that gets worse as you add nodes, is exactly what Origin was built to escape.

Origin's answer is elegant: make S3 the source of truth, treat each on-disk repo as a warm cache, replicate statelessly, let idle repos fall to zero replicas and monorepos scale to a hundred. It is the best version of the idea.

But notice what the idea is. Every entry in that twenty-year list is a different technique for solving the same self-imposed problem: how do we put one company back in the middle of a system that was designed not to have a middle?

Nobody in the lineage asked whether the middle was necessary. They inherited it from 2008 and spent two decades optimizing it.

Origin is the most sophisticated centralization yet

This isn't a criticism of the engineering. "Git storage as a database" is a genuinely good abstraction. But a database has an owner. The write-ahead log that serves as Origin's ultimate source of truth lives in Cursor's S3. The linearizable ordering is enforced by Cursor's infrastructure. The provenance trail they rightly celebrate, every operation logged, replayable, debuggable, belongs to Cursor.

That is the trade the whole history has been quietly making. Each generation bought reliability and scale by deepening the dependency on a single operator. Origin buys the most reliability yet, at the cost of the deepest dependency yet: your code's canonical existence is now a row in someone else's log.

And you saw the seam in real time. When Origin launched, the standout line under Cursor's own announcement was that they'd meant to ship earlier, but GitHub was down. Origin's onboarding is "sync your repos from GitHub." The most advanced centralized git storage ever built began life depending on the previous one.

The path not taken

Here is the question the twenty-year timeline never asks: what if the coordination layer didn't need an owner at all?

Git already solved the hard part. The data model is distributed. Every clone is a complete, verifiable replica. The thing that got re-centralized was never storage, it was coordination and identity: who is allowed to write, whose version is canonical, how strangers trust each other's objects. GitHub answered those with an account system. Spokes and Origin answer them with better plumbing underneath the same account system.

Gitlawb is a bet that those questions have a different answer, one that doesn't reintroduce a central authority to enforce them.

Identity is a keypair, not an account. You run one command and get an Ed25519 keypair. That key is your identity, a did:key, no email, no signup, no row in anyone's users table. There is no account to suspend because there is no account.

Writes are signed, not authorized by a server. Every push carries an RFC 9421 HTTP signature. The node doesn't check whether you're allowed in its database; it checks whether the math holds. Authority is cryptographic, not administrative.

Git stays Git. Repositories are real bare Git repositories served over smart HTTP. A remote helper makes git clone gitlawb://… work with an unmodified client. No forked Git, no new protocol to learn, no lock-in dressed as innovation.

Storage is pluggable, and the node is yours. The node is open-source Rust you run with docker compose up. Objects can live on the local filesystem, or S3, or IPFS, or Arweave, the point is that you choose, and you can run your own node and join the network rather than renting a seat in someone else's.

Coordination is federation, not consensus you don't control. Nodes are designed to discover and gossip over libp2p, so a repository's existence isn't bound to one operator's uptime. Origin's answer to "what if a node is down" is "we materialize it from our S3." gitlawb's answer is "clone it from any node that has it."

But that was never the axis that matters

The essay measures how fast and reliably one company can host your code. It's a superb answer to that question. It just isn't the question the agent era is going to ask.

When software agents write most of the commits, under their own identities, across organizations, at a volume no human review queue was built for, the binding constraint stops being pushes per second. It becomes: whose identity is on the change, can it be verified without trusting the host, and does your code survive the host having a bad day, a policy change, or an acquisition. Cursor's twenty-year history is the story of getting very good at the first question by making the answers to the others someone else's to control.

Gitlawb is the bet that you can have git that is fast enough and owned by no one, that the coordination layer, like the data layer before it, doesn't actually need a company in the middle. But the whole history Cursor so carefully documented is evidence for taking it. Twenty years of brilliant people making centralization work a little better each time is also twenty years of nobody checking whether it was needed.

Git already knew the answer in 2005. We just built an industry on forgetting it.

gitlawb is open source, live, and free. Run your own node, hold your own keys: gitlawb.com