Slashdot Mirror
Debugging in OSS Always Faster
dex@ruunat writes "Damien Challet and Yann Le Du of the University of Oxford studied a model of software bug dynamics, which resulted in a paper on cond-mat this morning. In this paper they study the difference in evolution of number of bugs in open and closed source projects. They conclude: 'When the program is written from scratch, the first phase of development is characterized by a fast decline of the number of bugs, followed by a slow phase where most bugs have been fixed, hence, are hard to find'. Another, perhaps surprising conclusion is that debugging in open source projects is always faster than in closed source projects."
Studies reveal that debugging is easier when you do not strip symbols from binaries!
There are no karma whores, only moderation johns
As with all statistics, you can make them say whatever you want...
Maybe most OSS projects are easier to debug because of lack of features, or smaller scope, etc.
What percentage of OSS projects, on say sourceforge.net, have a version number 1.0? (and are "widely" used). The first one that comes to my mind is MythTV and/or FreeVo. I can't speak of freevo, but mythtv (while being impressive) is still very bug ridden and has been out for over a year.
Another factor is the user group, of course. With OSS I imagine the kernel gets more bugs submitted by users than mythtv, just because the users aren't so much code hackers... they just want to use it.
The one rule in the software engineering is that there are no rules.
no comment
The paper's conculsion seemed to be that debugging open source projects is faster because you don't have a version problem where customers report bugs in code that has already been modified for the next version.
I don't buy it. Many open source projects (ACE/TAO, Mozilla) for instance have large customer bases using non-current versions, and presumably finding bugs. Sure, if you only want to fix the bug in the released version, its faster, but it's not like closed source vendors don't have the source code to their previous release to debug with.
Sure debugging is faster if you always make everyone upgrade to the latest version before filing a bug report. Good luck getting mass acceptance with that.
What do you want, Windows nightlies?
The very concept fills me with dread.
--
the strongest word is still the word "free"
This was a paper written for a class on statistics. It was not a rigorous study. Their findings are based on a lot of assumptions. They have a very small sample set--they only test their model on Linux, fetchmail, and Mozilla. Many people, including myself, consider these the cream of the crop so far as OSS goes.
Before you praise it, I urge you to actually read the paper. Don't be intimidated by it--FUD is FUD, even if it's mixed with a heavy does of greek letters and charts.
I do a lot of coding working mostly with open source products, and sometimes closed source. When I get some bug come up in an open source product, I actually go digging into their code sometimes to figure out what went wrong. If it's closed source I can dig down through my code, but once I hit their code, it's a brick wall.
Frankly this is why I try to stick to open source software when I do development work. Hell of a lot easier to figure out how something works when you've got code and direct access to the developers via a mailing list.
This sig has been temporarily disconnected or is no longer in service
Well, I think the explanation for this is pretty obvious.
If you've got open sores, you're going to want to get bugs off of them as quickly as possible. You're also going to notice sooner because it's still bleeding. If you've got closed sores, you might not notice flies buzzing around them near so quickly.
We don't have a state-run media we have a media-run state.
all the users use the modified code at time t + 1 and report bugs exclusively on the updated code.This assumes that all the users update their software at every release.
This is completely bogus. Not every user is going to update immediately. In fact, the larger the company is the less likely this is due to their desire to qualify new software. This means as Open Source gets more popular with big companies, the more bogus this assumption is.
The paper also mentions nothing about QA efforts or beta sites on closed source, which are typically on the "immediately updated" products.
I'm not going to argue whether oss is better/worse than closed, but I heavily doubt this paper proves anything other than if you make lots of assumptions you can prove whatever you want.
Your "untold number of eyes" is nearly indistinguishable from "0" unless your open source project is widely used. Sure, this may hold for the Linux kernel, or Apache, or even Mozilla, but what about all of the open source projects on SourceForge?
Sounds to me like you're working with an inadequate number of testers, or at least an inadequate unit testing plan for developers. Testers are invaluable because that's all they do -- test code. This frees up the developer to be able to actually write code while not having to sacrifice quality for lack of testing. Sure, it's more expensive to hire both testers and developers, but I'd bet that of your 30 or so developers, you could fire 10 of them and hire 15 testers for the same cost, and still have enough man power for development while increasing your code quality from rigorous testing. (Note: This isn't saying that developers can or should write bad code so long as they have testers. Developers should still aspire to writing quality code, so that the testers can focus on the really heinous parts, and not on trivial bugs or logic errors. But at least with testers and good unit tests, you're less likely to let slip a silly bug.)
That may be true in theory, but it doesn't pan out in practice. In practice, most open source projects will only be seen (code-wise) by the author(s). If you're lucky, you might have two or three active users that will submit bugs or patches, but often that's not the case.