Over the past seven days, a quiet tremor has rippled through the decentralized storage landscape—one that most market charts won't capture. Shipyard, a core development team that had been the backbone of the InterPlanetary File System (IPFS) software, announced it has terminated all IPFS-related work. Protocol Labs, the original creator and long-time benefactor, followed suit by ending its funding of the IPFS project. The result? The IPFS protocol, a foundational layer of the decentralized web, now has no dedicated maintainers. The key public services, such as the public gateways that millions of users rely on, hang in the balance, waiting for a decision from Protocol Labs.
This isn't a flash crash or a liquidity crisis. It's a maintenance crisis—a slow, creeping decay that is far more dangerous than any market correction. And it poses a question that cuts to the heart of our entire ecosystem: Can a public good survive without a dedicated steward?
Context: The Quiet Backbone of the Decentralized Web
IPFS, or the InterPlanetary File System, is not a token. It has no native cryptocurrency, no ICO, no trading pairs. It is a protocol—a content-addressed, peer-to-peer method of storing and sharing files. It is the 'data availability layer' that underpins much of what we consider decentralized: NFT metadata, DApp frontends, even parts of the Filecoin network. It is, in essence, a public good. And like many public goods in the crypto space, its development has been historically funded by a single entity: Protocol Labs, which also created Filecoin.
Shipyard was the team that maintained the core Go implementation of IPFS (go-ipfs). They were not just contributors; they were the primary custodians of the codebase. Their departure, coupled with the termination of Protocol Labs' funding, creates a 'maintenance vacuum.' This is not a hypothetical risk. Based on my experience auditing early ERC-20 standards and later working with Aave during the DeFi summer, I've seen how quickly technical debt accumulates when a protocol loses its dedicated maintainers. Code is law, but people are purpose. Without people, the law becomes a dead letter.
Core: The Technical Anatomy of a Maintenance Crisis
Let's be precise about what 'losing dedicated maintainers' means. It does not mean the IPFS network will stop working tomorrow. The nodes already running will continue to run. The existing peer-to-peer network will persist. But the ability to adapt, to patch, and to evolve will grind to a halt.
First, there is the issue of security patches. Every protocol has vulnerabilities. The DHT routing efficiency, the garbage collection mechanism, the handling of large files—these are areas where bugs can lie dormant for years. Without a dedicated team to triage, prioritize, and fix these issues, a critical vulnerability could be exploited. The risk is not immediate, but it is cumulative. As the codebase ages, the 'attack surface' grows. I've seen this pattern in traditional open-source projects that lost their maintainers; the first sign is usually a delay in responding to a disclosed vulnerability. The second sign is a fork, often rushed and poorly maintained.
Second, there is the problem of protocol evolution. IPFS was designed in an era when the dominant use case was static file storage. Today, the needs have shifted. We need dynamic content updates, better integration with browsers, and lower latency for retrieval. These improvements require active development. Without it, IPFS becomes a 'stagnant standard'—still useful, but increasingly out of step with the demands of modern applications. The protocol's performance, already not designed for high throughput, will not degrade, but it will not improve. Competitors like Arweave, with their 'permanent storage' narrative and dedicated development team, will continue to iterate. The gap will widen.
Third, there is the question of the public gateways. The ipfs.io gateway is the most common entry point for users who do not run their own nodes. It is a critical piece of infrastructure. If the gateway becomes unreliable—due to unpatched software, scaling issues, or lack of maintenance—the entire user experience suffers. NFTs that rely on IPFS for metadata may fail to load. DApp frontends may become inaccessible. The trust in the entire ecosystem will erode. Resilience beats hype every time, but resilience requires maintenance. Right now, resilience is in question.
Contrarian: The Uncomfortable Truth About Decentralized Governance
Here is where the contrarian angle comes in. Many in the community will see this as a failure of Protocol Labs or Shipyard. But the deeper issue is a failure of the governance model itself. IPFS was built as a public good, but funded like a venture-backed startup. When the funding dried up, the maintenance stopped. This is not a bug; it's a feature of the current model.
We have a romanticized view of open-source development. We think that if the code is good, the community will naturally maintain it. But the reality is different. Maintenance is unglamorous work. It requires deep domain knowledge, coordination, and sustained attention. It is not something that a loose community of volunteers can reliably provide for a complex protocol like IPFS. Most DAOs have the legal status of 'no legal status'; when things go wrong, members face unlimited personal liability. The same fragility applies to protocol maintenance. The assumption that 'community will step up' is often a comforting fiction. Based on my experience helping ArtBlocks build a creator-first governance model, I know that alignment of incentives is crucial. Without a dedicated funding stream—whether through a foundation, a DAO treasury, or a commercial service—the maintenance will falter.
This event is a wake-up call. It reveals that the 'stewardship model' of a single corporate sponsor is not sustainable for long-term public goods. We need to explore alternative mechanisms: protocol-owned liquidity for maintenance, community-run bounty programs, or even a 'maintenance layer' that charges a small fee for access to the latest security patches. The irony is that the very tool that could solve this—a decentralized autonomous organization for protocol maintenance—is still in its infancy. We are trying to build a house with a hammer that we haven't yet invented.
Takeaway: The Community Must Become the New Central Bank
The future of IPFS now rests on two decisions: what Protocol Labs will do with the key public services, and whether the community can organize to fill the maintenance gap. In my view, the most likely scenario is that Protocol Labs will internalize the maintenance work, but with a reduced team and a focus on the most critical bug fixes. This will slow down innovation but keep the protocol alive. The alternative—a community fork or a new maintainer emerging—is possible but requires a level of coordination that is rare in our space.
But the real takeaway is not about IPFS. It is about the fragility of our infrastructure. We have built a decentralized ecosystem on top of a set of protocols that are themselves centralized in their maintenance. We need to treat maintenance as a first-class concern, not an afterthought. Trust, verify. But also, connect. Connect the maintainers with the users, the funders with the coders, the visionaries with the pragmatists. Community is the new central bank. We must learn to mint our own attention and resources for the public good.
As I write this, I am reminded of a town hall meeting I organized in 2017, when I had to explain to 500 community members why algorithmic fairness is not a luxury but a necessity. The same principle applies here: maintenance is not a luxury; it is a necessity. Without it, the code becomes a relic. The question is not whether IPFS will survive—it will, in some form. The question is whether we, as a community, will learn to treat our infrastructure as a living, breathing entity that requires constant care. Or will we let it fade into the background, a silent casualty of the bear market that no one noticed until it was too late?
The answer lies not in the code, but in us.
