Forks are expensive

My terminal multiplexer is tmux. Whenever I open my terminal I enter tmux and start a client/server session. It is a very important piece of software. Behind tmux there is a lively community with plugins, docs and cheat sheets. Heck there are startups that pitch products that are solely based on tmux. At the heart tmux is an open source software. The introduction of a permissive ai policy led community members to fork tmux. Forking because of an ai policy is not news to OSS projects and maintainers at this point. But is a fork really the best answer?

Power grab?

I am clearly against this kind of permissive ai policies. Policies are meant to be decisive and not debatable. But, before judging the decision of using ai, I beg to ask some questions. It is important to know how this decision was made.

Here are some of questions that prevent preemptive judging: Was there voting held to make this decision? Does the project haven RFQ process? Who was allowed and voted on this decisions? Do long time contributors have a saying? Who are the sponsors of this project? Do these sponsors have special interest? Are there fashware connections?

It is possible that the project in question is a victim of a power grab. The questions above should reveal such case. If you don’t know about power grabs I highly suggest to read this post by tante.

Fork not good.

If project members and contributors are not happy with the decision, the can simply create a fork and move on. Or so the story goes. I believe creating a fork is worst possible alternative (not BATNA).

You can if fact fork the code quite easily. Go to the git forge and click fork. However, you cannot fork the community. For people to jump ship and join a new community is not feasible. The cost of makeing the switch is too high.

Moreover, maintaining a fork is not about writing code. You need to run and keep many systems (ci, website, docs, packages, registries) busy. The code is the result of these systems doing their job.

Note: Companies such as RedHat learned that forks are expensive this many years ago. Instead of forking they decided to always push upstream. This means making contributions to the origin, establish a relationship and not creating a copy. To make a business you create enterprise graded version downstream and many years later you become multi-million venture. Explained in detail by Jan Wildeboer.

Fork but why?

Being able to fork a project and pivot it into another direction is a fundamental principle in free open source software (FOSS). But, it does not have necessarily have to be the best option. So what else then?

What if we create a fork, always pull from upstream and wait? Wait for what you may ask? Well, wait for the software project to change its license.

There are is already a history of companies moving from an open source license to a source-available license: Elastic, MongoDB, Redis, Grafana, …

This kind of change often was a trigger for the community to change plans. The forks or related alternatives often received a lot of traction. Often to the point where these forks and alternatives became better products that their predecessor.

Let’s call this the “fork but wait” strategy.

Of course the code will be “polluted” by LLMs. But this should not be a problem as long as there is no functional regression (see rsync vs. openrsync). Also there is not such thing as purity in code.