Ronacher argues from direct experience shipping libraries through SourceForge, Google Code, Bitbucket, and GitHub eras that something meaningful was lost in the transition. He highlights how the pre-GitHub mailing list culture had friction that served as a feature — filtering for contributors who genuinely cared enough to learn project norms before participating. As the creator of Flask, Jinja2, and other widely-used Python libraries, he has unique standing to compare the fragmented but resilien
Ronacher describes how mailing list workflows required newcomers to lurk for weeks or months to understand project norms before submitting patches. This high barrier to entry meant contributors had genuine investment in the project by the time they participated, contrasting with GitHub's low-friction pull request model that optimizes for volume over depth.
The editorial synthesis draws a key structural distinction: SourceForge and Google Code offered similar technical features (repositories, bug trackers, mailing lists) but neither became a social network for code. GitHub's innovation was making open-source participation a social and identity-building activity, which drove its monopolistic adoption but also fundamentally changed the nature of contribution.
Armin Ronacher — the developer behind Flask, Jinja2, Werkzeug, Click, and more recently a key contributor at Sentry — published a reflective essay on [what open-source development looked like before GitHub](https://lucumr.pocoo.org/2026/4/28/before-github/) absorbed nearly all of it. The post landed on Hacker News and immediately climbed to 390+ points, triggering one of those rare threads where grizzled veterans and curious juniors actually talk to each other.
Ronacher isn't writing from the sidelines. He founded the Pocoo project in the mid-2000s, which produced some of the most widely-used Python libraries in existence. He shipped open-source software through the SourceForge era, the Google Code era, the Bitbucket-vs-GitHub era, and now the GitHub-is-the-only-option era. When someone with that lineage says something was lost in the transition, it's worth examining what, specifically, they mean.
For developers who entered the profession after roughly 2012, it's genuinely hard to imagine open source without GitHub. But the ecosystem that preceded it was vast, fragmented, and in certain ways more resilient.
The forge era. SourceForge (launched 1999) was the first major centralized hosting platform. It offered CVS (later SVN) repositories, bug trackers, mailing lists, and download mirrors — all in one place. Google Code followed in 2006, offering Subversion hosting with a cleaner interface. Both were free, both were proprietary platforms, and both eventually declined. The key difference from GitHub: neither one became a *social network* for code.
Mailing list culture. The Linux kernel, Python, PostgreSQL, and hundreds of other major projects ran (and some still run) on mailing list workflows. You'd subscribe to the dev list, lurk for weeks or months to understand the project's norms, then submit a patch inline or as an attachment. The friction was the feature — it filtered for people who cared enough to learn `git format-patch` and `git send-email`. Maintainers reviewed patches in their email client. There was no green "Merge" button.
Self-hosted everything. Many serious projects ran their own Trac, Bugzilla, or Redmine instances. The Pocoo project itself maintained its own infrastructure. This meant every project had a slightly different workflow, a slightly different bug tracker, a slightly different way to submit code. The cognitive overhead was real, but it also meant no single company could rug-pull the entire ecosystem.
Distributed version control as philosophy. Git and Mercurial weren't just technical improvements over SVN — they were ideological statements. Linus Torvalds built Git specifically so that no single server was authoritative. Every clone was a full copy. The irony that Git's most popular hosting platform became a single point of failure for most of open source was not lost on the people who built these tools.
GitHub didn't just host repositories — it redefined what "contributing to open source" means. The pull request model lowered the barrier to contribution dramatically. Fork, branch, change, PR. A developer could contribute to a project they'd never seen before in an afternoon. This was genuinely transformative for open-source adoption.
But the tradeoffs were real, and Ronacher's perspective is valuable precisely because he experienced both sides:
Centralization risk is no longer theoretical. When Microsoft acquired GitHub in 2018 for $7.5 billion, the open-source community held its breath. Nothing catastrophic happened — but the dependency was exposed. Today, GitHub Actions, GitHub Copilot, GitHub Packages, and GitHub Codespaces mean that many projects aren't just *hosted* on GitHub; their entire CI/CD, AI assistance, package distribution, and development environment run on Microsoft infrastructure. The blast radius of a GitHub outage or policy change now extends far beyond source code hosting.
The drive-by PR problem. The old model's friction wasn't purely wasteful. Mailing list culture meant that by the time someone submitted a patch, they'd usually read the project's contributing guidelines, understood the architecture, and could defend their change in a technical discussion. GitHub's low-friction model enabled "Hacktoberfest PRs" — well-intentioned but context-free contributions that cost maintainers more time to review than they save. The ratio of signal to noise shifted.
Monoculture kills resilience. When every project uses GitHub Issues, GitHub Actions, and GitHub-flavored Markdown, we get consistency at the cost of diversity. The pre-GitHub world's fragmentation was annoying, but it meant that the failure of any single platform affected only a fraction of projects. Today, a GitHub API change can break thousands of CI pipelines simultaneously.
The social graph changed incentives. GitHub profiles became developer resumes. Stars became social currency. This created real incentives to create *new* projects rather than contribute to existing ones — because a repo with your name on it is more visible than a merged PR in someone else's project. The contribution graph's green squares became a metric that optimized for activity over impact.
This isn't a "quit GitHub" argument — that's impractical for most teams. But Ronacher's historical perspective suggests concrete hedges:
Evaluate your GitHub dependency surface. List everything your project uses GitHub for: source hosting, CI, packages, container registry, project management, Copilot, Codespaces. If that list is longer than two items, you've built a single-vendor dependency that would be painful to unwind. Consider whether your CI (GitHub Actions) and your source hosting need to be the same vendor.
The alternatives are better than you think. Gitea and Forgejo offer self-hosted GitHub-like experiences that have matured significantly. GitLab remains a strong option for teams that want integrated CI without the Microsoft dependency. For pure Git hosting, anything with SSH access works — Git was designed for this. Sourcehut (sr.ht) deliberately embraces the mailing-list workflow with a modern interface, proving that the old model can be made approachable.
Preserve the muscle memory of decentralization. Even if you stay on GitHub, practice the skills that the pre-GitHub era required: know how to use `git format-patch`, maintain local backups of your repos, keep your CI configuration portable (use Makefiles or Taskfiles that work anywhere, not just in Actions). The point isn't paranoia — it's that reducing vendor lock-in is just good engineering.
Ronacher's essay resonates because it names a discomfort that many senior developers feel but rarely articulate: we traded a messy, resilient, decentralized ecosystem for a clean, fragile, centralized one — and we did it gradually enough that most people never made a conscious choice. The 390-point Hacker News response suggests this isn't just nostalgia. As AI-powered development tools (Copilot, Cursor, Claude Code) add yet another layer of platform dependency, the question of where your code *actually* lives — and who controls the tooling around it — is only getting more urgent. The developers who remember the before times aren't just reminiscing. They're warning us.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.