The Future of Code Hosting: Beyond Repository Management to Inter-Project Coordination

In the ongoing conversation about what a GitHub replacement should look like, Mat Duggan recently outlined his wishlist for a modern code hosting platform. His list includes familiar features like stacked PRs, pre-push feedback, offline review capabilities, lazy history loading, and graduated approval states. These improvements address legitimate pain points in the current development workflow.

However, Andrew Nesbitt offers a provocative counterpoint: almost every item on Duggan's list represents a client-side problem that's already being addressed by emerging tools. Jujutsu handles stacked changes more effectively than any web UI could. Code review is increasingly happening within editors rather than browsers. Pre-commit feedback naturally runs on the developer's machine where the files actually exist.

The real frontier for code hosting platforms, Nesbitt argues, lies not in improving how we work within repositories, but in how we coordinate between them. "The things I want from a forge are the things that can't move to the client because they involve more than one party," he writes. This represents a fundamental shift in perspective—from viewing repositories as isolated units to understanding them as nodes in a complex ecosystem of interdependencies.

The Relational Blind Spot

GitHub's relationship modeling appears frozen in time. The platform's primary model for connecting repositories remains the "fork," a concept that made sense in 2008 when the typical workflow involved copying someone else's code and submitting a pull request. Today's reality is fundamentally different: we add a single line to a manifest file to incorporate someone else's work across thousands of projects.

"In 2026 the way you use someone else's code is to add a line to a manifest, and the forge has no equivalent object for that," Nesbitt observes. GitHub recognizes dependencies only as triggers for Dependabot PRs, failing to model the rich relationships that actually exist between projects in the modern development ecosystem.

Downstream Testing: Preventing Breakage Before It Happens

One of the most compelling proposals is downstream testing—running a maintainer's test suite against a sample of projects that depend on their code before making a release. Rust implements this approach with "crater runs," but the concept remains largely absent from mainstream forges.

Currently, maintainers often discover they've broken downstream projects only after the fact, through a flood of angry issues or, worse, when dependent projects pin the old version and never upgrade. "The forge is the only place with both the dependency graph and the compute to tell me beforehand," Nesbitt points out. This represents a preventative approach to maintenance that could dramatically improve the stability of the open source ecosystem.

The Dependent Feed: Proactive Communication

Another critical gap is the lack of effective communication channels between maintainers and their downstream users. When planning to remove a deprecated function, maintainers typically document it in changelogs that go unread until it's too late, or emit runtime warnings that often never reach human developers.

Nesbitt proposes a "feed for dependents"—a communication channel that every project with a package in its lockfile would subscribe to by default. This single channel could carry announcements about deprecations, CVE patches, mainter searches, and repository migrations. It represents a more meaningful implementation of "social coding" than GitHub's current focus on following people—instead, following the code you actually depend on.

Fork Networks: Navigating Project Evolution

When a project goes quiet, the community typically fragments into multiple independent forks. Users eventually discover these alternatives through word-of-mouth or pinned issues, but this process is inefficient and opaque. The forge, with its complete view of the ecosystem, could surface active forks when the original project stagnates.

"The forge can see all of this. It knows the upstream hasn't merged in eighteen months and that three forks have active release tags and incoming stars," Nesbitt explains. Displaying this information on the original repository's page would save users from conducting their own archaeological investigations while allowing fork maintainers to signal their projects as continuations of the original work.

Package Registry Features for Repositories

As forges begin to model dependencies more comprehensively, they naturally overlap with package registry functionality. Features like version usage breakdowns, diff views between tagged releases, and dependency trees with vulnerability flags would be valuable for both package repositories and general code repositories.

Community-curated "use X instead" pointers when projects become unmaintained would complement the fork network concept, providing users with alternatives discovered by the community rather than through individual exploration.

Infrastructure Considerations

Nesbitt also highlights several practical infrastructure improvements that would benefit the entire ecosystem:

• Safer CI defaults: Current CI defaults were designed for private enterprise repositories, not open source projects. New forges could implement pinned actions, isolated caches, and workflows that aren't triggered by strangers by default.
• Package caching in CI: Every CI run downloads the same packages from public registries, creating unnecessary load on infrastructure often run by non-profits. A forge-run caching proxy could dramatically reduce this burden while improving build reliability.

Reframing the Conversation

Perhaps most provocatively, Nesbitt suggests renaming "issues" to "tickets." "A feature request isn't a problem, a question isn't a problem, and calling everything that arrives in a maintainer's inbox an 'issue' sets the temperature of the conversation before anyone's typed a word," he argues. This linguistic shift might seem minor, but it could help reduce the ambient hostility that often accompanies maintaining popular projects.

The Open Source Imperative

What's striking about Nesbitt's proposals is their focus on open source maintainers specifically. Enterprise codebases typically don't have thousands of unknown downstreams, so these features would primarily benefit those working in open source without institutional backing.

"There's no enterprise equivalent of any of this, because an internal codebase doesn't have a thousand unknown downstreams, so the only people who'd benefit are open source maintainers with large public dependent graphs and no budget," Nesbitt writes. "Which is probably why GitHub hasn't built it."

The future of code hosting platforms may well depend on which approach prevails: continuing to optimize for the enterprise workflow that pays the bills, or addressing the unique challenges of open source maintenance that underpins much of the software ecosystem. The most successful next-generation forge will likely be one that recognizes these inter-project relationships not as afterthoughts, but as the central challenge of modern software development.