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."
But bugs are cool..does that make me a geek for using Redhat?
I guess it stands to Reasoning that more developers hammering on code leads to fewer bugs. :)
Companies such as Oracle and Microsoft typically sell binaries incomprehensible to humans rather than the comparatively understandable source code.
After seeing this, I think that statement is being a bit generous
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
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.
Pope is catholic
Bears are found to sh*t in woods
Free cell phone tracking
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
Open source has fewer bugs.
Bill Gates: bugs are cool.
Ergo, open source is not cool!
Really? But I thought most commercial OSes derived their TCP/IP stacks from BSD code in the first place. And since BSD is open-source, shouldn't these commercial OSes show roughly the same level of quality then? Or are they arguing that the Linux TCP/IP stack is superior to the BSD one?
Cheers,
Ian
Reasoning, which sells automated software inspection services, scrutinized part of the code of the Linux and five operating systems,
Including the Solaris, the Windows, the AIX, and the HP/UX.
I want to drag this out as long as possible. Bring me my protractor.
I find the fact that they did not say what OSes they compared to be very... suspect. What about Mac OS X, FreeBSD, and other open source OSes that have Open Source TCP/IP implementations in their kernels? Since they did not say what OSes are being used...
"Reasoning declined to disclose which operating systems it compared with Linux, but said two of the three general-purpose operating systems were versions of Unix."
How lame. For all we know, they could have tested the Amiga OS, Mac OS 9, Windows 3.1, A/UX, and NeXTStep! Other than this, the article is pretty vague and does not seem to give me much meat on the subject, nor a link to the study (you have to go through some forms and give up personal info to get it at www.reasoning.com).
Conglom-O: We Own You (TM).
Most cryptographic algorithims do not gain acceptance without being open to peer review to spot flaws and potential weaknesses...
So why should any of this article be a suprise or even particulary note worthy?
--- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
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...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.
'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,
Well of course it does! The Linux and BSD IP stacks are benchmarks. This is where practically all protocol research happens - how would anyone be able to verify your results otherwise? Furthermore, only the free stacks are useful for compatibility testing because they are so configurable.
So obviously it stands to reason that this code is much more complete and bug-free than any commercial implementation. THOUSANDS of people are studying every single line of this code on an ongoing basis.
I've worked on a number of commercial IP stacks - some from scratch, and some based on Linux. Any IP stack written from scratch is understandably simpler, but it's not that hard to implement the essential RFC requirements (i.e. the "MUST"s) and make it stable. Now, making it FAST and making it use all of the bleeding-edge TCP stuff... that's another story. Only Linux/BSD are there (and of course any other OSes which use their stacks).
Well ya know you can either go on cursing or upgrade...
"Mozilla 1.2.1 was released to correct a DHTML bug in Mozilla 1.2. The only difference between the two releases is the fix for this bug (Bug 182500). If you have already installed Mozilla 1.2, you should upgrade to Mozilla 1.2.1. "
yours ever, fz.
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.
Much more interesting would be a code comparison between open source samba and the micro$oft CIFS code..
Before we begin the bashing, let's note that two flavors of 2.4.19 were compared to two closed source Unix operating systems. Let's try to keep the evil empire out of this one!
Put identity in the browser.
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.
If they found 0.1 errors per 1000 lines of code, did they approach Linus and Co. to point them out? Has Reasoning submitted any kernel patches to address the errors they say they found?
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
Were they testing code from 7 years ago?
Can't you see that everyone is buying station wagons?
Microsoft pinched their TCP/IP stack from *BSD
Not exactly true. I can't find the link off hand, but I read an explanation of the background to this myth quite recently. If you Google around you should be able to find it.
Back when MicroSoft were keen to add TCP/IP support to Windows, they contracted another firm to to do the work. That firm took the BSD licensed stack (from 4.3BSD as I recall), and did tyhe necessary porting work. This they then delivered to MS, meeting the original deadline. Since then, NT has gained a new TCP/IP stack written from scratch by MS engineers.
As a result, the TCP/IP stack currently used in Windows owes little or nothing to the BSD implementation.
Chris
in other news....duh
Yup. Note that this doesn't tell you anything about the overall quality of the software, though. So much open source software tends to be writter by students with little experience ("this was my first large project") and it shows. Just because other people find and fix the bugs doesn't change this.
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.
What I am wondering is which is the cause and which is the effect:
Microsoft source code is defective because it is closed.
Microsoft source code is closed because it is defective.
now we need to go OSS in diesel cars
There is also an article about this here.
They not searched for any kind of possible bug, the article says specifically what they were looking for:
Reasoning looked for programming problems such as memory that was marked as free when it was in fact still in use, memory that was being used without being properly initialised, and attempts to store data that exceeded the space reserved for it. This last problem is often associated with buffer overruns, a major weakness that under some circumstances can let an attacker take over a computer.
>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!
Now if they could please point out the filenames and line numbers in question, perhaps we could eliminate the bugs altogether...
Comment removed based on user account deletion
"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
This is still an argument for the open source method, but I think that the code quality should be attributed to a different source. Perhaps it is not about an inherently good or inherently bad method. What if age is the key factor?
The Linux networking code has been in for a long time. Not in it's present form, obviously, but each change builds on the last; as it must in open source - it would be foolish to start afresh when you have something that works. So a cylcle develops and at each stage the code gets better. Compare this with proprietary; can they look at a competitors code? No. They must start afresh and so their code is effectively younger.
Further, if we measure software age not in units of time but in units of updates, open source has the advantage that there are many updates, there is always someone new to look at the code. No company can compete with the sheer quantity of viewings and therefore updates that occur in open source developments.
Carpe Daemon
"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!
that MS code is just as good as code written by an ignorant or uneducated dork in his basement.
He'll probably have his mom sticth it into a sampler he can hang on his office wall.
(Of course, personally, I don't think it's true. Bill has the resources to throw at code to make it much worse than any single dork can, but that's just my opinion)
KFG
Hmm..
Say you have a load of CS students, and some of them code OS programs for a hobby. Now intuitively the ones who code for a hobby are more likely to be better coders than the average CS student.
When the hobbiest-student-coder has to do his 6 month computing project (I assume that most uni's have similiar projects - or at least some coding projects) then you have to produce plans and documentation etc for it. They are also far more likely to make their said software open source.
When in the work place, then you have all the coders together producing code - resulting in a lower average quality of code.
I'm obviously making some assumptions here, but you get my point..
Btw, as for kernel, it's not quite so clear cut. I do not dispute that there isn't enough documentation, but sometimes people take up issues in the wrong places.
For one example, when AA wrote his memory manager, and non-coders complained and booed because it wasn't documentated. One big reason for this was that the algorithm used was a standard well documentated algorithm, and anyone that understood the algorithm well, would be able to easily understand the code.
Anyway, I have a quantum computing lecture to attend.. bye!
Two key points are that (1) most of the bugs Reasoning found are false alarms (which is an occupational hazard for this kind of analysis), and (2) one reason Linux does so well is that those lunatics at Stanford have been doing just this kind of analysis for quite some time, so most of the easily-found bugs were found long ago.
This doesn't invalidate any of their conclusions, of course: the Stanford lunatics haven't been analyzing NT, they've been analyzing Linux, and for sound academic reasons.
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.
... so with the luxury of time, it _should_ be less buggy.
I don't think releasing the source is necessarily a good thing for a commericial app. How would you control updates and mods? Where would the configuration control come from? I just had my first encounter with CVS at Sourceforge. _NOT_ straightforward. I don't think you could scale that up to a million purhcasers.
"Consensus" in science is _always_ a political construct.
By the same token, the more managers you haven the better is your work ?
People coding something because they want to (and because they need it for something for themself) leads to better code. I know when I do something for myself, I don't half-ass it.
Coding for the end result = quality
Coding for a living = paycheck
Any questions?
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
Open Source is still largely deveolped as a hobby of enthusiasts. Some companies have their hands in the pie too, but even the resultant effort seems to be more in the style of the hobbiest than of the typical company effort.
Two factors. When I develop closed source apps for work, especially if it is something I have no real passion about, I tend to have messier code. No one is going to see it anyway. If I ever change jobs, a potential employer isn't going to ever see that code to review my style. If no user or the community in general will not see it, I'm more likely to take riskier shortcuts and settle for inelegant hacks. As long as no obvious runtime problems occur, then it is enough. When I submit patches for open source applications, I take more pride in the work. I want it to be clean, easy to read and follow, and free from amateurish looking code.
Secondly, even when I would like to re-evaluate approaches I use in a commercial environment, the business end of things will push deadlines. Time that I would have normally taken to go back, clean up, and rework the bits that work, but are too inelegant is denied. There is a significant amount of care with respect to market trends, customer demands, and marketing promises that interfere with quality code. With open source, you do it as you feel like it. Take as much time as you want. Sure, there are frequently deadlines in large projects (feature freeze, etc), but the penalty for not being able to meet those deadlines just means your work will be delayed to the next release cycle. There is no danger of losing your job, and even if consistantly missing feature freezes means you lose cvs write access, or are not taken as seriously, it really is no skin off your back, and you can almost always get back in through picking up the pace again...
XML is like violence. If it doesn't solve the problem, use more.
The Linux IP stack is a complete rewrite and doesn't derive from the traditional BSD sockets code at all. In particular IP packet formation between Linux and BSD is completely different. The header and tail portion of an IP packet is handled in a single pass through called an "sk_buff". In BSD header and tail formation of the packet is handled in two passes, one for the header the next for the tail, in an "nbuf". The BSD protocol implementation is traditional and the one described in TCP/IP Illustrated, while the Linux implementation is completely new. I believe that one positive feature of the Linux implementation is that it has allowed for zero copy networking, though that's a limited benefit which is only of use to a very small subset of servers connected to very fast network links. A big positive of the BSD stack is that it's old, rigorously tested, and very well documented. Note that the System V Streams implementation is completely different as well, so Solaris and other SysV derived kernels follow their own method for packet formation. I make no claims that any of these protocol implementations are better than the others, only that the code base and history are completely different.
I've attended a few USENIX kernel internals courses but that's the extent of my competence (have poked through the source out of curiosity though). Please feel free to post additional information or correct any mistakes I may have made.
Cheers,
--Maynard
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!
There is a reason for this, which has nothing to do with PHB's attitude, but more wth the Grad's attitude that he thinks he knows it all.
As they say; Hire a student while they still know everything!
This post reminded me of a question I was pondering last week. What makes one software program better than another software program? Is there a way to quantitatively measure how good a piece of software is? Would we measure the "goodness" of software by, the number of bugs it has (or rather the lack there of), the number of lines it took to write it, how long it took to develop, the type of license (open vs proprietary), the efficiency (how long to takes to run), the language it was written in, ease of use, etc, etc, etc? My guess is we would have to come up with a convoluted mathematical formula to measure the goodness of a program. Anyone care to take a stab at it?
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.