Git is for open source

Happy 20th, Git!

Git works great for building open source software. No surprise, since it was originally created to develop the Linux kernel. Why is it a great fit? How does Git’s version control model align with the typical patterns of open source development?

Open source projects typically operate with a hub and spoke model: a project owner or core group of maintainers manages the canonical source, sets the project direction, and gatekeepers contributions from peripheral contributors.

In this paradigm, there is relatively little coordination between the maintainers and the contributors. Anyone is free to send patches (or on GitHub, a pull request) and the owners are free to accept or reject the contribution. Likewise, users are free to fork the project and maintain their own copy, modifying the source as they like.

There is also relatively little obligation between the maintainers and the contributors (or users, for that matter). Open source software is ‘buyer beware’, “AS IS”, take-your-ball-and-go-home territory. The software is given freely but is controlled by the owners/maintainers – it is not a democracy and the owners and contributors in a project are not always aligned in their goals or wishes.

Git supports this way of working wonderfully. At a fundamental level, Git works by copying a repository onto your machine (i.e. it is a distributed VCS), ‘branching’ changes from some previous point in the revision history, and (if desired) having those changes later ‘merged’ into a branch in the canonical source repository. Forking is a substep of the contribution process; the source repository is constantly multiplied and manipulated.

Git’s alignment with the open source model has brought it to a dominant position among version control systems, but this same alignment handicaps users in closed-source projects. In closed source development (such as within a company), Git’s paradigm traps users and prevents innovation build, test, and code review infrastructure.

In contrast to open source projects, closed source projects normally have both high coordination and high obligation between contributors (typically coworkers). Because of this, the ease of source portability (forking) is actually a negative: code is a company asset that must be secured and protected. Likewise, Git’s reliance on ‘branching’ as a model for changes encourages larger change sizes than are optimal or necessary for a highly-coordinated team.

Git’s poor scaling also pressures closed source users to create many repositories, making it more difficult to discover and share code within a company. In the naturally-federated open source ecosystem this is not an issue: small, isolated projects are the norm and dependencies are often managed at arms-length through package managers.

Highly coordinated and aligned teammates on a closed source project can work significantly more efficiently than uncoordinated open source contributors because the nature of the firm massively reduces coordination overhead. In an applied sense, this means they can merge smaller changes, expect faster reviews, and feasibly make breaking changes across multiple systems (again due to coordination ability).

These benefits can only be realized, however, if the tooling at hand supports them. By its nature, Git does the opposite: it incentivizes larger changes (and therefore slower review) and federated codebases. So far, Git’s dominance in open source has been enough to make it the tool of choice in enterprise as well. But the opportunity exists for another tool to deliver a far superior experience for closed source users.