The Distributed Future

From Filing Cabinets to Here

You started this series looking at a folder full of files named project final dot doc. Project final version two. Project final version two, John's edits. Project actually final revised, no seriously use this one. Twenty-one episodes later, you understand how the entire software industry got from there to here.

You know about the code librarians of the nineteen seventies, real people whose full-time job was checking magnetic tapes in and out, writing names and timestamps in logbooks, because there was no software to do it for them. You know about Dick Grune in Amsterdam, who just wanted to work on a compiler in the evenings and accidentally created the tool that an entire generation of programmers would depend on. You know about a CVS server in a closet somewhere, humming away on a hard drive that nobody had tested a backup for in three months, holding fifteen years of institutional knowledge in one place.

And you know what happened when that model hit its ceiling. Thousands of kernel developers sending patches by email. Andrew Morton reading hundreds of diffs a day. Larry McVoy offering a proprietary tool to the world's most important open source project, a generous gift with strings that could be pulled at any time. Andrew Tridgell's curiosity pulling those strings. And then a Sunday morning in Portland, Oregon, in April two thousand five, when one person woke up angry and decided to build something new.

Two weeks later, Git existed. Two weeks. A version control system that would outlast every alternative, survive a seven and a half billion dollar acquisition, and become the invisible infrastructure underneath nearly every piece of software on Earth. Built by a man who named it after himself, because he's an egotistical bastard who names all his projects after himself.

That's the story we've been telling. But now, at the end, I want to step back and look at what it actually means. Not the history. You know the history. The patterns underneath it.

The Threads

Five threads run through every episode of this series. They were never announced, never labeled, but if you've been listening, you've felt them. Let me pull them out and hold them up to the light.

The first is that speed shapes behavior. Linus understood this better than anyone. He didn't make Git fast because he was impatient, though he is. He made Git fast because he knew that if operations are instant, people use them differently. When creating a branch takes microseconds instead of minutes, people branch for everything. Features, experiments, wild ideas they'll probably throw away. When committing is instant, people commit more often, in smaller pieces. When switching between branches costs nothing, people maintain three or four lines of work simultaneously without thinking about it.

CVS and Subversion had branching. It was technically possible. But it was slow and painful enough that teams avoided it. The feature existed, but the speed made it unusable in practice. Git didn't invent branching. Git made branching free. And free branching changed how software gets built more than any other single feature in the history of the craft.

The second thread is the tension between distributed and centralized. It never resolves. Every generation re-litigates it. The code librarians centralized everything in a logbook. CVS centralized everything on a server. Git distributed everything to every machine. And then GitHub re-centralized the social layer on top of distributed storage. GitLab, SourceHut, Forgejo, they're trying to decentralize that social layer again. The cycle keeps turning.

And here's the thing. Both sides are right. Centralization is convenient. One place to look, one source of truth, one login. Decentralization is resilient. No single point of failure, no single point of control, no single company that can change the terms. You want both. You can't have both. So you oscillate between them, and each swing learns something from the last one.

The third thread is that tools shape culture. The fork button on GitHub is a technical feature. Click it, get a copy. But it changed open source governance more than any license, any manifesto, any foundation. Before the fork button, contributing to a project meant requesting access, waiting for approval, navigating mailing lists. After the fork button, anyone could propose changes to anything. The default shifted from "no" to "show me what you've got." That's not a software feature. That's a social revolution wearing a software feature's clothes.

Pull requests aren't in Git. Git has no concept of them. GitHub invented them. And pull requests became the organizing principle for how teams collaborate, how code gets reviewed, how open source gets governed, how junior developers learn from senior ones. A tool built on top of a tool reshaped the culture of an entire profession.

The fourth thread is corporate capture. It starts with BitKeeper. Larry McVoy genuinely helped the Linux kernel. The free licenses were real generosity. But generosity with proprietary strings can be revoked at any time, and it was. That crisis gave birth to Git. Then GitHub took Git and built a platform around it. A startup became infrastructure. Infrastructure attracted Microsoft. Microsoft paid seven and a half billion dollars. And now the company that once called Linux a cancer owns the platform where most of the world's open source code lives.

Has Microsoft been a good steward? By most measures, yes. Private repositories became free. GitHub Actions launched. Investment flowed. But the structural concern doesn't depend on Microsoft's current behavior. It depends on the fact that one company controls a platform that an entire industry treats as essential. Good behavior today is not a guarantee. The BitKeeper story taught us that.

The fifth thread is the invisible people behind the infrastructure.

Junio Hamano took over Git maintenance on July twenty-sixth, two thousand five. Less than four months after Linus created it. He has maintained it every day since. Twenty years. Most developers who use Git every day do not know his name. They know Linus. They know the GitHub founders. They can name the Microsoft CEO who approved the acquisition. But the person who has spent two decades reviewing patches, making release decisions, keeping the tool stable and evolving, is invisible to them.

This is the pattern of infrastructure. The people who build it get the glory. The people who maintain it get silence. And the gap between those two things is where burnout lives, where security vulnerabilities hide, where the XZ backdoor found its opening. Jia Tan spent two years patiently building trust with a lone, overworked maintainer. The attack exploited not a technical flaw but a social one: the fact that critical software often depends on one exhausted person who nobody is watching, because nobody knows their name.

I just kept working on it. There was always more to do.

Those five threads, speed shapes behavior, distributed versus centralized, tools shape culture, corporate capture, invisible maintainers, they don't belong to Git alone. They're the recurring patterns of how software infrastructure gets built, adopted, and fought over. Git is just the clearest example of all five playing out in one story, across two decades, with the same cast of characters.

The Open Questions

So where does this leave us?

Will Git last another twenty years? Probably. But not because it's the best possible version control system. Mercurial was arguably easier to learn. Darcs had more elegant mathematics. Fossil had better integrated tooling. Git won because GitHub created network effects that made the switching cost unbearable. And network effects, once established, don't break easily. They break when something is so much better that the cost of switching becomes less painful than the cost of staying. Nothing on the horizon clears that bar. Yet.

Will AI change version control? It's already changing how code gets written. Copilot generates code. AI reviews pull requests. Automated tools write commit messages. But Git's metadata model, author, committer, timestamp, message, was designed for human workflows. When an AI generates a commit, who is the author? When git blame points at a line, and that line was written by a language model prompted by a human who didn't read the output carefully, what does blame even mean? These aren't theoretical questions. They're happening now. Git's data model doesn't have answers for them yet.

Will federation decentralize the social layer? Forgejo is building it, using the same protocol that powers Mastodon. Follow a developer on one server, contribute to their project on another. The technical pieces exist. But federation has the same problem it has everywhere: convenience pulls people toward the one big platform, and the one big platform is where everyone already is. Mastodon didn't kill Twitter. Forgejo probably won't kill GitHub. But it might build something valuable for the people who care about owning their tools. And that might be enough.

Will Junio maintain Git forever? No. Nobody does anything forever. And the question of what happens when he steps back is one the Git community has been quietly thinking about for years. The Linux kernel survived Linus stepping back from day-to-day maintenance because it had a deep bench of subsystem maintainers. Git has contributors from Microsoft, Google, GitHub, and GitLab. The bus factor is better than it was in two thousand five. But Junio's judgment, his taste for what belongs in Git and what doesn't, that's not something you replace with a committee. When the transition happens, it will be the most important moment in Git's history since the two weeks that created it.

The Strange Way Good Design Outlasts Its Creator

Linus built Git to solve one specific problem. The Linux kernel needed a version control system that was fast, distributed, and capable of handling thousands of parallel contributors. That's it. He wasn't thinking about startups in San Francisco sports bars, or social coding, or AI pair programming, or a seven and a half billion dollar acquisition. He was thinking about patches and merge conflicts and the fact that BitKeeper was gone and he needed something by next week.

But the choices he made in those two weeks turned out to be exactly right for problems that didn't exist yet. Content-addressing means every piece of data can be verified, which matters for supply chain security in ways Linus never imagined in two thousand five. Local-first means you can work on a plane, in a coffee shop with no wifi, or when GitHub is down, which matters for a world that treats a single platform as essential infrastructure. Cheap branching means you can experiment freely, which matters for workflows that didn't exist when branching was expensive.

If you can do something really fast, really well, people will start using it differently.

Torvalds was talking about speed. But it applies to the whole design. Good design has emergent properties. The features you build for one reason turn out to be useful for reasons you never anticipated. Git wasn't designed to be a social platform, a hiring signal, a security tool, or the foundation of modern continuous deployment. It was designed to track kernel patches really fast. Everything else emerged from the design being sound enough that people could build on top of it in ways its creator never imagined.

That's the story of Git. Not just the history, which is dramatic and human and occasionally absurd. But the deeper lesson: when you get the fundamentals right, your creation outlasts your intentions. It becomes infrastructure. It becomes invisible. It becomes the thing that everyone depends on and nobody thinks about, maintained by someone whose name most people will never learn, outliving the feud that created it, the company that commercialized it, and possibly the era that needed it.

You started this series looking at a folder full of badly named files. You end it understanding something most developers never will. Not just how Git works, or why it was built, or who maintains it. But how a tool born from anger and built in two weeks became the quiet foundation underneath everything.

The distributed future is already here. It just looks like a Sunday morning in Portland, a quiet maintainer in California, and a world that learned to share its work, one commit at a time.

Git help. Twenty-two episodes later, you know more about Git than most developers ever will. But there is always more. Type git help followed by any command name and Git opens the full manual page, every flag, every option, every edge case. The pages are dense, sometimes frustratingly so, but they are complete. And now that you understand the concepts, the design decisions, the history, those manual pages will finally make sense. Go explore.