Anirudh Oppiliappan on Why Git Was Always Decentralized, and Code Collaboration Never Was

Anirudh Oppiliappan has spent the past year building Tangled from a sharp starting point: git is decentralized, but most of modern code collaboration is not.

After years working across infrastructure, Kubernetes, observability, and open-source systems, he is now rethinking what a code forge should look like when developers want ownership, portability, and a credible alternative to defaulting everything to GitHub.

What stands out with Anirudh is the way he treats developer infrastructure as both technical and social. Tangled is not just about where code lives. It is about where identity, reputation, pull requests, issues, stars, and collaboration live, and what happens when all of that is controlled by a single platform. His answer is not simply self-hosting, but federation: a network of forges where developers can collaborate across servers without losing their data or identity.

Open source is entering a different phase. GitHub has become the default home for global software collaboration, while AI agents are beginning to change the volume, speed, and nature of code contribution. That creates a new question: what should a forge become when both humans and agents are building software together?

We sat down to talk about GitHub dependency, the need for a federation of forges, why developer reputation should be portable, and how AI agents could reshape the future of code collaboration.

Q&A

Q1: What does the software world misunderstand about its dependence on GitHub?

I suppose the misunderstanding is that people think they’ve chosen GitHub, when in reality they’ve just defaulted to it. Git itself is designed to be decentralised—you can clone, fork and send patches regardless of which server the code lives on. It just doesn’t specify a medium for where these interactions should happen. Currently, it all happens on GitHub; with Tangled it happens on an open protocol.

The other thing is people treat GitHub as neutral infrastructure. It’s not. It’s a platform with a business model and when that model shifts (due to various stakeholders, or just neglect)—that entire dependency becomes visible. As it has been recently! With their outages.

To be clear, we aren’t exactly a neutral platform either. We too have a business model. The key difference is that we give people a credible exit path: if you’re unhappy with how we run Tangled, you (or your community) can setup another Tangled and run it the way you see fit—without losing your data or identity.

Q2: What does "a federation of forges" actually mean in practice?

Self-hosting a Git server just means you control where the “bytes” live. Federation is about what happens next: can you open a pull request from your server to mine? Can I follow your activity without having an account on your instance? Can reputation, identity, and collaboration flow across servers without any of them being the center?

In Tangled's case, federation is mediated by the AT Protocol. We have this concept of "knots”: lightweight headless servers that anyone can run. This is where your code repositories live.

When you push code or open a PR, the knot emits events on AT Protocol. The appview at tangled.org aggregates those events, but it's not the only thing that can—anyone can run their own appview and get a consistent picture of the whole network. You can fork a repo across servers, open a pull request across knots, and collaborate with someone whose code lives somewhere completely different from yours. It's much closer in spirit to the original email-based git workflow—patch by email to someone else's repo—except with the social layer everyone expects now.

Q3: What parts of the GitHub social layer should be portable or developer-owned?

At minimum: identity and reputation. Your stars, your followers, your contribution history—these are things developers have spent years building, and right now they live entirely at GitHub's discretion. That's a strange arrangement when you think about it.

The AT Protocol makes this much more tractable. Your identity is a DID — a decentralized identifier you control. Your follows, stars, vouches—these are records in your personal data store. If Tangled disappeared tomorrow, that data wouldn't have to. Your issues, pull requests, and social graph are entirely portable.

Q4: Why did AT Protocol feel like the right foundation for code collaboration?

AT Protocol's architecture fits what we're trying to build. It separates identity from hosting—your DID is yours, not tied to any server. It has a built-in event firehose, which is how our federation actually works: knots emit events, appviews subscribe to them.

A happy consequence of the AT Protocol is its infinite extensibility. Users can build custom integrations, indexes, CLIs or just entirely different “views” into the Tangled network trivially, without us ever having to build an API. This level of end-user customisation is unprecedented, and it goes perfectly hand in hand with a platform for devs.

Q5: How do AI agents change what a code forge needs to be?

The forge was designed around human latency. A PR gets opened, someone reviews it in a day or two, maybe there's some back-and-forth, it gets merged. Agents break every assumption in that flow: they can open hundreds of PRs a day, respond to review feedback in seconds, and operate across dozens of repositories simultaneously.

The first and most urgent problem is spam and trust. We already shipped vouching on Tangled: a web-of-trust model where humans vouch for each other—partly as a response to what we're calling the "slopocalypse": LLM-generated noise flooding platforms. A forge that can't distinguish signal from agent-generated slop is going to become unusable very fast.

The deeper question is what collaboration even means when agents are involved. Issues and PRs are communication protocols between humans. If an agent is opening the issue and another agent is reviewing the PR, what's the human's role? I think the forge needs to become much better at surfacing intent and context; what is this change actually trying to do, who is accountable for it, rather than just tracking diffs and comments.

Q6: What have developers responded to most strongly, and what's surprised you?

Aside from the AT Protocol foundation, what people have been really excited about is our new model for pull requests: stacked PRs. We borrowed ideas from how Google and Meta deal with large swathes of code internally, and we built a system where users can stack changes one on top of another. This allows for a far simpler code review flow, and makes large code contributions easier to reason about. Also allows for cool features like “interdiffing” or diffing between two diffs.

What’s surprised me is just how far early adopters go to make your platform work for them. Tangled is still in alpha, and that comes with a host of issues and subtle bugs. Our users have been extremely willing to put up with tiny annoyances and incomplete features—or just build their own workarounds thanks to the openness of the platform.

Q7: What would you want to have changed your mind on in a year?

I'd want to be wrong about how long it takes developers to actually switch. My working assumption is that inertia is the dominant force in this: GitHub has the network, the integrations, the muscle memory. I'd love to sit down in a year and say: actually, once there's a credible alternative that doesn't ask you to sacrifice anything, people move faster than you'd expect.

And on agents and their autonomy: Right now, agents are still very much on a leash: you run them locally, you prompt them yourself, you review everything they touch. They're powerful tools but they're not yet independent actors in a codebase. I think that changes, and probably faster than most people expect. In a year I'd want to be able to point to agents that are genuinely operating with more independence: opening issues, triaging PRs, making judgment calls because they're part of the team in a more continuous way. If that's where we are in a year, the question of what a forge even needs to be becomes a lot more interesting.