Slashdot Mirror
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
Lest anyone think that you're full of theory, here's a concrete example: Zope Corporation and the Zope application server.
.
Quick background: ZC wrote Zope, released it under a GPL-compatible license, and makes money from large (>$100,000) contracts to build applications using Zope.
1. ZC's engineers know the code better than anyone else, giving them an edge over other contractors who do Zope.
2. There are no direct competitors involved, but customers and community members alike ensure that Zope supports standards (WebDAV, XMLRPC, etc).
3. Several major features of Zope were developed by community members, then adopted into the core. This led directly to some of the authors joining the company.
4. ZC was originally Digital Creations, Inc. They finally changed their name because the association was so valuable. Most of the community called the company "Zope" already anyhow
5. The fact that every single dollar of a contract with ZC is spent on custom development, and none on licences, is a *huge* marketing advatage.
6. If ZC hadn't made Zope Free, they would never have been able to compete with the likes of BEA and Vignette. The Zope community, and the fact that Zope solutions don't depend on ZC for maintenance, put Zope in a league that no penny-ante proprietary startup could reach.