I have always felt that forking an open source project is mostly a waste of energy because for the most part you get 1, 1 rather than 1+1, in other words the synergy of working together is lost by forking. Secondly forking divides the community.  Today, there are a lot of advocates of forking, and on the side of forking, I have even written a blog on why not all forks are bad:

https://www.bacula.org/all-project-forks-are-not-bad/

On the side of forks are bad, it is important to understand what experts such as Eric S Raymond have to say about it.  I quote:

The three taboos we observed above make perfect sense under this analysis. One’s reputation can suffer unfairly if someone else misappropriates or mangles one’s work; these taboos (and related customs) attempt to prevent this from happening. (Or, to put it more pragmatically, hackers generally refrain from forking or rogue-patching others’ projects in order to be able to deny legitimacy to the same behavior practiced against themselves.)

  • Forking projects is bad because it exposes pre-fork contributors to a reputation risk they can only control by being active in both child projects simultaneously after the fork. (This would generally be too confusing or difficult to be practical.)
  • Distributing rogue patches (or, much worse, rogue binaries) exposes the owners to an unfair reputation risk. Even if the official code is perfect, the owners will catch flak from bugs in the patches (but see [RP]).
  • Surreptitiously filing someone’s name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim’s gift to be presented as the thief’s own.

Of course, forking a project or distributing rogue patches for it also directly attacks the reputation of the original developer’s group. If I fork or rogue-patch your project, I am saying: “you made a wrong decision by failing to take the project where I am taking it”; and anyone who uses my forked variation is endorsing this challenge. But this in itself would be a fair challenge, albeit extreme; it’s the sharpest end of peer review. It’s therefore not sufficient in itself to account for the taboos, though it doubtless contributes force to them.

The full  quote can be found in following section:

http://catb.org/~esr/writings/homesteading/homesteading/ar01s09.html

and the full text of “Homesteading the Noosphere”, by Eric Steven Raymond is at:

http://catb.org/~esr/writings/homesteading/homesteading/index.htm

As project manager of the Bacula open source backup and restore program, I have experience with two open source forks and at least one closed source fork.  All three were made by former Bacula developers.  The first open source fork was Burp and is what I call a friendly non-commercial fork and was the subject of the first blog I cite above.  The second fork was Bareos. The Bareos fork was created by the four directors of DassIT, which is a commercial company and one former Bacula developer.

The third closed source fork is where a former Bacula developer created a backup appliance based on Bacula and the web site now stated that the code is proprietary.  This fork will be the subject of another blog one day and is not really in the category of open source forks that I am discussing here.

What Eric Raymond exposes in his article is that reputation in an open source project is more important than one would imagine.