Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Oct 5 '11 at 0:52

This question came from our site for professional and enthusiast programmers.

4 Answers 4

up vote 14 down vote accepted

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.

share|improve this answer

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

share|improve this answer
4  
"Let's just be friends." –  Adam Davis Jan 30 '09 at 23:15
4  
I am now further depressed. –  strager Jan 31 '09 at 0:11

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.

share|improve this answer

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.

share|improve this answer
    
IMHO, the last part of your answer is too presumptuous. It is not common that a popular project will simply decline in activity due to a fork. –  codelogic Jan 30 '09 at 23:48
    
Assuming of course that the project in question was not primarily the work of the single developer that decided to fork. –  codelogic Jan 30 '09 at 23:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.