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."
Debugging is always faster when you have a bunch of viral Linux commune hippies on the job!
In Soviet Rush, today's Tom Sawyer gets high on you.
That's why style(9) was created. Do it one way, the right way, MY way. ;-)
(Also, ask all of your contributors to send patches in your style. If you are the main coder for a project, that is an easy thing to handle. If you are part of a team, have the team code in a particular style. Doesn't matter which one, as long as you guys are consistant.)
> 1) With enough eyeballs, all bugs are shallow - someone will know the answer, or stimulate the person who does.
> 2) Users provide better bug reports including line numbers, decent config information, possibly even patches.
As a part of these phenomena there is the direct interaction between the user and the hacker. A nobody like me can post a problem to the LKML and get a reply from than Alan Cox suggesting things to try that will give him more information about the bug. Or can post something to some project's bugzilla site and as often as not get a response from the lead developer on the very same day.
Compare this to the "help" desk bureaucracy for the typical CSS application, where they whole setup is arranged to buffer the developers from the people spotting the problems.
Sheesh, evil *and* a jerk. -- Jade
I have to concur with this. My day job is working as a "Software Analyst" -- in short, I get problem reports that our setup folks can't figure out and I solve them. This usually requires a lot of digging through code.
Just this week we've had a major problem with one of our customers: IE is continuously crashing (an internal IE problem). It doesn't help that the customer isn't very good at giving us detailed information about who it happens to when, but what makes it even worse is the cryptic nature of the error information from IE and the fact that we have no access to source code.
On the other hand, much of our newer products are built on top of open source tools (which saves us an extreme amount of time). The few problems that we've had have been relatively easy to fix due to the more open nature of source and documentation with the OSS tools and services that we use.
~Dalcius
Rome wasn't burnt in a day.
Your "untold number of eyes" is nearly indistinguishable from "0" unless your open source project is widely used.
In other words, he is no worse off writing open-source software than closed-source. Most closed-source software is only checked over by one person, the one who wrote the software. At least with open-source there is the potential that other poeple will get involved with the project, with closed-source there is no potential.
Sounds to me like you're working with an inadequate number of testers, or at least an inadequate unit testing plan for developers
Most corporations, don't have quality testers and will not spend the money on them. Usually they roll it out to a limited number of users, who will HAVE TO USE THE PRODUCT and that is the test bed. That does not make them eager or exceptional or effective. At least with open-source, if someone is interested in a project they are usually eager to contribute, either by coding or testing, more so than someone who believes that it is an extra hassle to their regular job.
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.
Most closed-source products will not even acknowledge that they are fixing bugs, they have spent their money for development, got their money from the customer, so they are done as far as they are concerned. The programmers have moved onto the next project and the customers are just screwed. At least with an open-source project progress can continue alibi slowly if at all. However, someone to pick up the project and run with it.
While most open-source projects will not go anywhere, they always have the potential, closed-source projects have no potential at all. Once the company is done investing money into it, it stops for basically all time regardless of how good or bad it is.
I then boot to Linux and port my code. I've been writing portable code for half a decade, so I know what I'm doing, more or less. But, I can get more work done with Visual Studio, faster.
In case it makes a difference to your perception, I write end user apps, sometimes with heavy graphics requirements and GUI frontends.
Due to the nature of my work, I can't rely on masses to test everything before I ship.
Many eyes can. How many actually do? Unless you're talking about the really big projects, probably very few indeed -- one, I suspect, in many cases.
Dispite the fact that the topic of this article is stupid I would have to disagree with your claim that the "many eyes" statement about OSS is a myth. I run a medium sized OSS project and only a very select few have ever contributed any worthwhile code but what is usefull is that occationally someone finds something genuinely important. A bug. A simple code change to get around a problem. Etc. It's actually one of the few things that I think isn't a myth about OSS. That and the benifits of having a large base of users against which to test the code. That's the real benifit. It's the claim that OSS projects benifit from many different code contributors that is a myth. I reject a lot of code that I'm sure would have otherwise been accepted other maintainers. It's the patchy collage of code that becomes a spineless inflexible blob.