It's time.
You've worked long and hard to add your vision to the open source project you love, on which you've worked, debated, and to which you've contributed inestimable amounts of code and insight.
But it's not going to work out with the existing developers.
You finally need to fork the code.
How do you do this and remain on the best terms possible with the existing project? How do you not say, "Oh yeah? Fork you!"
Aside from the mechanics of cross-polination and assuming that the reasoning for forking is sound, logical, and acceptable, what issues come up?
Competition?
Resource sapping?
User poaching?
How do you go through this arguably difficult and long process until you've diversified enough that these are no longer seen as problems?
Rather than discussing the reasoning behind the decision, please assume that you have already been convinced that forking the code is the best overall solution, and now the point is to move forward in the best way possible.
-Adam
Best Answer
You want to work on your own fork of the code or do you want to fragment the community?
We've internally forked a couple of projects. We'd make a change, ship it up to the owners, they'd say "no thanks", and we'd shrug our shoulders and bring it internally and maintain it ourselves.
Mind, these weren't enormous projects, but that just the way it goes. We haven't published anything, hosted a site, or whatever. We just push the source downstream to our clients with rest of the code base.
There was simply no call for us to "promote" our changes in any more public fashion than the dev mailing list.
If you want to maintain parity with the original, then you're going to have to be aggressive on patch management, and merging, and whatever.
If you don't want to bother, then...don't. No reason to make a public thing about it unless that's the general intent, rather than simply needing a forked version for your own projects.
The source is there to be used, so use it.