Posted: Mon Dec 10, 2007 3:29 pm
Your missing my point...patrikG wrote:I suggest you read the article I've linked to. As I said above, "release early, release often" doesn't work in a non-shared development. The reason why there are a number of stalled projects on sourceforge is that they have never reached critical mass in their number of developers. If they had, "release early, release often" would apply.Hockey wrote:I'm not saying that "release early, release often" *can't* work but rather *doesn't* work...which if you look at all those open source projects on SourceForge...the truth is in the pudding. Perhaps it's an example of a little bit of insight being bad for you...I'm not one to say. Sure, If it's used in conjunction with other best practices, it might be successful, but rushing software leads to poor quality (It's a fact of life with anything really).
I wasn't comparing open source versus closed source, although proprietary software is often rushed too - just for different reasons.
Most open source projects are rushed, as are proprietary projects. I've been developing for long enough that I can see the potential advantages of "release early, release often" but I also have enough experience to realize that is typically not the case.
What does critical mass have to do with it?
Even single developer applications should benfit in theory...the sooner you catch a bug the sooner you get it fixed, the less it reverberates across the entire system. That is undisputable. How does having only X number of developers less than critical mass, make this a moot point?
That statement would apply to open source or closed source, multiple developers or sole developer...whether you have people looking at source code or just using your application...that is the point behind "release early, release often" as I understood it. The problem I see with that approach is that projects can use it as a crutch to avoid proper development techniques/design, etc...``Given enough eyeballs, all bugs are shallow''
Anyways, my point was not to dispute the "release early, release often" ideology (I can see it's advantages/disadvantages) but I'm sure as hell not going to focus on the fact that only 5 of every 5000 open source projects which follow that mantra suceed...
Yes, there are other factors which make or break a software project (open or closed) but it was a sales pitch not a convention. When selling propritary software, I'm not going to promote open source as an alternative, am I? Was I lying? Nope. More open source projects fail than closed source (in my experience - which is what I was selling - not yours - incase you care to argue that).