ForgeFed represents one of the most exciting movements toward making open-source collaboration fully decentralized. Built on ForgeFed and powered by the ActivityPub protocol, the same framework that drives Mastodon, the goal is to make code hosting and issue tracking interoperable across different platforms. The reference implementation, Vervis, shows how software forges could one day federate as naturally as social networks do. The dream is that developers could collaborate from any platform, whether Gitea, Forgejo, or GitLab, without barriers or duplicated accounts.
The Promise of Federated Development
In the world of open-source software, collaboration thrives on diversity. But that same diversity has led to fragmentation across different forges. Each platform—GitHub, GitLab, Gitea, Forgejo—has its own ecosystems, user bases, and authentication layers. ForgeFed is designed to bridge that divide by enabling these forges to communicate with one another through ActivityPub, creating a shared network for repositories, issues, pull requests, and more.
This approach could radically reshape how developers interact. Instead of being confined to a single platform, contributors could follow projects, comment on issues, and submit code across servers without leaving their preferred environment. It would turn open-source development into a truly federated social system, powered by decentralized trust rather than centralized control.
The Current State: Vervis and Beyond
Vervis is the pioneering reference implementation of the ForgeFed protocol. Hosted on Codeberg, it demonstrates what federation for code forges could look like in practice. While development on Vervis has slowed, the ideas it represents have inspired other projects—most notably Forgejo, which has begun exploring its own approach to federation. These parallel efforts suggest a healthy experimentation phase in the journey toward a unified but decentralized open-source ecosystem.
Yet despite its promise, ForgeFed faces major challenges. The most significant one is identity. Without a shared, portable way for users to authenticate and interact across instances, federation becomes clumsy and difficult to maintain. Developers may need to create separate accounts on every participating forge, which undermines the very simplicity that federation aims to achieve.
The Identity Problem
Identity lies at the heart of any decentralized system. Anvil, one of the projects in this space, has demonstrated some of the challenges. It would require users to create accounts on each forge they want to connect to, along with managing separate personal access tokens. That may work in small cases, but it does not scale for a federated web of interconnected platforms. ActivityPub solved this issue for social networks by allowing remote accounts to interact through unique identifiers like @user@server. But ForgeFed has not yet reached that level of seamless identity integration.
This raises a crucial question: how can open-source developers collaborate across federated systems without creating multiple accounts or giving up user control? The solution will need to balance two priorities: ease of use and self-sovereignty. Centralized identity systems like OAuth or SSO might make things simple, but they reintroduce the very centralization ForgeFed is trying to eliminate. The answer likely lies somewhere between decentralized authentication and verifiable cryptographic identity.
Exploring Web3-Style Identity Solutions
One idea worth exploring is the use of portable, cryptographically verified identities, similar to what platforms like Gitcoin Passport or Nostr offer. These systems allow users to maintain a digital identity that can be verified across multiple services without recreating accounts each time. They operate on the principle of self-sovereign identity—where ownership and verification rest with the user, not the platform.
Another possible direction is a MetaMask-style sign-in system. Instead of relying on centralized databases, such a login could use cryptographic wallets or zero-knowledge proofs to authenticate users across multiple forges. A lightweight blockchain or distributed ledger with low transaction fees could handle verification and signature requests without adding friction or cost. In this setup, users could sign in once and be recognized across the entire federated network.
🟦 Gitcoin Passport could provide a web-of-trust style verification layer for forge accounts.
🟦 Nostr’s public/private key model could serve as the foundation for identity portability.
🟦 A MetaMask-like authentication could make signing into multiple forges feel seamless and secure.
🟦 Together, these could create a single identity system for developers across federated platforms.
Toward a Seamless Federated Future
If ForgeFed can integrate an identity system like this, it would bring the convenience of centralized platforms without compromising user sovereignty. Developers could publish, fork, and collaborate from their preferred platform while still being part of a wider, interconnected ecosystem. Issues, pull requests, and comments could flow naturally between instances. Reputation systems could emerge across forges, allowing contributions to be recognized globally rather than per site.
More importantly, federation would protect open-source communities from platform lock-in. It would allow developers to migrate projects or hosts without losing visibility, followers, or collaboration opportunities. Just as email remains open and universal, federated development could ensure that the spirit of open source remains free from the walled gardens of proprietary hosts.
Challenges Ahead
There are still technical and social hurdles to overcome. Federation introduces complexity in version control, access management, and moderation. Different forges may implement federation features at different speeds, leading to fragmentation before convergence. Identity and trust remain the largest missing pieces of the puzzle, and without them, adoption will remain slow. Yet, with the growing interest from projects like Forgejo and the foundation laid by Vervis, the path forward is clearer than ever.
Conclusion
ForgeFed and its reference implementation Vervis point toward a more open, federated, and user-controlled future for software development. The challenge of identity—how developers authenticate, verify, and collaborate across systems—remains the key to unlocking this vision. Integrating ideas from Web3 identity systems, cryptographic sign-ins, and decentralized trust models could make the next leap possible.
As these technologies continue to evolve, collaboration across decentralized forges may one day feel as natural as sending a message on Mastodon. These are just notes and reflections, and I do not guarantee accuracy. If you see something here that feels incomplete or can be expressed more clearly, please share what you think might be more true. The future of open collaboration will depend on exactly that kind of collective refinement.
