If we took Chromium's multiprocess code and put it in the WebKit tree after the Chrome folks specifically said they did not want to do that, that would have been super rude. Don't you think? That's why I say "hostile fork". I am judging our own path not chosen, and do not mean to cast aspersions on Google's actions.

To be clear, I do not consider Blink to be a hostile fork. I wish the Blink developers good luck & godspeed.

>that would have been super rude. Don't you think?

As long as the license allows it and the maintainer is not burdened in any way, no?

Just because you can do something, doesn't mean you should. To do an action without considering the consequences is foolhardy.

A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project. It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split.

Compare to forking to solve a very specific or specialized problem that doesn't make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case. In such a case, it's common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don't diverge too much.

You could see the history between xMule and aMule for a hostile fork. Or the history between ffmpeg and libav, where some contributors where denied access to the repo.