Open Source Studies
e8johan writes "Avaya Labs Research has presented a paper studying the open source process in the cases of Apache and Mozilla. They reach a number of interesting conclusions, the ones I find most interesting are: * Open source projects tend to have a core team of 10-15 coders, producing almost all code. The next layer is a set of developers submitting new features and bugfixes. The next layer is a set of advanced users submitting bug reports. * Open source projects tend to have a lower bug-rate than commercial projects. * Open source projects are generally quicker to respond to user requests. The article also discusses the differences between projects that have always been open source (such as Apache) and projects having a proprietary history (such as Mozilla)."
For some of the best-known free software projects, particularly the Linux kernel and GCC, most of the core coders are paid to work on free software, either full-time or part-time.
Anyways Adobe has a pdf translation engine here. Just punch in the URL ...
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
HTML version via since the original is slashdotted and a PDF anyway.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
I'm sure the study will have very little effect on software development practices.
It reminds me of the study cited in DeMarco and Lister's "Peopleware" on the relation between schedule setting and productivity. They compared programmer productivity under four regimes: schedule set by the manager; schedule set by the programmer; schedule set by a neutral third party; and no schedule. The first three alternatives were tightly bunched, with "schedule set by the manager" producing the worst results (but only by a small amount). The fourth, no schedule, result in more than double the productivity of any of the others.
This book has been out for at least a decade, but as far as I know it has not led to the adoption of schedule-free development anywhere...
"How to Do Nothing," kids activities, back in print!
The metric they used was bug density, not the absolute number of bugs. In other words, number of reported defects per N lines of code.
...
Mozilla is a far larger project than the Apache core, so given an equivalent number of bugs per N lines of code you will see a far larger number of bugs.
They did report that to some extent the measurement of bug density wasn't necessarily directly comparable due to the different state of the projects at the time the report was written (Apache == stable, Mozilla == pre-release). If you're interested in more details read the paper yourself