Forking an open source project nicely

Question

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.

Answer 1

"It's not you it's me."

Answer 2

First say you just want to do some experimental refactoring. You know, just some ideas you want to play with. But these changes may necessitate breaking backward compatibility with the main branch of the project, so you don't want to commit the changes there.

Then create your fork. Of course you are a responsible developer, so you put all code under revision control. Use Launchpad or SourceForge or Google Code or whatever.

Lie low for a while and just work on it yourself. Then get someone you trust to "take a look" at what you've created. Then another someone. Some time after that, make a simple project web site wherever you're keeping your source.

By that time, the folks you thought weren't working out on the original project will probably have moved on too, so there'll be nobody left to offend. The original project will decline in activity as your new project gains followers.

---

Re codelogic's comment:

Right; I was assuming that the people the OP wants to leave behind are not capable of sustaining the project on their own.

I've heard it said, "organizations survive, people don't." That is, no single person is so critical to a project that the remaining team cannot compensate for a vacuum left by that person's departure.

However, in open source, sometimes it's true that no one has the will, the talent, and the time to run a project without the founder.

Answer 3

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.

Answer 4

In most open source projects, the word "fork" isn't often that warmly perceived, I have personally made the experience that asking to work on a "topic branch" in order to develop a specific set of features is much more welcomed.

And this only makes sense: "forks" are by nature potential competitors, while "topic branches" are -at least by design- meant to be eventually merged/contributed back to the project.