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.
And herpes leads to open sores. And thus the cycle continues.
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
Not only that, but I'd like to see projects that have deadlines that HAVE to be met, as opposed to your hobby code that's finished when its finished.
I'm working on a closed source project -- a vendor product with a huge amount of customized code -- that has some hard deadlines: first release for testing by mid-August; pilot by mid-September; general release by November 1. Except that we ran into problems getting the team up to speed, so we cut the scope of the project, and decided to skip the august release. And then we ran into more delay and we moved the pilot to the end of September. Then we decided to push the pilot to mid-October. Now we are skipping the pilot and going straight to general release in November.
I can hardly wait for the cries of incompetence, but I respond with the real-world: lay-offs happen. Or key people get new jobs. Or reorgs interfere. Or the business users change the scope (find me a company where business users are ignored). I have as yet to see a plan that accounts for all of these items.
I've worked in large corporations since 1993, as both a programmer and tech lead, with mature and immature development teams. Development is about negotiation. Dates and deliverables are constantly re-evaluated. If a project date can slip then it will slip. If the date is hard, then the scope is cut. In other words, closed source projects are finished when they are finished.
The welfare of the people has always been the alibi of tyrants. - Albert Camus
This is probably the most profound statement about OSS I've seen in this discussion.
OSS projects are not better because the coders are more talented or devoted than closed source projects. They are better because they actually have QA resources that cannot be matched by close source projects.
Yes, but on the flipside OS software is like a box of chocolates, you never know what you're going to get.
Without reliability, business won't endorse open source software. So what ends up happening is you have hundreds of so-called "advanced users" who are basically hobbiests with a sense of adventure spending thier time using faulty software...so that eventually the rest of us will get a useful product. Sure it's thorough, and the bugs do get found...but there are side-effects to this.
For a lot of us who were using Mozilla in the beta stages, it was a complete mess. I remember one bug that was just so rediculous it rendered the entire browswer unusable. As I recall the only way to type a URL into the browser address window was to doubleclick on the text, and hold down the mouse while typing the URL. It was maddening and I stopped using it after a few days. The bug was addressed, and fixed in the next version. But it wasn't for another 8 months(long after the 1.0 release) that I picked up and tried mozilla again.
The point is, I wanted a web browser, not an adventure. Most users want things they can trust. They want working e-mail, office applications, web browsers, etc. Businesses are even more fickle about this. In a business environment software has to be reliable or it could end up costing millions, there is just no room for "software speculation".
OSS projects like Apache and the Linux kernel are stable because they have enjoyed years of meticulous care. I say care because in those cases the user and the developer were the same person. But where are you going to find daring OSS beta-testers for office applications and enterprise level software? These are products that need to work now. 5 years of screw-ups may produce a good product in the end...but most companies can't afford those 5 years.
The government has a defect: it's potentially democratic. Corporations have no defect: they're pure tyrannies. -Chomsky
You're a new coder, aren't you?
In most industries the QA department is a joke. A really bad one. QA is the last thing budgeted and the first thing cut -- because when you have a deadline to hit management always thinks that QA is superfluous. I've heard VP's state that it's better to have a buggy product out than no product at all. And the VP in question really didn't care just how buggy it was. With that kind of attitude toward release quality QA can be viewed as nothing but an impediment to getting product out (and, to be fair, some QA departments do view that as their job - preventing anything from being released). So some QA departments just rubber stamp things instead of doing real testing.
On top of that getting good QA people is extremely difficult. A good QA tester has to have enough technical expertise to design test programs, methods, and sets themselves (having the coders do this defeats the purpose of QA), but doesn't want to be a coder fulltime. That particular combination of abilities and desires is very rare indeed.
Finally, and perhaps worst of all, a good QA department is invisible. If QA has done their job then there will be minimal complaints from end users -- sure, there will be issues, but nothing huge. When you never have any huge problems, management tends to forget that it was QA that caught those huge problems before the product shipped.
Where does QA work? Usually in industries like Aerospace, Medical, telecomm, and power generation -- industries which don't have a margin for error. They have decades old QA practices that often got instituted the hard way. They also have relatively little competition and insanely high development costs.
Frankly, OSS does a far better job of QA than most closed shops, because the QA team is not paid by the same company/group developing the software. So there's no incentive to not report a bug, but there's also no incentive to block release -- if a major bug is revealed then Joe Blow user isn't going to get fired for failing to find it.
Oh, I'm sure you won't agree with me. Get another decade or so of experience in the real world and I suspect that you'll think differently.
I think that you make a good point:
The microsoft products are more complex.
The open-source products are less complex.
I'll have to agree with you on the complexity level.
However, this is most likely due to the microsoft vs unix way of doing things. In unix, a lot of little programs accomplish a lot together. In the MS world, a few monolithic programs accomplish a lot together.
So, taking program to program, the MS ones would be most complex, since they try to put everything and the kitchen sink in every single one of their flagship products.
And so, consequently, these monolithic multi-million code lines programs are more difficult to design, engineer, maintain, and debug.
But there are fewer of them, so more resources (programmers, program managers) can be assigned to each.
In the unix world, there are many more programs. And while each of these programs individually may be less complex, less encompassing in scope, and have fewer features, as a group they are able to outperform microsoft's systems.
Since each program is smaller and more easily defined in scope and requirements, then each program takes fewer programmers to design, implement, and maintain. As a result, it is possible for a smallish dedicated team to design, implement, and enhance a valuable and usable piece of software.
For example, I was surprised two years ago to find out that the core team of Postgresql is relatively small (currently the steering committee and major developers combine to less than 25 people) and yet it is no small feat.
For the unix world, the difficulty comes when there are a great many programs in use that have been developed over the years by different groups of people with different methodologies. These programs must work with each others, store their files in known locations, etc. This is especially important in linux, because there are so many more programs (including multiple guis) that need to share the same directory tree, and each have varying degrees of dependencies.
So the complexity still exists, it just falls outside of the program itself, and is rather a product of the environment.
Of course, having had my share of windows dll hell, I realize the problem of software dependencies is OS-agnostic.
----
I think I'll get back to work now... Is it lunch yet?
"Piter, too, is dead."
Also note the fast, and in some cases parallel development of derivative products. I don't have the details, but there are a host of 'Gekko' based browsers, and the direct spin-off Phenix is proceeding very fast indeed. People are reporting it to be useable and fast at the 0.2 release.
There is one issue to worry about (from the paper). One hypothesis is that if a project doesn't achieve critical mass, it won't get enough of a user following to get the many eyes effect. I suspect that this may be weakened by a number of factors. Even if a project doesn't acheive critical mass, it may be reworked in another form because the code is still available for experimentation.
This study is bad because it only considers the two most successful open source projects.
p df
2 /0 6/05/1530208&mode=thread&tid=156
A more complete study of the top 100 most active projects on SourceForge comes to a completely different conclusion:
http://opensource.mit.edu/papers/krishnamurthy.
This different paper was discussed on Slashdot under the topic "Open Source Developed by Individuals, Not Large Groups", submitted on June 5, 2002. Here is the URL:
http://developers.slashdot.org/article.pl?sid=0