[dev] Forking as a feature

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> 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.

I'm with Jan on this.  I read this and felt that he was trying to be  
profound, but there really isn't anything in that article.  Forking is  
cool?  Yawn.  Forking is the new way of releasing?  I think not.

Case in point, I went and looked at prototypejs code on github  
(http://github.com/sstephenson/prototype).  Saw that it has been  
forked 107 times.  But what does that mean?  How do I know which one  
of these 107 forks are useful?  Instead, I rely on the social capital  
built up by the original developers to tell me when *they* think a new  
release is ready for prime time.  Because I can go to any of these  
forks and see a commit like "Added awesome new feature which increases  
speed by 400%!", but how do I know that statement is accurate?   
(Since, odds are, I am not familiar enough with the code to be able to  
eyeball the change/diff and be able to tell).  Thus, the need to rely  
on some central authority/group that I trust to tell me that things  
are ok to upgrade.

Forking is useful for software development.  It is lousy for software  
releases.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]