Open source under the microscope (News.com)

Posted Jan 6, 2004 7:07 UTC (Tue) by error27 (subscriber, #8346) [Link]

I have a project on sf.net for "easy graphics" that never got off the ground.

Basically, it was a school project and I was planning to put it online when I got done. I worked my tail off for a week and the result was crap. I was too embarrassed to post it.

People sometimes look at sf.net and point out how many projects there are like this, but that's silly. I didn't invest any worthwhile time and it's not sad that it died.

Games are the worst because it's so fun to sit around talking about writing them but it's difficult to actually sit down and do it.

Posted Jan 6, 2004 10:13 UTC (Tue) by Duncan (guest, #6647) [Link]

> In this example, what is the point of drawing attention
> to the failure rate of free software projects when no
> accurate comment could ever be made about the
> equivalent metric in proprietary software?

It would seem that, by asking that question, you are demonstrating that
you've missed the point. Why must it always be us vs. them? In fact, the
article never mentioned proprietary software at all, that I saw, tho it DID
mention how open source differs from traditional software engineering
concepts, which by implication would be proprietary in nature.

Rather, this, like ESR's The Cathedral and the Bazaar, this is a study of how
Open source techniques and society function on their own, with an eye
toward recognizing what works and what may not, within that cultural and
design concept reference. I don't know about you, but I at least find such
studies useful on their own, and the fact that they are being done, that free
software is considered to be worth study on its own, quite apart from
comparison with closed source, rather refreshing.

Seen as such, and it would appear the study authors take this view as well,
open source project failure isn't specifically a negative, but simply recognized
as part of the process, an accepted part of the culture. The article talks about
how traditional software engineering techniques predict a rapid initial growth
phase, followed by meeting the initial goals and a leveling off of
development, Open source, by contrast, tends to show a hockey-stick curve --
a period of fairly slow initial development with the efforts of only one or a
small group of people, the blade of the hockey stick, followed if the project is
successful by a point at which public interest begins to grow and public
contributions kick in. leading to a higher than linear and far faster than
expected growth rate, the "handle" of the hockey stick. The article doesn't
mention it explicitly, but implicit in that model is that many projects will
"fail", that is, never make it out of the "blade" phase of primarily individual
interest, into the handle or public contribution phase. This is only natural,
since all that extra interest and contribution comprising the handle phase
must come from SOMEWHERE, and that a good portion of it may come
from others giving up on their similar projects, to join the common more
successful public one, as they discover it meets their needs with a lower level
of investment than they were putting into their own "blade" phase project,
shouldn't be surprising.

There were a number of other interesting tidbits in the article as well. One of
particular interest to me was what the article and study authors call
"informalisms", which substitute for the more rigid traditional design spec, and
can be anything from a threaded mailing list discussion of how the software
design should proceed, to FAQs, READMEs, and TODOs, to comments in
the source code, to comments on the web site, possibly in a roadmap
document.

The article and study is pointing out how the open source approach tends to
use these more informal specifications in an evolutional approach -- these
documents tend to reflect the present or historic view of the project, a view
which changes or "evolves" over time -- as compared to the traditional more
rigidly designed spec used in again traditional pay-for-product scenarios,
where the rigidity is needed as a method for measuring when the contracted
work has been done, thus, measuring performance. Without that
requirement, or with it more loosely defined, open source is free to evolve in
new and interesting ways not possible to originally foresee in a rigid design
spec.

All in all, a VERY interesting read. Thanks to LWN for calling our attention
to it, and providing a forum here for its discussion, as well. =:^)

Duncan