Different Kinds of Open Source Forks – Salad, Dinner, and Fish
As I mentioned in the forking protocol post there are different reasons why forks occur. One way to categorize forks is by looking at who is/are the main drivers of the fork.
In general there are two groups of people who might drive a fork: the community (external) and the core developers (internal). They have different reasons and motivations.
A fork driven by the community often occurs because of a lack of transparency or openness. The community, unable to get patches or new features or information (like the roadmap), create a fork to protect their interests.
Since this is an external fork, in the world of place settings, this would be the ‘Salad Fork‘.
A fork driven by core developers or project founders often happens for architectural or political reasons. These motivations for an internal fork make a big difference.
Architecture or Features
A fork based on architecture is a fork that is based on sound motivation. If the core developers do not agree on the direction that the architecture or feature set should go in, the software in the new fork will be different from the original. Community members will decide, based on which architecture or set of features meets their needs, which code line to follow: the original or the fork. If one code line is significantly better than the other, one will fade away. This is competition based on the value of the software and the needs of the communities.
Since this is an internal fork of substance this is the ‘Dinner Fork‘.
A fork for purely political purposes might not be beneficial. It has all of the negative possibilities of a fork (diluting the community etc) with less potential for benefits (choice etc). It has the potential to be nothing more than a popularity contest based on personalities, not on technologies.
Since this internal fork has a certain stench to it, this would be the ‘Fish Fork‘.