The Billionaire's Folly: Reimagining Code Forges for a Post-GitHub World

In the landscape of software development, code forges have become the invisible infrastructure that powers collaboration, yet their design has increasingly diverged from the actual needs of developers. This reflection emerges from a growing recognition that platforms like GitHub, while dominant, have become bloated, inefficient, and misaligned with contemporary development workflows. The author's thought experiment envisions a new kind of forge—one built not for enterprise scale or feature proliferation, but for the fundamental needs of developers working in an increasingly automated yet still deeply human creative process.

The critique begins with a fundamental observation: modern forges are all modeled on effectively the same design pattern, with GitHub setting the industry standard that GitLab and Gitea then attempt to replicate with varying degrees of success. This homogeneity has resulted in platforms that prioritize centralized workflows over the distributed nature of git itself, creating a disconnect between the version control system and the collaboration tools built atop it.

Several core problems emerge from this design approach. First is the temporal dissonance in the feedback loop—code commits typically happen before validation, leading to the all-too-familiar scenario of late-night debugging sessions where developers push code that should never have left their local environment. The author envisions a system where pre-commit hooks run remotely on the forge, providing immediate feedback before code is ever shared, transforming the workflow from reactive to preventative.

Second is the binary nature of pull request approvals, which fails to capture the nuanced reality of code review. In actual practice, approvals exist on a spectrum—from tentative acceptance to conditional approval to outright rejection. The author points to Gerrit's more sophisticated model as inspiration, where maintainers can weakly approve changes with flags for later follow-up, acknowledging that real collaboration exists in the gray areas between yes and no.

Third is the inflexibility of review requirements, particularly the rigid application of the "four-eyes principle" across all changes. This creates tremendous waste as senior engineers spend valuable time reviewing trivial changes while more complex code waits in limbo. The author suggests a risk-based approach where LLM assessment could determine appropriate review levels, potentially reserving human oversight for substantive changes only.

The critique extends to architectural concerns as well. Modern forges attempt to be everything—issue trackers, CI/CD platforms, wikis, Kanban boards—resulting in monolithic systems that are difficult to deploy, maintain, and customize. The author advocates instead for a modular approach where forges focus on core version control and collaboration features, with other functionalities handled by specialized tools that can be plugged in as needed.

Technical limitations in current implementations also receive attention. The standard unit of hosting remains too large, with GitHub Enterprise and GitLab representing significant infrastructure commitments. The author imagines smaller, federated units that could be linked together to form organizations, potentially running on minimal hardware like Raspberry Pis. Similarly, the disconnect between local repositories and the forge creates friction, with local copies failing to represent the complete project state including PRs, issues, and discussions.

The author's vision extends to how git history and actions are handled. Current approaches either download excessive history or limit visibility, neither of which optimizes for developer experience. The proposed solution would involve on-demand fetching of historical data, combined with portable, offline-capable actions that could be bundled with repositories and run locally when needed.

This thought experiment is particularly timely as GitHub's dominance faces increasing challenges. The departure of projects like Ghostty signals a potential fragmentation of the forge ecosystem, creating an opportunity for alternatives. Yet the author notes that those with resources are pursuing ambitious but peripheral projects (submarines, space tourism) rather than addressing fundamental developer tooling needs.

The implications of this vision extend beyond mere tooling. It reflects a broader philosophical shift toward more humane, efficient development workflows that respect developers' time and cognitive load. By reimagining forges around actual rather than imagined needs, such a platform could potentially reverse the trend of developer tooling becoming increasingly complex and disconnected from daily practice.

Counter-perspectives might question the feasibility of building a competitive forge against GitHub's network effects, or suggest that many proposed solutions already exist in various specialized tools. Yet the author's argument is not merely about assembling existing components but about rethinking the fundamental architecture of code collaboration—a challenge that may require the kind of resources only a "billionaire's folly" could unlock.