I attended an excellent talk organised by OpenUK about open-source forks recently.

Dawn Foster gave the context about why forks happen and a few historical examples of when forks overtake their originating projects and why that sometimes doesn’t happen and a few occasions when both the original project and the fork end up in different niches.

This was all given life by James Humphries’ talk about OpenTofu and the problems the consortium of former competitors have had getting their project off the ground. One immediate lesson learned was not to just take the head of the forked project but look for a stable milestone to branch from so you don’t immediately inherit someone else’s work in progress.

Another interesting observation was that commits direct to main without the context of a PR were often harder to understand. Change control processes attract a lot of passion but it was interesting that fast moving projects with direct to main changes are harder for newcomers to understand and maintain.

One problem I found particularly interesting was the change in licensing on Terraform’s registry project which meant the fork had to construct an alternative registry very quickly. They had advice from several other projects including Homebrew and were able to quickly bring up a registry that could be community-maintained and with a contribution of network costs from Cloudflare very low-cost.

Hashicorp clearly changed the terms to not allow competitors to use their registry and maybe that’s valid but it demonstrated that it is the ecosystem that makes forks difficult rather the actual code of the tool.

The project removed the tool’s telemetry early on to help respect user privacy but then then that makes it harder to explain whether their fork is finding traction or not. Looking at the traffic into the registry is a proxy for the volume of usage. This balance between privacy and metrics is an interesting one in open projects.