Git is already decentralized in one important sense. Anyone who clones a repository receives a copy of its history, and anyone can create a fork without asking a central host for permission. Yet modern software development depends on much more than Git. GitHub and similar platforms centralize project discovery, contributor identity, issues, pull requests, code review, automation, releases, notifications, and reputation. The real challenge is not merely finding another place to store code. It is making all of these surrounding functions work across an open network.
Projects such as ForgeFed point toward a possible answer. Combined with durable decentralized storage, signed records, and local safety tools, federation could support a software commons that no single company controls. A project could be hosted on one service, discussed through another, archived across several networks, and discovered through multiple indexes. That possibility is compelling, but it is much more complicated than putting a Git repository on a blockchain or permanent storage network.
What ForgeFed Could Change
ForgeFed is a federation protocol for software forges and collaboration tools. It extends ActivityPub, the protocol family commonly associated with decentralized social networks, by adding concepts for repositories, commits, issues, patches, merge requests, releases, workflows, and other parts of software development.
In practical terms, ForgeFed could allow someone with an account on one forge to interact with a project hosted on another. A contributor might follow a remote repository, open an issue, submit a patch, or participate in a review without creating a separate account on every service. The receiving forge would evaluate the request according to its own authorization and moderation rules.
This changes the repository from something trapped inside one website into an addressable participant in a larger network. A centralized forge could remain convenient and successful, but it would no longer need to function as an indispensable gateway to the entire software ecosystem.
ForgeFed should not yet be described as a complete decentralized replacement for GitHub. Its specification remains under development, and the surrounding ecosystem still needs mature implementations, interoperability testing, secure defaults, and interfaces that ordinary developers can comfortably use. It is better understood as an effort to develop the common language that federated software services will need.
Federation and Permanent Storage Solve Different Problems
The word decentralized is often applied to several different technologies as if they were interchangeable. They are not. Git distributes source history. ForgeFed concerns communication between independent software forges. Content hashes help users verify that they retrieved the expected bytes. Permanent or archival storage attempts to preserve those bytes beyond the lifespan of one host.
Identity and authorization form another layer. They answer questions about who may update a branch, approve a change, or publish a release. Discovery and reputation form still another layer. They help people find projects and evaluate whether a repository, maintainer, or release deserves their trust.
No one layer provides the full experience. ForgeFed does not automatically make every part of a forge decentralized. Permanent storage does not create code review, spam controls, project governance, or a reliable way to identify the current version of a program. The more realistic future is a composition of interoperable layers rather than a new monolith advertised as the one final replacement for GitHub.
Why Durable Storage Still Matters
A durable storage layer could protect public software from the disappearance, acquisition, policy changes, or failure of a repository host. It could preserve source history, documentation, releases, and build evidence as a public record. Researchers and downstream users could refer to a particular version of a project even if its original website no longer existed.
Content-addressed storage can also improve verification. A release manifest might identify exact source objects, build inputs, output hashes, signatures, and maintainer statements. Independent tools could retrieve those objects and confirm that they match the published references.
Arweave is one possible archival substrate. Its protocol is designed to encourage long-term data availability through cryptographic proofs and an economic storage model. That can strengthen durability, but it should not be treated as a supernatural guarantee that every byte will remain accessible under every possible condition. Independent retrieval methods, redundant archives, exportable formats, and realistic failure planning would still matter.
The Danger of Making Mistakes Permanent
The greatest obstacle to permanent software storage may be ordinary human error. Developers sometimes commit API keys, passwords, private keys, internal logs, customer exports, database dumps, personal information, or proprietary material. A compromised dependency or malicious contributor might also introduce harmful content.
On a conventional forge, deleting a repository or rewriting its visible history does not guarantee that the material has disappeared. Copies may remain in clones, mirrors, caches, and backups. Even so, the host can usually remove the public page and reduce further distribution. A storage network designed for permanence makes that response considerably more difficult.
This does not mean that permanent storage should be rejected. It means that permanent publication must be treated as a distinct, consequential act. If a credential is exposed, it must be revoked or rotated immediately. Hiding a reference may reduce casual discovery, but it does not erase the disclosure.
A responsible client should scan staged material before publication. It should look for recognizable credentials, private keys, unusually high-entropy strings, personal information, dangerous file types, copied logs, and files that project policy excludes. Ambiguous cases could receive an additional contextual review. High-risk findings should be blocked or quarantined for human consideration, not silently altered.
Decentralization Does Not Eliminate Trust
A decentralized forge still requires trust. It simply divides trust among more visible relationships. Users must evaluate maintainers, keys, servers, storage networks, indexers, build systems, moderation policies, and project governance. This can be healthier than placing all authority in one company, but only if the system clearly explains those relationships.
Content hashes can show that two objects contain the same bytes. They cannot prove that the code is beneficial, secure, or genuinely associated with the project a user intended to find. A valid signature can prove that a particular key approved a release. It cannot establish that the key was never stolen or that its owner still possesses legitimate authority.
The system therefore needs practical answers for key creation, backup, rotation, revocation, and recovery. It should account for stolen devices, phishing, lost hardware keys, maintainer departures, organizational transfers, and the death or disappearance of a project owner. Widely used projects may need approval from several maintainers before sensitive changes become authoritative.
Immutable History Still Needs a Current State
Permanent records are valuable for preserving history, but software collaboration also depends on changing statements. Users need to know which commit is currently considered the main branch, which release is recommended, whether an issue has been resolved, and who currently has authority to act for the project.
An immutable storage system cannot rewrite an old statement. It can only preserve a newer statement that supersedes it. A practical architecture could store source objects, releases, and past events on a durable layer while using signed, updateable references for branch heads, maintainer roles, issue status, reviews, and releases.
In that design, a branch name is not a file that gets overwritten. It is a signed claim pointing to an immutable commit. The difficult question is what happens when several valid-looking claims disagree. Cryptography can reveal who signed each claim, but project governance must determine which signer had authority and which decision the community recognizes.
Moderation Must Be Part of the Architecture
Large centralized forges perform extensive abuse prevention. They restrict automated account creation, scan for malware, rate-limit requests, investigate reports, filter spam, and respond to legal notices. A federated network distributes these responsibilities rather than making them disappear.
Projects could decide who may submit issues or patches. Individual forges could quarantine messages from unknown servers, limit abusive peers, or block them entirely. Users could select trusted indexes and filtering services. Communities could share information about spam campaigns and malicious infrastructure.
Different communities would sometimes reach different conclusions. One forge might block a server that another accepts. That disagreement is part of avoiding a single universal moderator. The goal should be to make moderation rules and their consequences understandable while preventing one opaque blocklist or discovery service from quietly becoming the network’s central authority.
Discovery Could Recreate the Same Concentration of Power
Even if repositories and collaboration become federated, people still need to find the genuine project. Search engines, package registries, recommendation systems, domain names, and trending pages currently help answer that question. Any one of them can become a new center of control.
A decentralized software commons could support multiple indexes with published ranking and moderation policies. Projects could publish signed metadata, and users could choose among discovery sources without losing their identity or project relationships. The important feature is not the absence of useful services. It is the ability to replace one service without losing access to the wider ecosystem.
An Incremental Path Beyond GitHub
A credible transition would probably begin with public archives and mirrors. Existing Git workflows could continue while projects add durable backups, signed release manifests, and independently retrievable build evidence. The immediate benefit would be preservation and verification without requiring developers to abandon familiar tools.
Federated issues, patches, reviews, and project following could come next. Permanent publication should receive stronger local scanning and explicit confirmation. Private organizational work would require another level of development, including encryption, membership management, metadata protection, recoverable keys, and integration with existing build systems.
Eventually, multiple discovery services, registries, hosts, gateways, and funding systems could form a plural ecosystem. Success would not mean that centralized services ceased to exist. It would mean that no particular operator could trap a project’s identity, history, contributors, or ability to reach its users.
A Software Commons Must Make Exit Possible
GitHub is difficult to replace because it provides far more than repository storage. A durable alternative must address collaboration, authority, privacy, moderation, provenance, discovery, usability, and governance together. It must also remain fast and understandable enough that developers choose it for practical reasons, not only ideological ones.
The central promise of decentralization is not a world without trust. Such a world is neither realistic nor necessary. The more meaningful goal is to replace opaque dependence on one platform with open protocols, verifiable evidence, multiple service providers, and genuine exit paths. If a developer can leave one host without losing a project, its history, its community, or its place in the wider ecosystem, then a decentralized software commons will have become something more than an appealing idea.
