Projects fork when one or more groups with different visions from the original project team decide to take a copy of the SourceCode and develop it to their own ends. The SourceCode must be sufficiently Free to begin with for this to happen.
Being able to do this is both a blessing and a curse. Halving the number of developers working on the source for a project more than halves the productivity of each group due to the NetworkEffect – a powerful deterrent to forking. However, a fork can also serve to dissolve the tension in the direction of the previously united project, letting each of the forks focus on a particular agenda. In many (maybe most) cases, all but one of the forks eventually wither and die, and the surviving fork pushes onward with a more well-defined vision that has greater consensus. Forking may therefore contribute to the health of a project in the long term.
In rare cases (such as the Beryl/Compiz split or GCC/egcs), the projects eventually reunite.
Well-known examples of forks include:
Some interesting analyses of the pros and cons of forking are: