[dev] Forking as a feature

[Jan Schneider]

Zitat von Chuck Hagenbuch <chuck at horde.org>:

> Interesting essay:
>
> http://dashes.com/anil/2010/09/forking-is-a-feature.html

I don't find it as interesting as the discussion that spawns in the  
comments. Actually I find the article rather weak because he only  
describes the status quo and considers it good. He doesn't provide any  
reasoning *why* he considers this new style of forking good.

And by no means he convinced me. I'm rather with some of the  
commenters and still see the fork feature of github as a weakening  
point for projects hosted there. I agree that sometimes it's great to  
have an easier way to fork a project, especially if the project stalls  
or the developers reject too many patches.

But in most cases a patch queue of some sort makes much more sense.  
This is from a code *user's* point of view. Because at the moment you  
end up with a few dozen forks, and without any guidance have to decide  
as a user which ones make sense. There are forks that are quicker  
abandoned than you can say "spoon", others that are obsolete because  
their changes have already been incorporated upstream, with no way to  
find out, and most of them don't merge any upstream progressions.

I'm really curious how this is going to evolve, but at the moment I'm  
still more than sceptic that this does any good to OSS developement,  
at least for most of the projects.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/