Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology Science

Debugging in OSS Always Faster 297

Posted by michael from the bugging-also-always-faster dept.
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."
This discussion has been archived. No new comments can be posted.

Debugging in OSS Always Faster More

Debugging in OSS Always Faster

Comments Filter:

  • Possible explanation? (Score:4, Interesting)

    by Lane.exe ( 672783 ) on Friday June 20, 2003 @05:59PM (#6258095) Homepage
    Could this be because OS projects tend to be, on the average, smaller than closed-source?

    • Re:Possible explanation? (Score:4, Insightful)

      by SpaceLifeForm ( 228190 ) on Friday June 20, 2003 @06:06PM (#6258157)
      Not always. A more likely explanation is the 'many eyes' that can review the code.

      • Re:Possible explanation? (Score:5, Insightful)

        by athakur999 ( 44340 ) on Friday June 20, 2003 @06:16PM (#6258237) Journal
        Something else I can think of is that your testers have access to the code and can give you more precise bug reports than if they were doing traditional black box testing. Better bug reports and information means less time investigating.

        • That is a general insight into bug testing and perfectly valid, except your statement is a bit flawed.

          If the testers have some general coding and OS knowledge, they can help determine the fix before sending off an issue. It doesn't really matter whether the code is publicly available or not. Testers for non-open source projects can have access to the code as well. The code isn't usually kept in a vault with armed guards protecting it, you know. It is more a matter of having knowledgable and studious tester
          • I think he was refering to beta sites or tester, as in customers who are running pre-production code. In that case it depends on the relationship but most closed source shops do not share their beta code with their testers.

      • Re:Possible explanation? (Score:4, Funny)

        by Graspee_Leemoor ( 302316 ) on Friday June 20, 2003 @06:43PM (#6258419) Homepage Journal
        That explains why I debug so fast! I have many eyes. At last count I had 27! (Some of them are in the back of my head though, which means they can only debug things behind me).

        graspee

        • That explains why I debug so fast! I have many eyes. At last count I had 27! (Some of them are in the back of my head though, which means they can only debug things behind me).

          Well, as they say, hindsight is 20/20.

      • The "many eyes" myth (Score:5, Insightful)

        by Anonymous Brave Guy ( 457657 ) on Friday June 20, 2003 @08:11PM (#6258980)
        A more likely explanation is the 'many eyes' that can review the code.

        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.

        It's not fair to cite mainstream developments like Linux or Mozilla as the way all open source is any more than it's fair to cite Microsoft's history on things like security and reliability as the way all closed source is.

        • Re:The "many eyes" myth (Score:3, Interesting)

          by Ramses0 ( 63476 )
          I've looked at a surprising number of program's source code. abcde, www-mechanize, ode physicis libraries, perl stuff, php stuff, python stuff, parts of the ogg utilities. Mostly because it doesn't have some feature that I want, or it does something that I'm interested in doing, and want to know how hard it is. It might not be much, but a cursory overview can tell you whether the author knew what they heck they were doing, and auditing even one code path (or even one function) can be helpful. Try it so
        • 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 c

      • To quote Gene Spafford... (Score:5, Insightful)

        by DesScorp ( 410532 ) on Friday June 20, 2003 @09:35PM (#6259343) Journal
        " Not always. A more likely explanation is the 'many eyes' that can review the code."

        I went to a speech by Gene Spafford here a few years ago, when the subject of Linux code quality versus other systems (especially MS) came up. Someone mentioned Eric Raymond's "Thousand Eyeballs" theory, that more people looking at the code ensured better quality.

        Spaff responded "that does no good if those thousand eyeballs are looking at things like networking your toaster instead of quality and security".

        I don't think this point is emphasized enough. It's not enough that lots of people are looking at the code. You need lot's of people with training, expierience, and an eye for problems to look at the code. He pointed out that one of the biggest problems in development is that while people can learn C from a book, and even get good at it, they don't learn proper software engineering techniques, philosophies, and debugging skills that way.

        In short, simply being open source and having lots of developers isn't a solution in itself.

    • Re:Possible explanation? (Score:4, Interesting)

      by Anonymous Coward on Friday June 20, 2003 @06:10PM (#6258184)
      not always.

      What we need is a QUALIT RATING or SECURITY or DESIGN ratings for OSS.

      There is too much crap that is accepted as is because it is FREE.

      I want QUALITY software, I want to see what footprints the software uses, what info is left where etc (security ratings), I want to see USABILITY (design ratings), good layouts, not like 100 sepereate windows where an MDI type frame with docking would be better (photoshop vs GIMP etc) and so on.

      OSS NEEDS this.

      • Commercial software needs those things too. There's the security ratings for Word and Outlook? Where's the usability ratings for IE?

        Etc.

    • Re:Possible explanation? (Score:5, Insightful)

      by macrom ( 537566 ) <macrom75@hotmail.com> on Friday June 20, 2003 @06:10PM (#6258185) Homepage
      I would think the opposite -- that there are more (talented?) eyes looking at OS projects than CS projects. Many times closed projects have several developers, but only one ever sees a particular module at any given time. At my current company, we have 30 or so developers, but the modules I write are owned by me and usually only seen by me. Peer review sessions can alleviate this, but those are generally short and cover major functionality. With OSS, you have an untold number of eyes viewing a project that can help catch problems in a more timely manner.

      The theory that your best work will be done when the most eyes are watching can also apply. I think we (developers) are all guilty of shoving some nasty code in a project at some time or another under the notion that no one else will ever see it. When the whole world can look at your work, sometimes those attitudes change.

      • Re:Possible explanation? (Score:5, Insightful)

        by Osty ( 16825 ) on Friday June 20, 2003 @06:32PM (#6258359)

        With OSS, you have an untold number of eyes viewing a project that can help catch problems in a more timely manner.

        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?


        At my current company, we have 30 or so developers, but the modules I write are owned by me and usually only seen by me. Peer review sessions can alleviate this, but those are generally short and cover major functionality.

        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.)


        The theory that your best work will be done when the most eyes are watching can also apply. I think we (developers) are all guilty of shoving some nasty code in a project at some time or another under the notion that no one else will ever see it. When the whole world can look at your work, sometimes those attitudes change.

        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.

        • Re:Possible explanation? (Score:5, Interesting)

          by Dalcius ( 587481 ) on Friday June 20, 2003 @07:46PM (#6258831)
          "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?"

          While this argument does hold merit, I do think you would be surprised at the amount of looking over that utilities get. Ever hear of SDMS? [slashdot.org] Probably not. Not many folks have, I would reckon. I did some work with this project almost two years ago trying to implement PostgreSQL support so our company could use the utility internally. I found a few bugs and sent back patches as well as my changes to incorporate Postgres support. I can't speak as to the bug changes, but some time later Postgres support was added to the project.

          This is but one example, but I think it's fair to say that, although "millions and jillions of eyes are looking!!!11!" isn't correct, there are more eyes looking than you would imagine. There are only so many categories of software, and each have a good number of users.

          "Sounds to me like you're working with an inadequate number of testers, or at least an inadequate unit testing plan for developers."

          At the risk of sounding like an ass, have you or are you now working as a programmer? Testers are a valuable commodity, but are rarely used in the manner that they should be. The company that I work for is a good example, though we're attempting to move in that direction.
          Even with that said, this point is generally moot as one can argue that "more heads are better than none."

          • Re:Possible explanation? (Score:3, Interesting)

            by po8 ( 187055 )

            Heh. I was reading the source code for XGammon [unibw-hamburg.de] for some random reason a few months ago, and the README said

            An Imakefile is provided now.
            Thanks to thomas@ghpc8.ihf.rwth-aachen.de and
            Bart Skinner (bart@skinner.cs.uoregon.edu)

            and later

            Portation: SunOS 4.1 4.2 bart@skinner.cs.uoregon.edu, was the first and many others.

            I sat there for a moment trying to figure out who this Bart Skinner person was: I had done CS at U. Oregon in that time frame, and couldn't remember the name. Finally it came

        • 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 test

        • 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.

          Osty, you're exactly right. Sometimes we just have to make do. The few of us decent programmers hope for a day when the management gets the stones to get rid of the dead weight. My company is like many others : keeping your job is
        • 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?

          As soon as it gets used, it gets seen, which is not true for even popular closed source material.

          I once programmed against libgnet 0.2. This library was (at least back then) so obscure that only two websites from google had the (fairly lacking) HTMLized API docs
      • We have egos at work too. I am not supposed to TOUCH anything my coworkers do, it is THEIR code and THEIRS to command, hands off! Even when I sneak a peek and find obvious bugs, I am not allowed to fix them because it violates territoriality.

        This sort of code hording is impossible in OSS, and it's a shame. It's well known in literary circles that the more eyes that grace a page, editorially, the more likely you'll be to have a coherent and gramatically correct work. Code is no different IMO.

        Of course,
        • Sometimes it's not egos that cause a lack of eyes but time. I would love to spend more time as a team collaborating on code, but I barely have enough time to get my own modules written and tested. Then there's also the problem of talent -- most of the people in my development department are VB programmers. I wouldn't want them looking and evaluating my C++ if my job depended on it. Well, maybe then, but I would at least throw a fit! Add to it that we don't really have a talent pool for reviews and you're st

        • We have egos at work too. I am not supposed to TOUCH anything my coworkers do, it is THEIR code and THEIRS to command, hands off! Even when I sneak a peek and find obvious bugs, I am not allowed to fix them because it violates territoriality. This sort of code hording is impossible in OSS [...]

          It should be impossible in a sensibly run closed source project as well. If you have a development team whose egos are such that they can't stand criticism and claim unique ownership, you are on the absolute lowes

      • I think it's because people starting fresh can see bugs where the original programmers think it's perfectly settled.
        Those are, precisely, the bugs escaping the first phase the article writer talks about.

        Programmers are humans too and get bored. First passes of debugging are done more or less deeply, but unconsciously the following passes can't catch so much attention from the programmers, no matter how hard they try.

        In closed source, bringing new programmers not involved from the beginning is outrageou

      • Re:Possible explanation? (Score:5, Interesting)

        by jafac ( 1449 ) on Friday June 20, 2003 @07:10PM (#6258556) Homepage
        I work in an environment where we do Peer Reviews, and I've worked, in the past, in an environment where "if it compiles, ship it" - and I'll say that even if the Peers occasionally miss problems in the Review - the coder who has to present it to the Peers has a TOTALLY different attitude.

        I see code that's very carefully analyzed first, thoroughly commented, thoughtfully indented, module, class, and variable names, though generally longer, they make sense. People go out of their way to be elegant.

        I think that Peer Review is probably MORE important to overall quality of the end product, than developer experience. That's just my opinion, but after living the chaos that was a non-peer reviewed environment for 10 years, the attitudes, etc. there's really a huge difference.

        It's even better if the Review team reserves the right, by convention, to give the presenter a wedgie if they don't like their code.
    • Linux. Nuff said.

      Besides, you'd be surprised how many commercial libs out there are based on OSS. Like all the zlib variants. Or all the MP3 decoders, etc...

      The difference is more of a "reputation" is at stake in OSS. You can't just half-ass write something that works most of the time when your name is all over it.

      Of the few software firms I've worked in most of the software developers are in the mindset "if the program runs and doesn't crash, its all good" which leads to horribly incomplete poorly f

      • Re:Possible explanation? (Score:5, Funny)

        by ColaMan ( 37550 ) on Friday June 20, 2003 @08:17PM (#6259007) Journal
        You can't just half-ass write something that works most of the time when your name is all over it

        Well, looking at most OSS projects, you can do that as long as :

        1) No-one else has done it yet.
        2) You mention in the source that this is a "half-ass hack that I threw together to make something work"

    • Re:Possible explanation? (Score:4, Insightful)

      by jared_hanson ( 514797 ) on Friday June 20, 2003 @06:17PM (#6258244) Homepage Journal
      There are a number of different possiblities here, given the different dynamics of each group.

      1. In general, there are more users of closed source software, so bugs may be discovered at a faster rate. With limited development resources, the greater number of bugs take longer to fix.

      2. Users of open source software tend to be more programmer-minded. They find bugs and fix them themselves, since they have access to the source code. Everyone fixing their own bugs leads to faster debugging times.

      3. In larger companies, development and test typically are two distinct groups. There is an inherent lag in this that leads to slower response time in removing bugs. Open source software is developed and tested by the same core, ususally small group. Since the same people develop and test, they are more likely to find the bugs in their own code and fix them quicker.

      Just some observations, and I am sure there are other reasons. I'm sure the results of the study are a combination of many factors.

  • In other news ... (Score:5, Funny)

    by The Clockwork Troll ( 655321 ) on Friday June 20, 2003 @06:00PM (#6258100) Journal
    Studies reveal that debugging is easier when you do not strip symbols from binaries!

  • Faster to debug? (Score:2, Interesting)

    by Anonymous Coward
    Why does it matter if the source is open? The article should be talking about software developed by a team of individuales (including OSS) vs. software by one individual. If the source is open, there may be additional people looking at the sourcecode, but if there are many contributors the source may be a big mess of 50 different coding styles. (can't agree on a single way to splice a string, etc)

    --
    Getting too much pr0n? [porn-free.org]
    • Why does it matter if the source is open? The article should be talking about software developed by a team of individuales (including OSS) vs. software by one individual.

      There are broadly speaking two types of open source projects, often called baazar and cathedral, as put by Raymond [8]. Baazar projects such as Linux release new versions as often as possible, while cathedral projects release new versions at a much lower pace; in that respect cathedral projects are similar closed source projects, hence, c

    • 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.)

  • Look at lifecycle (Score:2, Interesting)

    by Anonymous Coward
    In the open source world, people are more willing to let a project die and be replaced than in close source.

    I know when I work on open source, if something is really ugly and needs to be replaced, I do. In a close source world thats often considered too risky and old unmaintainable code hangs around forever.

  • Not very impressed (Score:5, Insightful)

    by zapp ( 201236 ) on Friday June 20, 2003 @06:06PM (#6258152)
    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.

    • The one rule in the software engineering is that there are no rules.

      YOU FOOL! Your paradox has just ripped a hole in the space time continum! Now the planets will collapse upon themselves, destroying the entire universe. We will all enter a parrallel dimension the size of a pin tac. it will be very cold. jerk

    • Re:Not very impressed (Score:4, Insightful)

      by Otter ( 3800 ) on Friday June 20, 2003 @06:25PM (#6258316) Journal
      As with all statistics, you can make them say whatever you want...

      While I applaud all the people trying to propose alternative explanations for their findings -- if you read the paper, there are no findings.

      They have a statistical model that shows that "release early, release often" will cause bugs to be fixed faster, all things being equal, and that a handful of projects (Linux, Mozilla) have scaling behavior that fits their model. That's all.

    • but I thought... (Score:5, Funny)

      by H0NGK0NGPH00EY ( 210370 ) on Friday June 20, 2003 @06:29PM (#6258342) Homepage
      The one rule in the software engineering is that there are no rules.

      I thought the first rule in software engineering was "you don't talk about software engineering."

    • Re:Not very impressed (Score:3, Insightful)

      by rmohr02 ( 208447 )

      What percentage of OSS projects, on say sourceforge.net, have a version number 1.0? (and are "widely" used).

      I'd say that projects saying their development status is at 5 - Production/Stable [sourceforge.net] would be a better comparison.

      Looking through the first couple pages I see phpMyAdmin, Gaim, BitTorrent, and NTFS support for Linux. I'm sure there's more widely used apps there, but I either don't know them, or didn't want to look through all the pages.

    • Truedat. Plus, in OSS, there's often a very coherent problem, which requires a certain solution. If you need a journaling filesystem, you take a filesystem and add journalling. If you think that the solution other people are working in needs advanced metadata more than it needs journalling, you take a filesystem and add advanced metadata. You don't try to add both, at the same time.

      And that's what every company I've ever worked for has tried to do. Because it's integrated, package d solutions that mak

    • Re:Not very impressed (Score:4, Flamebait)

      by nathanh ( 1214 ) on Friday June 20, 2003 @07:09PM (#6258551) Homepage
      As with all statistics, you can make them say whatever you want...

      This is false. An urban myth. Something that people like to say to make themselves sound more knowledgeable than they really are. The reality is that statistics is a mathematical field and it is as rigorous as any other mathematical field.

      The real problem is that people think they understand statistics when they do not. They will claim "statistics say blah" when the statistics say nothing of the sort. The non-mathematical audience blames the statistics instead of their own ignorance.

      • Re:Not very impressed (Score:5, Insightful)

        by Mostly a lurker ( 634878 ) on Saturday June 21, 2003 @05:10AM (#6260589)
        As with all statistics, you can make them say whatever you want...

        This is false. An urban myth. Something that people like to say to make themselves sound more knowledgeable than they really are. The reality is that statistics is a mathematical field and it is as rigorous as any other mathematical field.

        Thank you for correcting my misunderstanding on this. I have always naively assumed that the raw data selected for analysis was somewhat important. In the future, I shall never doubt the result of those benchmarks I see reported as long as the numbers are correctly calculated using appropriate statistical formulae.

  • Faster debugging in Open Source (Score:5, Insightful)

    by Cato the Elder ( 520133 ) on Friday June 20, 2003 @06:06PM (#6258155) Homepage
    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.

    • Re:Faster debugging in Open Source (Score:4, Insightful)

      by Zork the Almighty ( 599344 ) on Friday June 20, 2003 @07:24PM (#6258636) Journal
      Good points, however when developers fix a bug in the latest version, can't they *sometimes* go back and fix earlier versions as well ?

      I think that the most debugging benefit that open source provides is that knowledgeable users sometimes do all the work for you...
    • Frequently, if a bug never got reported in an old version, it didn't get fixed, and it's still present in the new version (unless the project has taken to rewriting the whole thing frequently). If a bug has been reported in the old version and fixed in the latest version, you can frequently determine this, because you have access to the bug reports and mailing list archives. So you know if upgrading will fix your problem.

      It's also possible that you get can and apply a patch that solves your problem. I've d

  • bug reports (Score:4, Insightful)

    by DarkSkiesAhead ( 562955 ) on Friday June 20, 2003 @06:07PM (#6258162)

    I'd imagine that one of the most difficult parts of debugging for a large OSS project is dealing with the deluge [mozilla.org] of bug reports.

  • I thought this was agreed on .... (Score:2, Insightful)

    by Anonymous Coward
    "Another, perhaps surprising conclusion is that debugging in open source projects is always faster than in closed source projects."

    I thought that this was the one pro OSS argument that was the least argued; release early and often (since the only way to simulate all the different conditions your software will encounter in the outside world .... is to release it to the outside world)

    This is also based on the fact (?) that the hardest part about squashing bugs is finding them ...

    Is this actually controvers

  • Models? (Score:2, Offtopic)

    by DogIsMyCoprocessor ( 642655 )
    From the abstract -

    We introduce a model of software bug dynamics where users, programmers and maintainers interact through a given program. 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. For a given set of parameters, debugging in open source projects is always faster than in closed source projects. Finally, we determine qualitative lowers

  • Mediocre Propoganda at Best, A Joke at Worse (Score:5, Insightful)

    by Gabe Garza ( 535203 ) on Friday June 20, 2003 @06:10PM (#6258191)
    I know this is Slashdot and the party line is "OSS Rules!," but this seems pushing it even for this audience.

    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.

    • You have angered the /. gods now.

      Mod parent and grandparent and great-grandparent down.

      Also, mod parents children down.

      Also, mod great-great-grandparents great-great-granddaughters down.

      Also, say up unto them verily, that the mod of the parent will be cast down the generations to be a mod on the children, and on the children's children, and on the children's children's chilluns.

      And also, mod down the nephews of the parents of the sibilings of the grandparent for though they be trolls or flaimbait, they

    • Re:Mediocre Propoganda at Best, A Joke at Worse (Score:4, Interesting)

      by ArmorFiend ( 151674 ) on Friday June 20, 2003 @07:08PM (#6258548) Homepage Journal
      Two of the three open projects you cite also happen to be bigger than most projects, with more developers working in || at the same time than most projects. Does that help them? Read "the mythical man-month" for the answer. (Hint: no).
      • Two of the three open projects you cite also happen to be bigger than most projects, with more developers working in || at the same time than most projects. Does that help them? Read "the mythical man-month" for the answer. (Hint: no).

        I agree that Mozilla and the Linux kernel are very good pieces of software--I use them each for many hours each day. I don't have a problem with them: I have a problem with using only three projects has a sample size. They're attempting to make a precise model to describe

      • Mythical Man Month Myths (Score:3, Insightful)

        by Jerf ( 17166 )
        Two of the three open projects you cite also happen to be bigger than most projects, with more developers working in || at the same time than most projects. Does that help them? Read "the mythical man-month" for the answer. (Hint: no).

        You have seriously misread The Mythical Man Month, to the point of absurdity. The Mythical Man Month does emphatically not claim that more people can't do any more then fewer people.

        What it says is that programmers are not interchangable, and as a result, adding program

  • Of course debugging is easier... (Score:5, Insightful)

    by sterno ( 16320 ) on Friday June 20, 2003 @06:10PM (#6258192) Homepage
    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.
    • 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 t
  • Because gdb is so slow with a realy big project.
    ( ...Symbol loading... )
    Trust me on this, I'm in this situation every day.

  • Easy explanation (Score:5, Funny)

    by meta-monkey ( 321000 ) on Friday June 20, 2003 @06:11PM (#6258197) Journal
    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.

  • Microsoft Refutes Oxford Researchers' Conclusions (Score:4, Funny)

    by xelph ( 542741 ) on Friday June 20, 2003 @06:13PM (#6258213)
    A spokesperson at Microsoft refuted the conclusions of two french researchers from Oxford University this afternoon, saying that the business model behind Open Source was flawed anyway, since fewer bugs meant less urgency in updating to newer versions of software where old annoying bugs had been eliminated (only to be replaced with fresh one in anticipation of the subsequent forced release). The spokesperson also mentioned the enormous success of Microsoft's recent Closed Source initiative, under Bill Gates's supervision, to make computing more stable and secure, and finished by indicating that the UK government, who is being turned by Microsoft into a strong Open Source opponent (see recent Slashdot story), belonged to them anyway, and that the "frogs" would be deported to France shortly.

  • ESR says... (Score:4, Interesting)

    by Realistic_Dragon ( 655151 ) on Friday June 20, 2003 @06:17PM (#6258252) Homepage
    If you read 'The Cathedral and the Bazzar' by ESR he gives some very good reasons for Open Source development being better at bug finding:

    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.

    To which you can add number 3 and 4 of my own devising:

    3) The kind of people who write and use OSS care about security and stability (often to an extreme) and so think that bug fixes are essential not a nice-to-have.

    4) Closed source developes have to deal with management and merketing wienies - it's a wonder they even get buggy code out the door.
    • Whereas I have to admit the reality of 4) at times, I do write closed source software, and oddly enough, I do care about security and stability. May I suggest that 3) should be

      3) The people writing OSS don't have to deal with #4, which makes security and stability a more achievable goal.

      (I can't argue with the reality of CS being often less secure and less stable - that is just 4) makes it so)

    • Re: ESR says... (Score:3, Informative)

      by Black Parrot ( 19622 )

      > 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

      • old practices (Score:3, Insightful)

        by Jerf ( 17166 )
        I think those are probably fossil practices left over from pre-Internet days.

        It is important to shield the developers from telephone calls and visits from the customer, because otherwise the developers will get nothing done, not necessarily because they have no time (time_in_day - time_dealing_with_customers may still be large), but because they are constantly being interrupted.

        As long as the developer has discipline and the customer realizes that the answers won't be instant, though, there can be great v

  • Bogus assumptions (Score:5, Insightful)

    by ckessel ( 607295 ) <ckessel AT tripwire DOT com> on Friday June 20, 2003 @06:18PM (#6258259)
    The paper makes some critical assumptions, one of which is:

    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.

    • This is true, but any size business will update more often with open source software. OSS is generally the same version carried on for eternity, rewriting portions anywhere it makes sense. The kernel for instance, takes very small incremmental steps. There is also no licensing cost for the upgrade. So while large businesses will upgrade less often than small, large using open source will tend to upgrade more often than large using closed source.
  • Give a random developer 200,000 lines of code he's never seen. Ask him to find a bug. Odds are he'll have lots of trouble doing so. When he's finished, will it make any difference if you tell him that the code was open or closed source? A big project is a big project, period.

    • > Give a random developer 200,000 lines of code he's never seen. Ask him to find a bug. Odds are he'll have lots of trouble doing so. When he's finished, will it make any difference if you tell him that the code was open or closed source? A big project is a big project, period.

      Most bugs are found by using the software rather than by reading its code.

      The debugging difference between OSS and CSS is (mostly) only interesting in terms of what happens after the bug is found.

  • Weak (Score:2, Insightful)

    by aztektum ( 170569 )
    How come stories like these always seem like they get posted because of zealotry?

  • Programming Style (Score:3, Interesting)

    by bobthemuse ( 574400 ) on Friday June 20, 2003 @06:25PM (#6258312)
    I wonder how much of this is due to programming style. What I mean is, can there be a difference in how easy it is to debug apache (maintained and written by many people) versus an OSS project which was mostly written my one person? I'd imagine that a large number of programmers results in more 'generic' code, rather than the specialized shortcuts that are unique to most programmers. That would make it much easier to debug, IMHO.
  • Funny how these guys posted their paper to the cond-mat (condensed matter physics) section of the e-print archive, which, after all, has categories for computer science. The paper has nothing to do with condensed matter physics, aside from the fact that programmers are usually composed of solids and liquids.

  • Thats because (Score:3, Funny)

    by nother_nix_hacker ( 596961 ) on Friday June 20, 2003 @06:32PM (#6258357)
    Another, perhaps surprising conclusion is that debugging in open source projects is always faster than in closed source projects."

    Thats because in closed source projects you have to dis-assemble the binary first! :)

  • Always ? (Score:5, Insightful)

    by FauxPasIII ( 75900 ) on Friday June 20, 2003 @06:41PM (#6258400)
    All generalizations are false.
    • That's true. Closed source development is like a single processor pc, compared to open source development this is your massively parallel supercomputer. Now generally your massively parallel super computer is faster than a desktop pc, but it's NOT always faster... for instance, it's not faster if it's turned off.
  • But they're fixed now, make sure to upgrade!

  • Seems reasonable to me (Score:5, Interesting)

    by riptalon ( 595997 ) on Friday June 20, 2003 @07:26PM (#6258663)

    During development the closed source software will only be used by the developers, and in general the developers are not like their end users and may have little interest in actually using the software they have been payed to write. For open source however the software is likely to be available to users from a very early stage and the developers are likely to be active users of the software as well. It would be very surprising if the bugs were not squashed faster.

    Once the software is released closed source has the problem that bugs will only be fixed if the producer sees profit in it. Major security bugs will be fixed "relatively" quickly, as they might impact future sales otherwise, but with closed source the producer may not fix known non-security critical bugs if they don't feel like it, and no one else can.

    There is also a problem with bug reporting in the closed source world. Who actually reports closed source non-security critical bugs? There isn't a lot of incentive since they may not be fixed anyway and if they are the fix will likely just go into then next version (that could be a year or two away) and you will have to pay for. Also the fraction of the users that do not have a licenced copy are unlikely to report bugs.

    Whatever the merits of this particular study's methodology the results are just plain common sense anyway.

  • its the documentation! (Score:5, Insightful)

    by appleLaserWriter ( 91994 ) on Friday June 20, 2003 @07:45PM (#6258821)
    Successful OSS projects must be well documented in order to survive. Naming variables in an intuitive manner and providing insightful comments isn't about improving your annual review scores, it is about ensureing that others can and will read your code.

    Companies like Microsoft need to introduce policies to create the same effect. Code reviews and extreme programming are good examples. They often degenerate into either a rubber stamp or a grudge match between different interpretations of Hungarian Notation.
  • followed by a slow phase where most bugs have been fixed, hence, are hard to find
    Duh. So it takes a "model of software bug dynamics" to see that it's a tad harder to find something which is no longer there ?

    Their "model of iraqi WMD dynamics" is eagerly awaited.

  • Drink the kool-aid... (Score:2, Interesting)

    by HydeMan ( 638036 )
    This is yet another example of someone trying to sell the OSS agenda. Statistics can easily lie, and I suspect that the person involved in the study was not a neutral party. A more important question is do people on /. EVER find fault in OSS? Surely it can't be a nirvana. Be honest, and get real.
  • Any paper that concludes that one method is "always" better than another is almost certainly wrong. Be happy slashdotters, you can get away without reading the article this time.
  • Seriously, grab gnat, go to http://www.adahome.com/ and read a tutorial or two, and start writing reliable, readable, and reusable code in the amount of time it takes to read through the tutorial.
  • I develop with Cygwin and Emacs, but I compile and debug with Visual Studio 7.0. I believe that the Visual Studio debugger is unparalleled (lacking just Emacs integration! :) ), and there is nothing that can beat precompiled headers, a fast compiler (in the first place) and the visual debugging integration of Visual Studio.

    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.

Slashdot Top Deals

Lots of folks confuse bad management with destiny. -- Frank Hubbard

Close