To read all comments associated with this story, please click here.
Without arguing for either side of the fence. The argument goes that more eyes make bugs shallow. More people read and check prominent code from open source projects, so there is a higher probability to find bugs.
Of course, in practice it highly depends on the project. While "the more eyes make bugs shallow" mantra works for open source projects with a high number of developers, it may not apply to projects with few developers.
Additionally, it should be pointed out that Coverity's software does static analysis. It does not uncover (security) bugs that can not be detected with static analysis.
Of course, in practice it highly depends on the project. While "the more eyes make bugs shallow" mantra works for open source projects with a high number of developers, it may not apply to projects with few developers.
I would say the results support the "more eyes" argument. The active projects with many contributors (like the linux kernel or libc) have far fewer than 1 bug/1kloc. Of course without a comparison to a comparable closed source system it's difficult to tell whether that is a good result or not.
That statement is fine and it was created by Eric Raymond. I disagree with it. Performance bugs, bugs that cause software not to function properly sure, the statement holds water but if security holes were the same then that test would show NO security holes in open source software. Coding with security by design takes a specialist, someone who knows what they are looking for.
You may argue that Linux and Open Source are superior to proprietary software security wise. It may have that perception but look at the userbase, or lack of, and the fact that Linux "inherits" a lot from UNIX which was a system designed from with security in mind.
What I find interesting is how this is labelled news when it is confirming what is common knowledge.
The issue isn't necessarily the number of bugs but the speed in which they are fixed, the speed in which the fixes are made available, and when there are security issues, the speed in which structural problems are addressed.
Anyone remember around 2 years ago KHTML went through a spate of security problems so over Christmas one year, one of the developers (on his holiday) did a complete code audit there were some development procedure changes etc. etc. lets remember, these weren't serious security issues, but the developers were proactive enough to bite it in the butt before it became worse. Here we are, 2 years later, with a very secure and stable KHTML/Webkit.
The problem is, however, is that many companies don't want to do the above; what is easier - fixing a problem correctly which might set them back several thousand, or simply continuing to patch which is cheaper (but later offset by a buggy, complex, ugly code based to maintain)? that is the issue at hand.






Member since:
2005-07-06
Award me a captain obvious tag, but did you really think there would be much variation in code quality between closed and open source?
Morglum