What's next?

The speaker discusses the growing dissatisfaction with GitHub due to issues like random merge reverts and extended downtime, prompting many, including himself and other prominent developers, to seek alternatives. He acknowledges the difficulty of this situation, especially concerning the open-source community. He outlines key features a GitHub alternative should offer: 1. **Git Hosting:** A reliable, server-backed Git remote supporting collaborative work and pull request (PR) workflows. 2. **Community:** Features like user profiles, contribution histories, activity feeds, and stars to foster community engagement. 3. **CI/CD:** Integration for continuous integration and continuous deployment, similar to GitHub Actions. Beyond existing GitHub features, he desires a "stable platform" (reliable uptime) and "open source" availability for self-hosting. He also vaguely mentions "AI native" capabilities as a future consideration. The first alternative examined is **GitLab**, often cited as the primary option. The speaker draws an analogy: GitLab is like a bicycle – everyone knows it's an option, but most choose other methods due to perceived difficulties. He shares user feedback highlighting significant usability issues. Josh, a developer, describes GitLab's UX as "atrocious," suggesting a lack of design consideration from its developers. He'd rather switch to Bitbucket than GitLab, even if GitHub's uptime worsened. A specific example of GitLab's poor UX is demonstrated: navigating back and forth can cause content to disappear because API requests are not reliably re-fired. Jason Cox further details "UX monstrosities." The speaker points out that a project's README is often buried 75% down the page, and navigation elements like release numbers have the same visual weight, making crucial information hard to find. Searching for old commits is nearly impossible without knowing the exact message or author, as infinite scrolling is inefficient and date filtering is absent. The release page itself is confusing, with ambiguous "percent complete" metrics, hidden dates, and no clear way to view all commits within a release or navigate to subsequent commits. The speaker then attempts to clone the GitLab codebase to assess its complexity for potential community contributions. The clone process is extremely slow, taking nearly five minutes just to enumerate objects, and the repository contains over 7 million Git objects. The codebase itself is massive: 3.8 million lines of Ruby, 1.16 million lines of JavaScript (not TypeScript), 600K Vue components (Vue 2, not Vue 3), and significant amounts of Markdown, JSON, YAML, and raw SQL. This extensive and dated codebase makes it incredibly difficult for individuals to "vibe code" their way out of issues or contribute meaningfully. He concludes that GitLab, while an open alternative, is "just a worse version of GitHub" in nearly every aspect except potentially uptime and enterprise pricing. He introduces the concept of "generations of product" using text editors as an analogy: Sublime Text (Gen 1.0), Atom (Gen 1.5, open source but a downgrade), VS Code (Gen 1.9, best of its generation), and Cursor (Gen 2.0, AI-enhanced). He argues that GitLab and Bitbucket belong to the same "Gen 2" of version control as GitHub, not representing a generational improvement but rather alternatives within the same paradigm. VS Code succeeded by being the best of its generation, not by introducing fundamentally new features. Next, **Bitbucket** is reviewed. Its Google search description, "Git solutions for teams using Jira," immediately signals its primary value proposition. Atlassian's comparison with GitHub emphasizes cost savings and "best-in-class Jira integrations" rather than superior functionality. Bitbucket's pricing model is shown to be significantly cheaper per user, but the "10x savings" claim is based on adding all expensive GitHub Enterprise Cloud add-ons, making the comparison disingenuous. The speaker critiques companies that prioritize such marginal savings over paying engineers well. While Bitbucket offers included DevSecOps tools and premium support with 99.9% SLAs (a rare positive), its build minutes are account-wide, not per user, requiring additional purchases for higher usage. The core value of Bitbucket is its deep integration with the Atlassian ecosystem (Jira, Jira Service Management), making it attractive only to existing Atlassian customers. The speaker dismisses Bitbucket for most users who are not already heavily invested in Atlassian products. Moving to open-source and nonprofit options, the speaker first examines **Gitea (Git T)**. Despite its claim as an open-source alternative, the speaker notes its website emphasizes "private, fast, reliable DevOps platform" and uses questionable quotes from non-existent or zero-following accounts. Gitea faced a "rug pull" where its maintainers shifted towards a more private, for-profit model, leading the community to fork the project. This fork is **Forgejo**, maintained by the democratic nonprofit Codeberg EV. Forgejo aims to be a self-hostable, lightweight, and low-maintenance software forge. The speaker expresses strong support for Forgejo, praising its community-driven, truly free software approach. He creates an account on Codeberg, a hosted instance of Forgejo. While the initial UI is not polished, he finds the underlying Forgejo project well-maintained and solid, with a much smaller and more elegant codebase (around 12MB, 400k lines of Go) compared to GitLab. Being built on Go, it promises faster performance than Ruby-based alternatives. He highlights several positive aspects of Forgejo: * **Clear UI:** Releases are a top-level tab, and the release page provides all necessary information (date, commit count) clearly, unlike GitLab. * **Search and RSS:** Includes an actual search function and an RSS feed for releases, catering to developers. * **Issue Tracking:** Similar to GitHub, issues load quickly and support embedded images. * **Code Review:** While having some UI jank, it's "absolutely passable" and displays lines changed. It does require a page reload to switch between split and unified diff views, similar to GitHub. * **Transparency:** Forgejo is exclusively free software, developed by a nonprofit, and uses Forgejo Actions for its own testing and releases (unlike Gitea, which uses GitHub). It prioritizes security fixes and stability with end-to-end testing. The speaker is so impressed that he donates $1200 and commits to $400/month in recurring donations to Codeberg, emphasizing the importance of supporting such projects. He plans to move some of his own projects to Forgejo, noting that Forgejo Actions can largely use the same YAML files as GitHub Actions, making migration easier. He also praises Codeberg's transparency regarding downtime (e.g., for security patches) and the option for self-hosting or bringing your own runners for actions. He strongly recommends Forgejo for self-hosting over GitLab due to its Go-based architecture and robust design. He briefly dismisses other older or less relevant options like SourceHut, Code Commit, Google Code, SourceForge, and Fabricator. The discussion then shifts to **Pierre**, a GitHub alternative that paused its development to focus on building "primitives to make a better GitHub." One such primitive is **code.store**, an "ultra low latency git cloud for reading and writing files from anywhere." Code.store aims to handle the high throughput of agent-generated code, which GitHub struggles with due to its older, Ruby-based architecture. Pierre's code.store handled 9 million repos in 30 days and a peak of 15,000 repos per minute for three hours without downtime, demonstrating its capacity for "Gen 3" source control. The speaker contrasts the complexity of creating a new GitHub repository via the GitHub CLI (nine steps, four loading blockers, and buggy behavior with keyboard shortcuts) with code.store's programmatic approach: `store.createRepo()`, a single line of code. This highlights the generational difference in developer experience. While code.store is currently invite-only, Pierre is also building other open-source primitives like **diffs.com** (a diff rendering library used by T3 Code) and **trees.software** (a file tree rendering library). Pierre, a VC-backed company, is focusing on building these foundational components for future GitHub alternatives, rather than a direct replacement. **Graphite** is introduced as another potential "big winner." It focuses on improving code review workflows, offering a significantly better experience than GitHub for reviewing code, navigating PRs, and commenting. Initially built on top of GitHub's API, Graphite faced performance issues due to GitHub's slowness. They addressed this by mirroring repos on their own infrastructure, leading to better performance. Graphite was recently acquired by Cursor, leading the speaker to suspect that Cursor and Graphite together could build a fundamentally different, "Gen 3" approach to source code management, moving beyond being just a "better GitHub." Finally, **Entire** is presented. Founded by Thomas Dohmke, the former CEO of GitHub, Entire recently raised a $60 million seed round. The speaker is also an investor in Entire. Entire's first product, the Entire CLI, focuses on tracking "agent context." They argue that Git preserves "what changed" but not "why," leading to context loss for AI agents. Entire aims to create more durable history alongside code to provide agents with better context. This aligns with other efforts like Zed's Delta DB, which uses CRDTs to record and synchronize incremental changes, interoperating with Git but supporting real-time interactions beyond Git snapshots. This suggests a potential "Gen 3" where the underlying version control might move beyond Git entirely. The speaker concludes with the "most heartbreaking part": the loss of the **GitHub community**. GitHub's central role meant that developer profiles, project histories, issue discussions, and source code were all in one place. This unified community fostered connections and made it easy to assess a developer's legitimacy or a project's activity. The "great fracturing" has begun, with projects dispersing across various platforms (Forgejo, GitLab, self-hosted instances, federated solutions). This means the consistent, 20-year history of open-source contributions linked to individual profiles is over. He likens it to graduating from high school – while friendships may endure, the shared experience and central "home" are gone. He expresses sadness over this inevitable loss of community, despite the promise of better, more stable hosting alternatives. He hopes GitHub can improve but doesn't expect it, committing to supporting projects like Forgejo and Codeberg and building the foundations for future, more stable homes for code.