Open source renaissance

open source   community

James Ross explains how LLM slop is causing projects to close their doors to outside contributors and migrate from GitHub to other code forges in Open Source as We Know It Is Dead. There are some really good points in that article, but I am optimistic that the current low point is the prelude to an open source renaissance.

History

Let’s have a look at how version control and forges have evolved in the last few decades to get an idea of how they might change in the future.

  1. 1982: RCS
    • Local versioning. That is, there’s no easy way to contribute commits to a copy of a repository.
    • Version tracking is per file, not for the entire project.
    • Rudimentary, complex branching.
  2. 1990: CVS
    • Client-server model, allowing people with write access to collaborate from their copy of the repository.
    • Project-level versioning, tracking changes to multiple files in a single commit.
    • Easier branching.
  3. 1999: SourceForge
    • Started with CVS support, and added Subversion, Bazaar, Git and Mercurial later.
    • “Major features […] include project wikis, metrics and analysis, […].”
  4. 2000: Subversion
    • Tracks metadata and symlinks.
    • Atomic commits.
    • Easy branching.
    • Authorisation.
    • Can clone directories rather than the whole project.
    • File locking.
  5. 2005: Git
    • Cryptographically hashed commits, making even intentional corruption very difficult.
    • Distributed, meaning there’s no need for a central server. Every clone gets a copy of the entire history, so most operations are local (and therefore faster and more reliable than Subversion, where practically every operation had to go over the network). One caveat is that cloning a single directory is no longer a basic operation.
    • Trivial and cheap branching.
  6. 2008: GitHub
    • Basically everything can be done on the website itself: fork, use the web IDE to change things, create a pull request, respond to feedback from maintainers, ping anyone on the platform by @-ing them.
    • Free server capacity for arbitrary automation.

Basically, Git lowered the bar for local, project-based version control to “Do you have a computer?”, and GitHub lowered the bar for contributing to “Do you have a web browser?”. That is probably the biggest reason why nothing revolutionary has happened in this space in roughly 20 years - for anything to disrupt this situation, the replacement would have to be at least as good as the predecessor, while also providing some compelling reason to move.

Reasons to leave GitHub

  • Controlled by an organisation which doesn’t care about its users, other than as a means to make even more obscene amounts of money.
  • They don’t integrate with other forges. No, syncing repos doesn’t count, that’s trivial with plain Git.
  • They don’t integrate with any other version control systems. This adds a lot of friction for experimenting, and ultimately holds the community back from moving to better options when they arrive. As we can see from the revolutions above, the time is ripe for some new ideas to take over.
  • Ossified, since they already have captured most of the market, and any large change has the potential to affect the bottom line.
  • Despite the above they have not open sourced their systems, so they are clearly settling in for stagnation long-term.
  • Recently unstable, probably for typical enshittification reasons: saving money everywhere until nothing keeps the service going. See Google.
  • Federation services and protocols have matured to the point where building a federated code forge with a similar user experience to GitHub should be doable, since each instance has to handle a tiny fraction of the complexity of a centralised service.
  • One size does not fit all. For example, the GitHub tooling isn’t good enough for the original Git project, the Linux kernel. Right now the barrier to exit is big, because of the pull of the huge user base on GitHub. But open source projects aren’t afraid of creating good ways to migrate both on and off, enabling users to shop around and use whatever they like.

Reasons to replace Git

  • New version control systems solve some of the problems Git has. See for example Jujutsu and Pijul. So far these have received relatively little attention, but that could change quickly.
  • Git is far too popular to apply fundamental changes to the underlying model - it would break existing automation and habits. So evolving Git into something fundamentally different is out of the question.

I’m not saying Git is bad, just that it’s pretty much inevitable that any good software will eventually be replaced by better software.

What next?

Who knows? GitHub is dying, and slop is assaulting projects from bad actors, but open source software developers are nothing if not tenacious, and new ones with fresh energy are brought into the fold every day. Ideas are tested, and overall, with every few steps going backwards, good ideas survive. Open source is changing, not dying. The people, the software, the focus on always improving ourselves and what we build, that will endure.

Version history

No webmentions were found.