The ability to fork, that is, to take a project's code and continue developing it independently, is one of the fundamental guarantees of free software. Nobody can hold an open source project hostage: if those leading it take an unacceptable direction, anyone can start again from the existing code. But forking is only easy from a technical point of view. Keeping a fork alive is another story.
Two meanings of the same word
The term is used in two very different senses:
- technical fork: a copy of a repository in your own account to work on it and propose changes. This is the normal pull request workflow and has nothing confrontational about it;
- community fork: the birth of an alternative project, with a different name, its own maintainers and separate releases, which competes or coexists with the original.
This article is about the second case.
Why forks happen
The recurring reasons are few and recognisable:
- license change: the original project moves to a non-open source license and part of the community continues from the last free version;
- change of ownership: a company acquires the project and the community fears for its future;
- governance conflicts: deep disagreements about who decides and how;
- abandonment: the maintainers stop responding and someone picks up the work;
- technical divergence: goals so different they cannot coexist in the same codebase.
Well-known examples
A few cases help to understand the dynamics:
- LibreOffice was born from OpenOffice.org when a large part of the community chose to continue under an independent foundation; over time it became the more active branch.
- MariaDB was started from MySQL by some of its original developers, after MySQL had come under the control of a large company.
- Jenkins was born from Hudson following a dispute over the project's name and control.
- OpenTofu and Valkey were born from Terraform and Redis respectively, after those projects moved to non-open source licenses.
In all these cases the fork succeeded because it took along a substantial share of the people actually doing the development, not just the code.
Before forking
A fork splits energy, users and attention. Before launching one, it is worth exhausting the alternatives:
- discuss the problem openly with the maintainers, in writing;
- propose a governance change or a co-maintainer role;
- in case of abandonment, explicitly ask for the repository and packages to be transferred;
- check whether other active forks already exist that you could support instead of creating a new one.
Many forks fail precisely because three appear at once, each with two people.
Name, trademarks and license
An open source license allows you to copy and modify the code, but it almost never grants the use of the name and logo. The fork must therefore:
- choose a new, clearly distinct name and check that it is not already registered;
- remove or replace logos and references that might suggest an official origin;
- keep copyright notices and existing file licenses intact;
- if the original license is copyleft, distribute the fork under the same terms.
When the fork starts after a license change, the starting point must be the last version released under the free license: later code cannot be included.
Concrete steps for a sustainable fork
- State the reason in a public document, measured and free of personal attacks.
- Define governance immediately, so as not to repeat the problems that caused the fork.
- Secure the infrastructure: domain, organisation on the hosting platform, package names in registries.
- Ensure initial compatibility with the original, so users can switch without rewriting anything.
- Publish a first release quickly, even with only minor fixes, to show the project is alive.
- Look for a neutral home, such as a foundation or a fiscal sponsor, if the fork stems from control disputes.
In short
- A community fork is a guarantee of free software, but it splits energy and users.
- It usually arises from license or ownership changes, conflicts or abandonment.
- The license lets you copy the code, not use the original's name and trademarks.
- A fork succeeds if it brings active developers, clear governance and a quick first release.
