A friendly fork is one which strives to retain compatibility with the project it's forked from - in order to allow the exploration of new code/features/ideas which can be created, released, tested, and then trusted sufficiently to allow a central code tree to advance in a satisfactory manner.

These can be created by the project itself:

• An UNSTABLE branch (Squid, FreeBSD, Debian)
  • These mature into the RELEASE/STABLE versions.
• A development release ( - eg Linux's .odd releases)
  • TWiki's Alpha releases & beta's aren't really the same - they're effectively candidate releases, not separate trees.

Or by those who believe in the project, but can't hang around for the core project for some reason. A good example would be Alan Cox's Linux tree.

The point here is that there's no hijacking of the project, or breakage of community - it's just a method of moving the codebases of everyone forward in a quicker manner than any central tree can.

Sometimes however friendly a fork is, it will contain code that isn't considered suitable for the core code, which can result in a separate kind of fork. A good example here would be the stackless python implementation.

The flipside of a friendly fork however is an unfriendly fork.

A friendly fork can be is often used to leapfrog over future releases of current stable branch. People heavily invested in stability could run the stable branch, while adventurous and new users could try the fork, debug it to make stable - ready to replace the current stable branch.

-- MichaelSparks, PeterMasiar - 14 Aug 2003