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)."
One of the authors, Roy Fielding, is on the Apache Board of Directors. I haven't read the paper yet and I'm sure he can be objective, but still.
Does this make business sense? In a word,
/sarcasm ;-)
Yes.
Paying people to work on an OSS project is strategic for any business for the following reasons:
1. You get in on the ground floor. If your competitors have core developers on an important Open Source project, you are at a disadvantage. They will have intimate knowledge of the product, since they helped generate the source code. You, on the other hand will have to read and decode the source. You then spend more time - and $ - getting up to speed in supporting your end users. Having a core developer means you're that much closer to the information you need.
2. Standards compliance. If you and 2 or 3 of your competitors are all working on an OSS product, it will become a standard, since everyone has to agree on the functionality of the package. It is impossible to do otherwise. Basically, you all agree to detente - you permenately remove a weapon from the arsenal. This stops an expensive "arms race", and also means less things to worry about and/or reverse engineer. Interoperability is assured then, so it means $ can be spent in more constructive ways.
3. Wealth of focused resources. A compelling Open Source product will attract the brightest users who have a vested interest in your product. The quality of bug reports usually is better and more diverse. For that matter, the coders outside of your organisation also will have a vested interest in your product, since they aren't motivated by getting paid to submit changes and bug fixes. This means development is focused on getting the right product in user's hands - not what marketing thinks is the right stuff. The feedback loop from the field is much better. Less $ wasted on dead end products, or going down the wrong development path.
4. Marketing. If your organisation starts an OSS project and keeps/pays the lead developers, your name is attached to it, even if others contribute to the code. Everyone knows that JFS is and IBM product, as well that XFS is an SGI product. They just happen to be OpenSource. This doesn't result in tangeable $, but other things that can lead to more $ - like goodwill from the development community, end users and sometimes even (gasp!) your competition.
5. Undercutting the competition. If your OSS project provides the same funtionality as a competitors closed source product at the same quality level (most indications state quality will be above Closed Source), you've effectively removed most of the reasons that your competitions product will be bought. If you're paying 2 developers and have 10 other regularily contributing code an OSS product under the GPL, but a competing product needs 20 developers to code (and untold others to support the product and the codrs too), well the math is easy. Cut throat, but effective business strategy.
There are likely many other benefits that come from "owning" OSS code, but I'll stop here for brevities sake.
Soko
P.S. - I haven't listed the downsides, since we, unh, know there aren't any
"Depression is merely anger without enthusiasm." - Anonymous