The Fossil ↗ source code management system is the most fully-featured alternative to Git, and has had twenty years of development and testing since 2006. After helping Fossil make some changes I now use Fossil for several projects. I also use Git extensively on various software forges (but not GitHub unless I must). Mercurial ↗ is actively maintained but has lost most of its mindshare since Mozilla ↗ , Bitbucket and others migrated away, and is rarely chosen for new projects today.

In Summary - Why Fossil?

21st century privacy and reproducibility ↗ require code to be in an append-only, non-repudiable Merkle tree ↗ with strong cryptographic guarantees, and that is what Fossil is by design. A Merkle tree is a chain of cryptographic links, where every change is linked to every previous change, so nothing can be silently rewritten.

More Detail - Why Fossil?

  • ✅ Fossil has a simple, small and written-down standard ↗ , so “people not yet born” will be able to read a Fossil repository. Fossil repositories are designed to last for at least 100 years.
  • ✅ Fossil has a second, independently developed implementation of the core data model — libfossil ↗ , a C library which is in turn used to create Fossil-compatible apps ↗ . libfossil does not yet have complete feature parity with the main implementation, but it is significant insurance: if I want to solve a source management problem Fossil does not address, the library gives me a very big start, and the existence of a second implementation tests the standard.
  • ✅ Fossil treats the code record as immutable by design.
  • ✅ Fossil is designed for projects of ordinary size and complexity, which means nearly 100% of all projects. By my own ad-hoc measurements, this means < 8 million lines of code, < 800 developers and < 8 thousand checkin events per year since approximately the year 1990. The unscientific measure I settled on was to import the Git repo for the GNU Compiler Collection ↗ into Fossil, which is 7 million lines of code.

This article is about Fossil, but a reasonable person will ask in 2026 “Why not Git?”.

  • ❌ Git has no independent standard. The project publishes format documentation ↗ for its on-disk structures, but these describe the current implementation rather than defining a stable specification — they change when Git changes, and independent implementations must chase upstream ↗ . Fossil has a written-down format standard ↗ designed to be readable in a hundred years. Git’s format is whatever the source code does this month.

  • ❌ Git’s defaults and design trade-offs were set by the needs of a tiny number of the biggest projects in the world, and all other users have to accept whatever features are good for those few projects. The Linux kernel source tree is enormous, and the Microsoft internal source code repository is much larger again - but nearly all software projects are hundreds of times smaller than these two elephants. Even, say, the large Postgres database ↗ project with 2 million lines of code is twenty times smaller than the Linux kernel. Fossil works great with the Postgres source tree.

  • ❌ Git makes it easy to rewrite history by default and that is very appealing to human psychology: I will just squash my last twenty changes into a single change before committing where my whole team can see it. Unfortunately that decision also means the Merkle tree is not complete.

  • ❌ libgit2 ↗ is an independent reimplementation of Git as a minimal-dependency C library, used at scale by GitHub ↗ and Azure DevOps ↗ among others and with near-complete coverage of the Git feature set. Being purely a consumer of the Git system, libgit2 must adjust to changes made upstream and candidly documents areas where it lags ↗ . Separately, the Git project is pursuing a libification effort ↗ to modularise Git’s own C internals into small independent libraries, and Git 3.0 will make Rust a mandatory build requirement ↗ , an acknowledgement that the C codebase has become difficult to maintain safely. These parallel efforts reinforce the point: the only complete Git standard is the Git source code itself ↗ .

  • ❌ Git source code is a Big Ball of Mud ↗ . One telling example is that in 2017 the SHAttered attack was released ↗ , demonstrating that SHA-1 collisions are practical to create (although not a general compromise of SHA-1). Eight days later a new Fossil release implemented migration to 256-bit SHA-3 ↗ with backwards compatibility to existing SHA-1 based repositories. Git began its own SHA-256 transition in 2020. Nine years after SHAttered, Git 2.51 finally made SHA-256 the default for new repositories, and Git 3.0 ↗ is expected by late 2026 to complete the switch. Fossil shipped the equivalent change in a point release over a weekend. It is difficult to make changes to Git source code, and harder still to get the ecosystem to follow.

💡
Key Point This article is about why I chose Fossil, rather than comparing with Git. For a very detailed and balanced comparison see Fossil v Git ↗ on the Fossil SCM web site.

But GitHub is So Successful!

Git is not GitHub, but yes, GitHub is successful and played a big role in making code visible in the first decade of the 21st century. We’ve been here before: SourceForge ↗ was the dominant forge before GitHub, and is now an afterthought. Will GitHub similarly slide into obscurity? As a US-based cloud company GitHub is unable to offer privacy guarantees that EU-based clouds can. GitHub also is a closed-source cloud offering a restricted level of service for free, and constantly tinkering with their business model and lock-in devices including non-consensual AI tools. These are disadvantages for GitHub in competing with open source forges. GitHub is a good place to search for existing projects, but new projects have options, and alternative forges (all based on Git) are growing fast.

I wanted to find an alternative to Git and GitHub because:

  • I could not convince GitHub to fix visual accessibility problems, and I had multiple team members with visual impairments. It turns out that despite their billions in the bank, it will be a years-long project for GitHub to implement years-old W3C accessibility standards. That is not acceptable.
  • Even if you only ever use a git commandline, Git comes with a lot of pain… even the most experienced software developers wrestle with Git and its complexities. Why should a development team need to worry about losing work? Why should they use an interface so complex that parody man pages look real ↗ ? GitHub may be a good solution for the closed-source needs of the very largest companies, but I am one of millions of developers who have totally different needs. In 2022, after 14 years, GitHub started offering a commandline tool ↗ that can access some of its features. This is not putting developers first.
  • Git encourages merging of private trees, or the ‘Benevolent Dictator development model ↗ ’, which seems to me to be delaying discussion until after code is written. This is what Git supports well because it is the Linux model. There are many online resources and entire training companies dedicated to undoing the default Git/GitHub workflow practices. I like my projects to instead be a tighter ‘cathedral-style’ development community, with discussion happening as code is developed, all branches visible to everyone, and no long-lived active branches.
  • GitHub wants to be at the centre of CI/CD ↗ , and with closed source APIs and services as part of every toolchain. This means that GitHub becomes part of the reproducibility chain, except since GitHub is not transparent these toolchains are not reproducible.
  • There is a common class of source tree management problems that GitHub could address where Git fails, one which no SCM can currently solve. This is the problem of non-diffable trees, some of which is addressed by the Not Forking project. GitHub is the biggest source tree management company in the world, but it does not appear to have thought about this problem - or if it has, does not even give me the tools to explore solutions for myself.

There are two open source EU-hosted alternatives to GitHub that feel to me like they could have a long and happy future - SourceHut ↗ and Codeberg ↗ . SourceHut is able to work with non-Git DVCSs as proved by its Mercurial support ↗ while Codeberg currently only works with git. Both are open source, and I use Codeberg extensively and have installed instances of Forgejo ↗ , the software behind Codeberg.

Other people discuss moving away from GitHub:

In Addition: Security and Privacy Issues More Complex Than They Seem

Well-established security projects use GitHub, but that reflects their resources, not GitHub’s safety. The campaign Give Up GitHub ↗ presents a comprehensive view of why open source software developers should move elsewhere. From my personal point of view, LumoSQL and Sweet Lies projects are two small examples of open source security projects which must be completely sure that the source code is exactly as the developers wrote it, and that the source code has not been interfered with, and that the developers have not had their own personal data misused.

Git and GitHub would cause security problems in my projects:

  1. Git actively encourages users to break the Merkle tree. Rather than an inviolate historical record, Git users expect to produce a curated version of their local tree (especially with the ‘git rebase’ command used to squash commits). This YCombinator thread ↗ discusses the pros and cons of squashing commits.
  2. Finding the descendants of a check-in in Git is so difficult that neither Git nor GitHub provide the capability — you must crawl the commit log yourself. This makes it hard to trace what code was affected by an upstream bug or deliberate insertion.
  3. GitHub is closed source, and since it is also strongly focussed on third-party toolchain integration, that means we cannot know how secure the toolchain is. In April 2021 there was an example of GitHub giving credentials to a compromised toolchain partner ↗ . In 2023 GitHub Actions exposed credentials ↗ .
  4. GitHub is a US-controlled company. As a risk assessment: the US has a history of actively working to insert vulnerabilities into encryption systems ↗ and believing that their NOBUS (Nobody But Us) ↗ policy can work. My projects are critical security systems, so I have to weigh the possibility that GitHub could be instructed by the US government not to inform me of an attack against my projects.
  5. GitHub has US Cloud issues , which correctly means it should not be used by EU developers, etc. While this is legitimately serious, it is common to all US cloud companies.

Fossil may have many security issues too, but it does not have the entirely avoidable ones listed above.

Work Done on Fossil

Before I could use Fossil, I needed some changes:

  • Fossil was not then a commodity, off-the-shelf SCM, and I needed users to be able to just get it easily for their favourite operating system.
  • Fossil only had one implementation, which is something I dislike about Git too. A vital standardised data format should have multiple tools that can read it. As an example of this, any proposal for an Internet RFC can’t be considered unless there are at least two independent implementations, because that is how the standard is tested.
  • I discovered some small but significant bugs in Fossil’s Git compatibility.

So I invested significantly in Fossil, and these problems were fixed:

  • I became a temporary packaging intermediary ↗ with the main distributions. This has been successful… recent operating systems all carry recent versions of Fossil, and this now appears to be self-sustaining. There was a lot of private community interaction to make this happen.
  • I assisted Stephan Beal’s libfossil ↗ to roar back into life as a second, completely independent implementation of the Fossil data model. Multiple implementations are important, and being a library means the world can have multiple front-end alternatives to the official Fossil app. I don’t want my projects locked into Fossil any more than GitHub, although I am perfectly happy with Fossil for now. libfossil is great insurance.
  • I completed a privacy review of Fossil, and debated my proposal ↗ in public. Some of that involved discussion of privacy arcana ↗ .
  • After being accepted as a code contributor, I have made commits to the Fossil tree.
  • I participate in the Fossil forum ↗ , which is an efficient and friendly group discussion.

Fossil as a LumoSQL Test Case

Not only is Fossil a better SCM for the needs of my projects, but it is also a very demanding test case for LumoSQL. Fossil is built on SQLite, in fact Fossil and SQLite are symbiotic projects, and Fossil is the one SQLite application all SQLite developers are guaranteed to use. If Fossil can run on LumoSQL without a problem, and potentially even with some advantages, then LumoSQL will have passed a major milestone.

Not GitLab Either

Once Git and GitHub were ruled out, so was GitLab, but for its own reasons:

  • GitLab is proprietary closed source wrapped around an open source core ↗ . From my experience with GitLab instances I don’t believe it is possible to self-host a fully-functional GitLab — features like full text search are reserved for the paid product, and that will never change because the business model depends on it.
  • GitLab integrates with many of the same third party toolchain services as GitHub, and has been affected by similar security problems as GitHub.
  • GitLab does try to address the common inefficient Git practices with their Git Flow ↗ process. This tries to get closer to the default Fossil way of doing things, but adds a lot of overhead to do so.
  • GitLab Inc. is incorporated in Delaware, headquartered in San Francisco, and trades on the US stock exchange. It is subject to the same US law and US cloud issues as GitHub and other US cloud companies.

Codeberg/Forgejo seems a good Git Forge

I have done a few experiments using Forgejo ↗ and I use Codeberg ↗ . If Git is what you are looking for (which is true for most people) then this European-hosted open source forge appears to address many of the problems of GitHub and GitLab discussed above.

I cannot recommend Sourcehut ↗ in the same way for general use. SourceHut is impressive in its API-first, decomposable design, but not what most developers seem to be looking for now. It is wonderful that Mercurial works as a SourceHut backend (no other forge does this), and Fossil could become a third.