If people are forking your project instead of giving you patches, it probably means 1 of 3 things:
1) You aren't going the direction they think you should go. If this is the case, you don't want the patch anyhow.
2) You have made it too hard to submit patches. They actually found it easier to manage the project themselves rather than go through your patch submission process. Ouch.
3) They think you're doing a bad job as project manager. They would never submit the patch to you anyhow, so nothing is lost by them forking.
And don't forget that if you want the patch, their fork is going to be under the same license, so you can just go grab it from their repo.
In GitHub, that's not the case. People often fork Rails, etc. to make a change that they need locally but will push that (easily) back up to the main project for consideration. Forking allows you and others to easily work with your patched version without even having to wait on the original project. For the project owner that wants sole control of a project, GitHub might not be the right choice. But for those that want other to easily be able to make changes and provide those changes to others, GitHub is great.
Since the article uses evolution metaphors, how about this: forks can be a good way to help organisms (read: projects) navigate a complex multivariate fitness landscape. Abandoned forks then serve as concrete markers of particular design decisions that can be revisited later if a similar kind of problem comes up.
We often don't know ahead of time how a decision will work out, so calling these forks "wasted effort" seems to miss their utility as experiments that can drive the direction of future development indirectly.
http://github.com/mxcl/homebrew is my project. IMO anyone who is afraid of forking is actually just afraid of losing control. It's much easier now for people to do a better job than you. You have to work harder in order to keep your kudos. That guy who has submitted 20 patches a month since 2005 could in theory attract more attention than you and everyone would start using their fork.
6 comments
[ 1.3 ms ] story [ 26.9 ms ] thread1) You aren't going the direction they think you should go. If this is the case, you don't want the patch anyhow.
2) You have made it too hard to submit patches. They actually found it easier to manage the project themselves rather than go through your patch submission process. Ouch.
3) They think you're doing a bad job as project manager. They would never submit the patch to you anyhow, so nothing is lost by them forking.
And don't forget that if you want the patch, their fork is going to be under the same license, so you can just go grab it from their repo.
We often don't know ahead of time how a decision will work out, so calling these forks "wasted effort" seems to miss their utility as experiments that can drive the direction of future development indirectly.
On the way, they probably learned something they didn't know.
That seems like a more then acceptable outcome.
I'm probably 50% right.
You incubated the original idea, and to some that's more valuable then improving the technicalities. Ideas are cheap but initial execution is hard.
On the flip side, for a whole other bunch of people, continued improvement is hard, so the maintainers are the heroes in that instance.