Slashdot Mirror
Open Code Has Fewer Bugs
ganns.com writes "Reasoning, which sells automated software inspection services, scrutinized part of the code of Linux and five other operating systems, comparing the number and rate of programming defects. Specifically, Reasoning examined the TCP/IP stack and found fewer errors in Linux. 'The open-source implementation of TCP/IP in the Linux kernel clearly exhibits a higher code quality than commercial implementations in general-purpose operating systems,' the company said in a report released last week. Reasoning also compared the code with that used in two special-purpose networking products and found it superior to one of them."
How about using a larger sample of code before making such bold statements. It's probably true that the code has fewer bugs, but when you abuse statistics it just makes things look dishonest.
Over time, successfull open source projects which address a particular issue will most likely have fewer bugs; just being open source doesn't mean fewer bugs (or better software). It just means that it has a better chance, if it survives, of being better software.
"What we have here, is a failure to communicate." - Cool Hand Luke
The attitude I've seen in the corporate world is that open source products are made by amateurs and is therefore in some way not blessed by the magical corporate coding fairy which makes all the shit churned out by corporate code shops stink less. This attitude is arrogant and does not take into account the simple fact that all those people who got into programming just for the money tend not to work on open source products. When you've got code that is both written and reviewed by legions of people who love to code and who find good computer programs to be beautiful, you're going to get better code.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
The more points of view you apply to solving a problem, the quicker, and better you'll solve it. The beauty of human reasoning isthat no two people will view the world in *exactly* the same way, therefore each one of their respective paths to the solution will be different...Travelling that path to one solution can, as we know, lead to other SOLUTIONS to other PROBLEMS.. The more heads that work, the more solutions discovered . . and so on..
Open Code Has Fewer Bugs
The study looked at a single part of an operating systems (TCP/IP stack) and then the posting made a very general claim about open source software. This is cheap engineering (a.k.a. bad science). Period. You need a much larger sample to make such a claim. A single data point is meaningless. In fact, I believe that code bugs are much more a function of programmer performance and code complexity than open vs. close source development model. Opening the code may have a positive impact, but it is not the major factor to consider. The last thing Open Source needs is this kind of marketing strategies...i think the enjoyment is also important.
take 2 people that have the same skills, one enjoys a complicated task, the other does not. more than likely the result will be better by the person enjoys it, because they will show more care.
Severity of bugs is more important that number of bugs. I could have a program with one bug, doesn't work. And you can have two bugs, feature broken and memory leak, but it works. Who is better?
I also like the assumption in the title that because linux was found to have fewer bugs than some other OS's that open software in general has fewer bugs. Take a look at some of the bug lists on sourceforge projects and tell me that again. Number of bugs varies by project, not by open-ness.
The GeekNights podcast is going strong. Listen!
Why did they test only one free software kernel while testing four proprietary ones? I'm not saying that if, say, a *BSD kernel was used, the results would necessarily be something else, but making general statements of open code by examining only one open project is certainly not very accurate. Although I suspect that these inaccurate conclusions are more in the Slashdot side than in the study.
They chose the TCP/IP stack. That is almost certainly the best tested of all the components in Linux. It is used by everyone, so the eyeball count is particularily enormous.
If they would compare the implementations of something less popular, the numbers MIGHT be different. x.25 or something.
Stop the brainwash
The code for the shuttle's GPCs is closed, and it's regarded by many as probably the most bug-free code around with any degree of complexity. It's been upgraded several times since the '70s, and rarely have errors been found.
It probably had one of the longest development times for its size, too. Which helps a lot.
Quality has nothing to do with whether code is open or closed source. It's got everything to do with the environment in which it was written. Code written under extreme management pressure from a profit-hungry megacorp is just as bad as code written by an ignorant or uneducated dork in his basement.
Specifically, Reasoning examined the TCP/IP stack and found fewer errors in Linux.
So they just looked at the code and found all the bugs. They must have the best programmers in history working for them if they could just look and find all those bugs that it usually takes years for mortal programmers to find.
Depends on how the source-tree is managed...
Too many cooks spoil the broth!
TCP/IP is better on linux because many very talented people have worked on it. This is an area in which open source software development has worked well. However, it does not mean that open source developement always works better.
The code I write for myself is the cleanest stuff in the universe. I get freaky about extra lines or lines that look "ugly" or inelegant.
.024 euros.
Now when I'm at work I toss out functional, ugly code. Doesn't work quite as well, but 90% of the users will never know that. I'll write catch statements for the most obvious errors, but I don't sit and brood about what some hypothetical idiot might want to do with the code. If there are enough people who hit an error there, I patch it, and move on with my life.
By and large, high production commercial code is sloppy. There isn't any profit to be made in making it pretty or elegant, and we all know how (for a random example) MICROSOFT feels about profit.
Open source is just the opposite; if you're not making any money on it, you're doing it for your own personal satisfaction, and I think most people find it more satisfying to have clean baddass code, rather than sloppy junk code. Heh. Especially when your NAME is on it, and the SOURCE is available.
Just my
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Reasoning "sells automated software inspection services."
The key word here is "sells." They would have a tought time selling this to open sourcers, what with everything wanting to be free and all. Instead, they show the big closed source companies that their code isn't nearly as bug free as the open stuff, therefore they really need to buy this.
I'm not denying that open source is less buggy, but always question the motivation of the company making the claims. Just because Reasoning's assertions fit your own neat world views doesn't mean that they are without bias or secondary motivation.
Do not taunt Happy Fun Ball(TM)
Actually, you've inadvertantly stumbled upon an excellent point.
No code is perfect to begin with. The BSD stack is still improved from time to time. The BSD stack that companies folded into their code years ago has since had some major changes and the companies haven't bothered to take many of those changes into account.
Had they been required by license (GPL) to keep the code open, then it could be fixed by other people. Instead, the implementation has languished. This in fact is one of Stallman's great resons for keeping all code free.
However, the reality of it is that our current environment still favors closed source software. With any luck, people will slowly start to wake up and realize that source code needs to be open for all software projects. Think about it. If it was normal to receive source with binaries, nobody would really think twice about it. It's only seen as a bad thing because it's not what Microsoft does. But the reality is that Microsoft has a business model that works well for them, a giant monopoly. The reason their competitors fall on their asses is because they are trying to play as if they were MS, which they are not. It's not impossible to compete with Microsoft, it's just impossible to compete head-on.
>So much open source software tends to be writter by students with little experience and it shows.
You mean it's been written with the latest design and coding ideas, to a high quality, tested, documentated and above all written by someone who cares about the program, without the bother of office politcs?
I agree!
Comment removed based on user account deletion
Not just that, but anybody will tend to produce a higher quality product when they aren't being badgered to meet deadlines and being dragged into meetings every other day.
Mmm, troll! Just what I always wanted.
Let me tell you -why- I wouldn't choose any of the below that you've mentioned:
1) Gentoo. Well, on principle I like the idea, but in practice it's a pain in the ass. Having to wait around for hours on end just to have the latest version of KDE compile isn't for everybody. On top of that, there's very little hardware detection, if any. The elitist response to this complaint, I suppose, would be that it's more "configurable" that way..well why not offer two installation modes, the configurable one and the sane, easy-to-use one? Seems like the despised Windows, MacOSX, and yes, even Redhat seem to have that working pretty well for the most part.
2) Debian. I like the packaging system, but other than that there's no reason for me to use it. Redhat 8.0 installed in 20 minutes, and at that point I had a fully usable system. Sound worked, graphics worked, I didn't have to touch any configuration files. The last time I installed Debian I had to recompile the kernel for support for a number of pieces of hardware I had, and I never did get 3D acceleration working properly. If I wanted to use packages made in the last 1-2 years, I would have had to use the "unstable" packages. I wasn't really keen on that, when RedHat provided everything that I needed.
3) FreeBSD. I have no problems with FreeBSD..my first webserver ran on it. I wouldn't use it for a desktop, however, which is my primary usage for a system, simply because it barely supports any of the hardware I have. If FreeBSD supported the same amount of hardware that Linux did, perhaps even with auto-detection similar to RedHat or Knoppix, I'd probably use it..and I bet a lot of other people would too.
The wonderful thing about Linux distributions is that there are many of them. There's ones for people who want to spend their time messing with text files to get their hardware set up properly, there's distributions for people who just want a stable, fast operating system that they can get to work with quickly. Perhaps that does make me a "User," if by definition a "User" expects a certain amount of the work to be done by the operating system, and not themselves. In that case I'm proud I am a "User," as the prospect of being a "Real Geek" sounds monotonous and time-consuming.
"Reasoning examined the TCP/IP stack and found fewer errors in Linux" The TCP/IP stack in Linux (and for that matter, most operating systems) was borrowed from BSD. Shouldn't this comparison be a testament to quality BSD instead of Linux? Paul Zimmerman http://zimmermantech.com/webcam.htm "Comments should be like skirts - Short enough to keep your attention, but long enough to cover the subject"
Listen to Live FM Radio
While the commercial OSes derive from BSD code, it is not the same thing. Related to that, there are three sources of bugs that Closed OS's will have but Open OS's will not. 1) Errors in the derivation of the BSD code - that is they generally have to make minor changes in the BSD code to get it to work with their product. 2) Bugs in the Non-BSD code that is wrapped around the BSD code. 3) Errors found in the BSD code after the Closed code was written. Usually the closed Os will NOT upgrade the BSD code for a bug found in it because either 1) they are lazy, 2) they are ignorant of the bug, or 3) doing so would require a re-write of the Non-BSD code.
excitingthingstodo.blogspot.com
"You mean it's been written with the latest design and coding ideas, to a high quality, tested, documentated..."
I have to respectfully disagree with you that this is a good thing. All too often students will learn a new design or coding idea and want to apply it even when it is not neccessary or the best tool for the job. Furthermore, students, in my experience, are way too ambitious to test much. The just want to code, code, and then code.
Finally, have you read much of the kernel? Documentation is sparse (though getting a little better in 2.5.x).
Office politics no. Dorm politics - e.g. my stack is better than yours? Maybe.
Holy s-, it's Jesus!
So why should any of this article be a suprise or even particulary note worthy?
perhaps because when large numbers of people are uneducated about something they use and make daily decisions about, it is shocking to them to learn that their assumptions (probably brought about by marketing) are erroneous.
Other notable, and obvious "surprises" in research:
-Two parents are better than one.
-More concealed carry = less violent crime.
-You are more likely to get sick at a hospital than at home.
-Breast milk is better for babies than formula.
A lot of money and time have been spent researching these topics, only to find what many of us already knew to be true and obvious.
Not everyone is educated and experienced in everything, and it can be painfully difficult to dissuade people of their delusions. Especially when they've been formed out of ignorance.
begin troll
This may be another feather in the Open Source cap, but I wonder if Open Sources is a good thing in the first place. Think about it for a second. Linux replaces Unix in the server world (which is happening). Companies that make closed source Unix OS's lose money, then they fire people. Company's get used to not paying for software so they start using Open Sources more. More closed source companies lose money, more fire people. Just something to think about when your hacking away at your latest kernal patch. You are writing software so companies can spend less money, executives can give them selves big bonuses for saving money, and vendors can fire people. I'm a consultant for big companies, I've seen it, it happens.
"Failure is not an option, it's part of the standard package"
You mean it's been written with the latest design and coding ideas, to a high quality, tested, documentated and above all written by someone who cares about the program, without the bother of office politcs?
I agree!
No, I mean it's written by people without experience architecting large projects, so the result is verbose, brittle, and messy. Period.
"Coding for the end result = quality"
Too bad that quality doesn't always bubble itself up to the UI. That's probably my biggest complaint about open source software is that few ppl actually put serious thought into the UI design. It starts off as a utility written to solve their own problem and eventually it becomes useful enough to share with ppl. VirtualDub comes to mind. Kick ass prog, hardly intuitive in terms of UI.
The answer is simple. They often do force you to half ass, cut corners, or even write to a horrible design created by someone with no idea what he is doing. So often I have seen commercial software that I myself have worked on go out in deplorable states due to deadlines, budget reasons, or just plain bad managerial decisions, forcing the coding to be horrible, sleep deprived, and poorly debugged. Last time I checked, I don't have a deadline on my personal projects, therefore I can spend all the time I wish to obsessive-compulsively making sure everything works exactly how it should. It's not a matter of willful half-assing, it's a matter of circumstantial half-assing. Excuse or not, the fact is that quality comes from having both the time and the freedom to do it right.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
It is natural for open source projects that survive to become very high quality. Look at it this way: If you buy proprietary software from a corporation, you can be sure that they are motivated by the bottom line.
Corporations are there for one reason only: profit. This in itself does not mean that the products that they put out will be inferior. However, being motivated by profit means that:
1. They will push their employees to put out a product quickly.
2. If a product has flaws, it is the bottom line that dictates the priority given to fixing that flaw.
Open source on the other hand is completely different. Although it can be motivated by profit usually it is not as much. A lot of people do it because they just want to do it. This in itself does not make open source less buggy. I would say that most young projects have as many or more bugs in them than proprietary projects.
However, if the projects live for a long time it is because dedicated coders have decided to spend their time improving the product. This dedication over a period of time without the pressure by management to quickly push the product to market is the reason that open source becomes better than proprietary software.
The race isn't always to the swift... but that's the way to bet!
The old saying about "many eyes makes all bugs shallow" is true even for propeietary code. I have been working on proprietary software for most of my career. My own opinion is that software made by companies with collective ownership policies is of better quality than software made by companies which allow for individual ownership.
At some places where I worked, some people just "owned" some of the source code and for whatever reason, nobody else was allowed to touch it (or sometimes even see it if the boss owned the code). Anybody else who wrote anything dependent upon that often found a lot of bugs in that code, and just had to wait until so-and-so got around to fixing it. Some of eventually wrote a replacement for that whole component, and obsoleted the original.
At some places where I worked, and at where I am now, the rule is that we all own the code collectively. Sure, there are some people that better understand some parts of the code than others, but nobody tells anybody that some code is off limits. It is easy to just go in to some section of code, fix the bug, and move on.