Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Opensource Code More Refined Than Closed? 270

zonker writes "In this poorly titled cnet story (as opposed to an earlier story stating a similar theme), a company named Reasoning says that at first open source code has marginally worse quality than closed source code of the same maturity, but it tends to become better refined through the open-natured development process than closed source. They mention Apache and Linux as examples, however they don't mention the 'competitors' they tested against by name. ."
This discussion has been archived. No new comments can be posted.

Opensource Code More Refined Than Closed?

Comments Filter:
  • Who Knows? (Score:3, Interesting)

    by caffeinex36 ( 608768 ) on Tuesday July 01, 2003 @07:20AM (#6338179)
    Who really knows? I mean...of course we know some closed-source applications just plain out have horrible code, but being closed-source, we really can't look at it can we? With open-source, I think because it is open, it is critiqued more.

    -Rob
    • Re:Who Knows? (Score:5, Insightful)

      by __past__ ( 542467 ) on Tuesday July 01, 2003 @08:10AM (#6338481)
      Of course we can know.

      First, a lot of "us" work on closed-sources apps in their day jobs. And most of those I have met were really ugly indeed.

      Second, I cannot remember a single occasion where a formerly closed source app was opened and did not stink. Netscape took some years and a nearly complete rewrite to become the Mozilla we all know and love. OpenOffice.org is not exactly clean, modular code, even if it is undoubtly useful when you finally get it to compile. Ever looked at SAP DB? A horribly mess of ancient C and a custom Pascal dialect. Remember that ages-old backdoor in Interbase, found when Borland thought OS would be a good idea for a week or so?

      I think that the feeling that thousands of your peers will eventually read your code and make fun of you in public forums and mailing lists if it isn't clean is quite an effective way of quality control.

      On the other hand, browsing sourceforge can make it pretty clear that ugly code is not exclusively a problem of closed-source code.

      • Re:Who Knows? (Score:5, Interesting)

        by bluethundr ( 562578 ) * on Tuesday July 01, 2003 @09:45AM (#6339071) Homepage Journal
        I think that the feeling that thousands of your peers will eventually read your code and make fun of you in public forums and mailing lists if it isn't clean is quite an effective way of quality control.

        I agree that peer review of your code is a great motivator of quality. But, however incredibly illustrative it may prove, we'll only be able to compare apples to apples on projects that have made the transition from closed to open (like Netscape->Mozilla).

        Will we ever have an opportunity to compare Apache to IIS, for example? Likely not. Nor is it likely that we'll ever be able to compare comparable open source projects to anything coded in Redmond.

        I personally have no doubt (or rather a belief) that Apache is pure and sweet like a mountain spring, and that IIS is a huge turd-burglar. But how can I know this is true beyond any shadow of doubt. And it just so happens that, while it's nice comparing Open Source to closed stuff from Borland and Netscape, Microsoft is the biggest kid on the block of the closed source world. So how can we know, how say, Open Office compares to MS Office? I really think we can't, and likely won't.
        • Re:Who Knows? (Score:5, Interesting)

          by ChaosDiscord ( 4913 ) on Tuesday July 01, 2003 @01:31PM (#6341479) Homepage Journal
          So how can we know, how say, Open Office compares to MS Office? I really think we can't, and likely won't.

          How can we know? In a philosophical sense, we can't. But you can find out for practical purposes. Personally I know people who used to work for Microsoft. I heard that the code, while not bad, wasn't that good. I learned about the constant political infighting between groups and an irrational refusal to use external code. This led to such silliness as no major project in Microsoft actually using their own source control system [highprogrammer.com]. This lead to the the Office project maintaining their own forked version of the compiler. While none of this actively says their code is bad, it does suggest problems in their system that might be reflected in their code. Of course, while this is second hand to me, it's third hand to you, so you might not trust it. Reasonable enough. But my point is that one way to learn is to get the information from someone who really does know and who you trust.

          Relatedly, you can make a certain level of judgement based on the software you receive and work with. If the software is buggy crap, chances are that the code isn't the Mona Lisa of the programming world.

      • I've also worked for a large number of companies over the years, and have also worked on open-source. I'd venture that one of the main reasons closed-source doesn't improve is that many (actually most) employers do not want to pay for 'code cleanup'. An employee will see little gain from trying to improve the code, and will certainly get penalized if his work causes even a single bug.
        • It's not the programmers that pay for large-scale code cleanup, it's the company. A good commercial software manager realizes it's a large investment in time and money to completely refactor code, so if the planned functionality doesn't require a rewrite of that magnitude, they won't do it.

          Open-source applications aren't limited by hard deadlines, demanding customers that want the feature yesterday, and budgets that limit the man-hours that can be devoted to a project. An open-source project manager can ta
    • If you write bad closed source code, all the developers in the company will se it.

      If you write bad open source code, the entire fscking world will see it.

      More shame -> more incentive to write clean, solid, well-commented code.
  • It makes sense ... (Score:5, Insightful)

    by leeroybrown ( 624767 ) on Tuesday July 01, 2003 @07:22AM (#6338190)
    Of course code that is peer reviewed by a large group of coders will become better over time.

    Most proprietary code is only reviewed until the developers have ironed all the bugs necessary to get it to run reliably. Then it's shelved until the support lifecycle requires a fix.

    Conversly, Open Source projects have a huge interested user base who can continue to review, submit bugs and improve the code over time.
    • by Glyndwr ( 217857 ) on Tuesday July 01, 2003 @07:25AM (#6338221) Homepage Journal
      Of course code that is peer reviewed by a large group of coders will become better over time.
      Well, yeah, that seems intuiative... but if you're working with a team of half a dozen other people in a big company with strict coding guidelines, then it seems to be there would be a fair bit of peer review. Whereas if you're working on one of the smaller open source projects with just you developing and the odd patch coming in, not to mention no boss figure looking critically at your code, there's little reason to clean code up. What I'm saying is that this peer review thing cuts both ways.
      • by killmenow ( 184444 ) on Tuesday July 01, 2003 @07:42AM (#6338320)
        Still, even if I'm just one guy working on my own favorite pet project which I distribute as open source, I'm going to put as much effort into making it clean, simple, aesthetically pleasing, well-designed, etc. as possible.

        Whereas, if I'm writing my own one-man-show app for my employer, knowing nobody else is likely to ever see the code, it'll end up more like a Q&D.

        And that's simply because of human nature. It's like cleaning house. If I *know* people are coming over and likely to see my house, I want it clean and orderly. If I *know* the reverse is true, I have less incentive to make my house immaculate.
        • I've read through a lot of shitty open source code

          When you can't code above your level how will you ever improve it?

          I tidy up for guests but the place is still scruffy cos I just don't have the money / incentive to spruce it up further.

          • When you can't code above your level how will you ever improve it?

            By failing. That's how you usually learn.

            • Or someone who can code above your level sees the code and rips you a new one. If you're lucky they then fix your mistakes, if you're really lucky they explain how, so you learn.

              That doesn't happen much (if at all) in commercial environments where, IME, the better coders are usually too tied doing their own work to fix yours and managers are more interested in hitting their deadline with code that works than whether there might be a better, more reliable, way to do it. The exceptions tend to be environme

              • > if you're really lucky they explain how

                And if you're really, really lucky you pair program with them. Then you get to watch them make mistakes like everyone else, and they get to explain how they write good code - the thought process they go thru, how they remove duplication, etc.
      • >>then it seems to be there would be a fair bit
        >>of peer review

        Peer review only lasts until the product is deemed to have no 'show stoppers'. Look at most retail software titles that come with a README of 'known issues'.
      • by XMunkki ( 533952 )
        That's why I think that at the start, perr reviewed closed source projects tend to be better than open source projects. But once the project grows older, so does the focus. Within a company there's always incentive to improve on the existing and create more features. Sure enough, these all are per reviewed, but which small group could actually notice all minor design flaws? These minor details may not be critical at the moment, but may come up later. 6-8 months later with a tight deadline.

        With open source,
      • Well, yeah, that seems intuiative... but if you're working with a team of half a dozen other people in a big company with strict coding guidelines, then it seems to be there would be a fair bit of peer review.

        This could easily turn out to be little better than a single person working on the code. Since all the people are in the same environment, subject to the same "corporate culture".

        Whereas if you're working on one of the smaller open source projects with just you developing and the odd patch coming i
    • by GeckoFood ( 585211 ) <[geckofood] [at] [gmail.com]> on Tuesday July 01, 2003 @07:25AM (#6338226) Journal

      It makes good sense, to a point.

      It is not uncommon to have multiple spinoffs from the main source tree. Each branch will have a different path to maturity in the lifecycle of development. All things being equal, each branch should acheive the same quality as all the others, but this isn't always the case.

      I have seen open source programs that actually got worse over time as well, but that was due to being passed around like a hot potato as far as maintainer was concerned.

    • Of course code that is peer reviewed by a large group of coders will become better over time.

      But is a typical OS project really peer reviewed properly by more people than a typical closed source project of a comparable size?

      Conversly, Open Source projects have a huge interested user base who can continue to review, submit bugs and improve the code over time.

      There's nothing inherent about open source that means it has a wider user base or that more people should report bugs.

      Improving the code imp

      • Depends what you mean by projects 'of a comparable size'. Obviously, if you mean 'having a similar sized development team', then I guess they probably do have about the same amount of peer review, don't they?
    • by Hatechall ( 541378 ) on Tuesday July 01, 2003 @07:45AM (#6338327) Homepage
      Sure code that is peer reviewed by a large group of coders does get better over time, but just because this is /. let's not shortchange the benifits of closed source.

      The programmers will all know (or should) what the main points of the program should be directed towards, will all follow similar protocol, and in alot of cases, all work togeather; and because of this may be able to write tighter code due to being able to be with the person who origionally coded the program. Pages and pages of documentation usually is no match for that.

      I'm not bashing open source, I prefer it, but let's not go critiquing closed source for no reason, there is enough valid reasons for that.
    • There's an important variable involved with Open/Closed Source that nearly every OSS advocate blatently ignores. While OSS may have numerous people browsing through source code for a project, only a minute percentage of the OSS projects get the required attention to make them "good code" or "good design". Also, while numerous people may be focussing on a particular OSS project, only a small percentage of them produce the majority of the work for that project, which limits its diversity. To top all of thi
      • > only a minute percentage of the
        > OSS projects get the required attention
        > to make them "good code" or "good design".

        And that's OK. Why? Because it takes 10 seconds to start an "open source" project. All you have to do is say "I'm starting a Microsoft Exchange replacement!" and put up a web page. If you make progress, people will come and help you out. If you don't they won't, and that's fine.

        So the good projects float to the top and more people work on them. As it should be.

        > far out
        • Fortunately, software quality or usefulness isn't determined by the number of hours needed to produce it.

          They don't determine quality or usefulness, they represent the quality and usefulness.
  • Competitors? (Score:3, Interesting)

    by Noryungi ( 70322 ) on Tuesday July 01, 2003 @07:23AM (#6338197) Homepage Journal
    The interesting thing is that ATT is a client of Reasoning [reasoning.com].

    Makes you wonder if they may have tested OSs like Plan9 or Inferno... They probably haven't tested the original UNIX code, though.
  • Right.. (Score:4, Insightful)

    by Gortbusters.org ( 637314 ) on Tuesday July 01, 2003 @07:23AM (#6338199) Homepage Journal
    So your version 0.1 written by some dude in his spare time is laughable compared to the closed source commercial products. By the time you get to 1.0, 2.0 or whatever.. and many people on the project, the quality has risen greatly.

    Personally, I like seeing the quality improvements on the Apache and PHP projects. Is there anything these guys can't do?
  • by GillBates0 ( 664202 ) on Tuesday July 01, 2003 @07:24AM (#6338206) Homepage Journal
    Ofcourse Open Source code is better than Open Sores code!
  • Summary (Score:4, Insightful)

    by binarytoaster ( 174681 ) on Tuesday July 01, 2003 @07:24AM (#6338209)
    "When more people can look at your stuff, you have a tendency to make it look nicer."
  • Stupid (Score:3, Insightful)

    by stoev ( 103408 ) on Tuesday July 01, 2003 @07:24AM (#6338211)
    This kind of comparisons are stupid in general. The quality of the algorithm used can not be measured in this way. And so many things depend on it.
    • Re:Stupid (Score:2, Informative)

      by znaps ( 470170 )
      It's more about quality in terms of the code being well-written, bug free, and maintainable. These are the things which create a lasting, reliable and hence popular product.
    • Yes. If a better algorithm is used then the code will be usually better. But the algorithms aren't usually patented (or haven't been up to this point), so open source and closed source software tends to use similar algorithms.

      In my experience there's more or less two classes of bugs; those problems that were more or less inevitable to happen given the original specification (given that people's intelligence doesn't vary that much, and in some ways people are pretty similar, unless they are experienced in

  • Weren't Reasoning mentioned here before, and didn't several people note then that most of the defects they were looking for were actually the sort of thing that automated software (such as theirs, for example) could spot? Any good project, open- or closed-source, will routinely run tools to scan for such flaws, and no serious development should have any.

    The more serious question, since the one they appear to be asking has such an obvious and easy answer, is whether open-source development leads to signifi

  • BS (Score:4, Interesting)

    by Anonymous Coward on Tuesday July 01, 2003 @07:24AM (#6338213)
    I call BS. More refined?? How about we have a semi-scientific study that lists competitors that have the same amount of hours put towards their code as the open source code.

    To actually clarify what happened:
    -Opensource code can have a lot more man hours put into it in a shorter period of time than closed source

    -Close source code is only as good as the person doing the hiring.
    • by Surak ( 18578 ) *
      What is the guy, a SCO plant? :)

      You can say either thing about either development model and it's true.

      Opensource code can have a lot more man hours put into it in a shorter period of time than closed source

      Closed source code can also have a lot more man hours. Not every open source project has as many man hours into it as Apache or Linux.

      Closed source code is only as good as the person doing the hiring.

      Open Source code is only as good as the developers working on the project.

      While the statements
  • by Anonymous Coward on Tuesday July 01, 2003 @07:25AM (#6338218)
    As a Linux user myself for many years I now see the sideeffects of Open Source myself and started to eye for alternative Operating Systems such as MorphOS (Pegasos), MacOSX, BeOS Zeta and Microsoft Windows. There are various reasons for me to do this.

    a) The Open Source community used to be a nice one, the philosophy of it was valued high in the first couple of years but meanwhile the entire situation has changed. Companies are trying to protect their IP, other companies don't work fair with the Open Source community by not backporting their changes in the original sources and so on.

    b) The audience changed totally, you need to deal with more and more complaining and ranting people every day. People that are always dis-satisfied regardless what you do. Even I as Programmer need to deal with these people. I spent my time writing the programms, fixing bugs, answering technical emails, pay for the Webspace, offer the software and yet you need to deal with dis-satisfied people all overwhere which leads into demotivation of doing something better.

    c) Many people wandered off from Linux and Open Source by using alternative Systems (preferabely MacOSX) thus they have a working, aesthetical, nice, round and standardized desktop environment with all tested tools. They can get their work done and don't care for Linux and it's Open Source that much anymore as they initially did. A lot of people started to work a lot less on Open Source because they don't see the need to do this anymore because they get all the software with better quality offered on their alternative System.

    Here an example: A lot of GNOME developer moved away working on MacOSX these days and don't look back, while they still help with various fixes, coding etc. they still do this as funjob, they don't see the need to work as hard to make a good Desktop because they have a Microsoft independant OS (MacOSX) which offers them everything and more than GNOME for example. Of course they also see the points written by me here with all the ranting people, no fair play of companies and the general demotivation.

    Face it, we all like to be honoured for our work, we all like to hear 'thank you' from the people outside that we spent our time working our ass off on the tools we offer. But the reality is that we deal more with complaining people rather than people who said 'thank you'. We all like to earn some money with what we do. Look, we sit down the entire day, weeks, months working on the Tool, we pay for Webspace and more and we don't even get the money back for the Webspace we pay once per year.

    Open Source is indeed a nice thing but the times has heavily changed, complaining users, demotivation, dirty play with companies, sueing of people who wrote Open Source applications like the freecraft person. A very nice game and now it's not available anymore because he got is ass sued off.

    Think about it, is it really worth the trouble ? We should concentrate back to the old roots and try making some bucks with our work, getting the webspace paid, stop the insanity with open source. it's a good idea but the license is only a hype. Like everyone can fork the code and release his own version of the software which only ends in 20 derivates which each of them still doesn't do the work it was aimed for. Not to mention that we all are individual people who work for fame, for money for being someone in the community. You work on the software because you love it because you never think about someone comming up forking it and then one day you see a derivate of your work floating around in the community and you get heavily pissed off and stop working on it and feel disappointed and have thoughts in your head saying 'what did i do wrong, why did this person fork my software' and so on. Please don't understand me wrong, think back the time when emacs got forked to xemacs. Or think back when KDE Desktop got heavily trashed by RedHat. You are itching at the egos of people with this. It's really better to start thinking about new and better ways and search for an alternative work on an alternative System.
    • by haeger ( 85819 ) on Tuesday July 01, 2003 @08:11AM (#6338490)
      Ok troll, I'll bite.

      a) The OpenSource community is still a nice one. There are some people that don't play nice, but most do. Yes, companies are fighting to protect their IP. Naturally, they make money from it and they wont give that up so easily. What did You expect? The companies that You mention that won't backport their changes to the original source, well if You put a license on your code that prohibits them from keeping their changes to themselves, they can't do that, can they?

      b) Yes the audience has changed. Now not only techies use linux and open source. I thought this was a good thing? Here's a newsflash for You, if You write OS software on your free time the users that You complain about can't really demand anything from You. Next time someone asks You do do something, charge them for it. If they need something done they've got to pay for it. That's the way I do if someone asks me for windows help.

      c) Now if this isn't flamebait I don't know what is. There are plenty of "working, aesthetical, nice, round and standardized desktop environment with all tested tools." on Linux and other Open Source systems.
      Yes, a lot of people works less on Open Source now than they did a few years ago, and You know what? A lot of people works more on Open Source now than they did a few years ago. Peoples interests change, is that strange to You?

      "Face it, we all like to be honoured for our work, we all like to hear 'thank you' from the people outside that we spent our time working our ass off on the tools we offer."
      True, but that's not why I write Open Source. I do it because it's fun and to have the tools I need for my own benefit. If someone complains to me about my tool and don't bring constructive ideas, they can bite my shiny metal ass. Or they can pay me to modify it to their liking.

      "Open Source is indeed a nice thing but the times has heavily changed, complaining users, demotivation, dirty play with companies, sueing of people..."
      I'm sorry that You feel that way and that your motivation is down, but that don't make Open Source a failure. I gave up playing the guitar because my hands hurt and my girfriend asked me to (don't ask), does that make guitar music a failure?

      "Think about it, is it really worth the trouble ?"
      I have, and for me the answer is Yes. I get the tools I need for a job and as a bonus reward I get to use some other peoples tools that they've created to get their job done. I do get paid for my work, just not in cash in my pocket. If I can use the tools that other people write in my job to do it better, I win anyway.

      Now, Mr Big Buissness that's hiding under that AC protection, I can understand that You would like Open Source to go away as fast as possible. I understand that You see this Open Source as a threat to your buisness, and it might be, if You sell programs, but for all other companies it's a winning concept. I'm sure You'll figure out how to make the most of Open Source in the future. Most people do eventually.

      All the best

      .haeger
      • I agree with you about the Troll. It is probably a business wannabe.

        You forget to mention though that all the shennigans now happening come down to some unsuccessful closed source companies getting very worried. Some of them produced reasonable software, but they can't support it any more. Support on OSS is variable too, but at least I've got the source code. Some companies using the support model to get revenue continuity from older products really don't want to lose this.

    • As a Linux user myself for many years I now see the sideeffects of Open Source myself and started to eye for alternative Operating Systems such as MorphOS (Pegasos), MacOSX, BeOS Zeta and Microsoft Windows. There are various reasons for me to do this.

      Nah, scratch what I said earlier. *This* guy is a SCO plant. ;)
    • This guy has started trolling all over the place (same message each time).

      If this was one off and signed, I would debate with him, but it is just a troll (a little like BSD/xxx is dying). It could even be the same troll.

  • No Brainer (Score:4, Insightful)

    by Richard_at_work ( 517087 ) * on Tuesday July 01, 2003 @07:26AM (#6338231)
    This is obvious, as most businesses dont want developers to spend time on code that already works. If it doesnt work, then it gets rewritten. If the spec changes, then it gets rewritten. If its fine then you work on something else.

    Opensource developers have to have a certain pride in their code almost by definition, as other people will be looking at it. Also if someone sees that a bit of code is not as efficient as it can be, then usually they rewrite it.

    The one downside to opensource code that i have seen is that since many people contribute, and some of those contributions are not official, eg patches, then coding styles start to show through. In closed source business environments, coding styles are usually not a issue as we all have guidelines to work to, defining the use of the language so that anyone in our group can pick up code and instantly add to it, usually code written this way cannot be pinned to any one individual.
    • Well, that's a reason that Open-Source would be *worse* than closed-source: if closed-source that worked was left alone, then there won't be many bugs in it (otherwise, it wouldn't be left alone), if open-source gets things rewritten for aesthetic or personal reasons then many bugs are going to be introduced.

      'If it aint broke, don't touch it' should be the adage of every programmer (and is the reason banks still use Cobol for their apps)
    • This is obvious, as most businesses dont want developers to spend time on code that already works. If it doesnt work, then it gets rewritten. If the spec changes, then it gets rewritten.

      Or alternativly the spec gets changed to avoid needing to rewrite/debug :)
  • How do they know ? (Score:4, Insightful)

    by Rosco P. Coltrane ( 209368 ) on Tuesday July 01, 2003 @07:26AM (#6338234)
    open source code has marginally worse quality than closed source code of the same maturity

    So they compared the source code of an open-source project with what ? the disassembled code of a closed-source project ? how would they know if the source code of the latter has better quality than the former's, since by definition, you can't get the source code of the latter ?

    I believe the guy is talking about the quality of the whole project, not source code quality.
    • So they compared the source code of an open-source project with what ? the disassembled code of a closed-source project ? how would they know if the source code of the latter has better quality than the former's, since by definition, you can't get the source code of the latter ?

      If you have the cash, you can get source to a lot of things. That doesn't mean it's open-source though, just "with-source". Check out the open-source definition [opensource.org].

  • common sense (Score:4, Insightful)

    by pytheron ( 443963 ) on Tuesday July 01, 2003 @07:26AM (#6338238) Homepage
    Closed source is driven by timeframes, customer requests and profitability. It's not done as a labour of love. Hence quality will always take second place to it-works-but-its-a-kludge

    In contrast, Open Source is driven by all-that-is-good, i.e free software, community spirit, because-I-can. When there is no paymaster (because you rarely get paid for OSS), the motives for development differ greatly, and pride-of-work takes priority.

    The two disparate models do cross sometimes, like in the case of ReiserFS - features are chosen by donation, but don't expect development to be rushed. Hans seems to have got the balance right with his project.

    • Closed source is driven by timeframes, customer requests and profitability. It's not done as a labour of love. Hence quality will always take second place to it-works-but-its-a-kludge

      Generalize much? The fact of the matter is that closed source software is driven by the harsh realities of the real world: namely, that people like to be compensated for their work. If I were to create a webserver that worked exactly the same as Apache (but developed it independently of Apache and never looked at the source
    • By their article, it seems to me that they are saying this only is the case long-term. In other words, the cutting edge of Linux is much rougher than the cutting edge of Windows or Adobe Photoshop; but in the end it works better and more reliably, because the programmers rework it forever until it just works well.
    • "It's not done as a labour of love."

      I beg to differ. Just ask John Carmack. Don't you think he does it as a labor of love? I think so. I think there are plenty of programmers to work on closed source applications because they love it. Or take programmers who work on closed source during the day at work and contribute to open source at home. I know I do.

      -Vic
  • by Advocadus Diaboli ( 323784 ) on Tuesday July 01, 2003 @07:33AM (#6338276)
    If I read the Datasheet [reasoning.com] for the automatic code inspector there is a funny example. They find a memory leak in their example. I had a quick code review and found the following bugs:

    27 fspec=malloc(strlen(dir) + 2 + 1);
    28 strcpy(filespec, dir);
    30 if ((ix = strlen (fspec) ....

    First of all it looks like line 29 is disappeared, but maybe it was just whitespace. Looking at the code above show me that the strlen function is called with the pointer returned by the malloc in line 27. That's great, since strlen is looking for the "null termination byte" in the string it will return the position of whatever random zero byte will be next in the allocated memory because nobody was writing anything to the allocated space. I suspect, that line 28 should refer to "fspec" instead of "filespec" but since the program obviously compiled it can also be that filespec is a valid global identifier.

    Anyway, this simple example from them shows, that their automatic tool doesn't find all bugs and so the numbers returned can be just a sort of wild guess. BTW: I would really like to know what their code inspection tool will report if they use it on their own code inspection software. :-)

    • Nah, dir is the parameter to the function. It's the whole purpose for calling the function. Assuming it's a non-NULL null-terminated string, which is what the function requires as its input parameter, then this will work. If not, Garbage-In, Garbage-Out.

      BTW: "strdup()" looks like this:
      char *strdup(char *a) {
      char *b = (a) ? malloc(strlen(a)+1) : NULL;
      if (b) strcpy(b, a);
      return b;
      }

      However, the "filespec" instead of "fspec" is a clear mistake. It probably wouldn't compile -- this sort of mistake occ
  • by shoppa ( 464619 ) on Tuesday July 01, 2003 @07:35AM (#6338284)
    My textbook example of this is comparing gnu 'pwd' with commercial Unice's 'pwd'.

    I can get most commercial Unix's to core dump by running 'pwd' in the right circumstance. Yes, that's right. A command that takes no arguments and reads nothing from standard input core dumps in the correct circumstance. The circumstance is usually just being in a directory whose path name is several hundred thousand characters long, but some will crash if you set the environment variables right and it looks at them for something having to do with POSIX compliance. I don't know what POSIX compliance should have to do with pwd but then again I'm just a dummy.

    OTOH I have never been able to get GNU 'pwd' to dump core.

    What does this mean in the big picture? That after many man-years of intensive effort you can write a robust piece of code that takes no input or command-line arguments :-)

  • The comparable defect rate indicates that open-source software starts out as raw as proprietary software, but Reasoning said that ultimately open-source software has the potential to exceed proprietary software.

    For some value of "starting out" and "open source software", I think everybody can agree with this. The average open-source project starts out as a lone coder with a pet project - it stands to reason it will improve significantly when other coders (with varying experience in various areas) jum

    • But Apache isn't in that boat - it's considered to be mature. Which version were they studying?

      Don't laugh. They studied apache 2.1 [reasoning.com].

      IOW. an open source product tagged alpha is comparable to a typical closed source product.

  • It's ego stroke (Score:3, Insightful)

    by TerryAtWork ( 598364 ) <research@aceretail.com> on Tuesday July 01, 2003 @07:41AM (#6338312)
    The reason OS software is good is because when people publish OS software they know thousands of experienced geeks will be perusing their code, and they don't want to look bad.

    This is a powerful motiviation.

  • by Chalst ( 57653 ) on Tuesday July 01, 2003 @07:41AM (#6338315) Homepage Journal
    It would be interesting to see if outliers in terms of code quality follow different development methodologies than the median projects. Eg. does Twisted Python's much vaunted attachment to extreme programming make a difference?

    Another thought along these lines is: perhaps the projects that fail often fail due to project management (in the most Bazaar sense of the word), rather than the usually heard competing time pressures, personality conflicts, loss of interest, and so on.

    • ESR wrote something about the similarities between "agile" development and what he calls "hacking" in his blog recently. While it is of course full of all the annoying "Look at me! I am the one and only authorized voice of the Hacker Tribe!" wanking and other brainfarts you would expect from one of his articles, there are some interesting points in it.

      It is currently the front story at his blog [blogspot.com]. I'd post a permanent link, but apparently the Galeon developers have decided that being able to paste URLs in t

  • If code is 'c l o s e d'...you can't read it to know if it is cleaner or not...if you can read it, then it is 'o p e n '...now get away from my desk so I can work.

    "How many times do I haf to tell you...if you don't want to take my word as proof that the light goes out when you close the refridgerator door, yer just gonna hafta climb in there and let me close the door so you can find our fer yerself!"

    How do you tell the difference between an open wound and a closed wound? - stiches....

    Close the door
  • Open vs. Closed (Score:2, Insightful)

    by ad0le ( 684017 )
    I have worked in the software industry for 5 years now and I tend to disagree with this articles view. Many closed source projects have horrid code that can be hidden by a "Closed" or "Proprietary" label. Open source is exactly that, "Open" therefore people who write the code automatically have "Big Brother" watching over them. Your coding practices is a direct view of your knowledge of the language and I know for personal experience that the open source code I have written was much better tested and revie
  • This is a M.Sc paper [ludd.luth.se] that tries to explain how the open source development is working. It's an interesting read.
  • by binaryDigit ( 557647 ) on Tuesday July 01, 2003 @07:48AM (#6338346)
    These OSS vs CSS comparsions are just the dumbest things ever. How can you take a couple of OSS programs and compare them to a couple of CSS and come to ANY conclusions? I've worked in places that have had GREAT code, the developers had a clue, and they had reasonable process (given the usual capitalist based time constraints). Then again I've been in places where the code is crap, the process is broken, and mgmt doesn't have the first clue. Now which view of CSS is this co. going to take, well I'd assume they'd use whichever one will make the outcome the way they want it to be.

    Fact is that they are looking at nothing but process and demographics. When you look at "bigger" OSS projects, then you'll notice a couple of things. They have a tendency to have their act together, because the project has been around and therefore has had time to get it's process together. Imagine an OSS project that had no clear "leader" or "leaders". One where anyone was allowed to check in code with review. What would you end up with, CRAP. Now imagine a CSS that had regular code reviews, where developers actually unit tested their code, and where QA depts had their act together and had good test plans. Assuming a decent level of developer skill, you'd probably have a decent product. The the quality of the product is based purely on the process's put in place to ensure that quality.

    BTW, if I see one more post about "many eyes", I'm going to puke (oops, too late). Those who write that pie in the sky crap don't really seem to have a clue about any real development. Sure it CAN be true, but I highly doubt it typically is. If that was the case, if the "magic" of OSS were so clear cut, then damn, OSS should be as close to bug free as is attainable, which OBVIOUSLY is not the case. You work on some code, you get it to work, you move on, period. OSS, CSS same thing. Someone else probably isn't going to bother with it unless it is A) broken B) too slow C) needs a new feature.
  • MS source code (Score:3, Interesting)

    by m00nun1t ( 588082 ) on Tuesday July 01, 2003 @07:48AM (#6338347) Homepage
    I'm sure I've read here, and more than once, that people who have seen Windows source code (I believe many universities have access?) have generally described it as being very good.

    Hard to find references to it though - try searching /. for "Microsoft source code quality" :)

    Anyone got a pointer?

    • Pointers? I thought windows was done in VB!

      And is this "good quality" in comparison to other professional code or what the uni students themselves can do?
    • The NT/2K kernel probably is. I have seen Cutler's code from when he worked at Digital (source listings were easy to get then) and it was generally extremely good (Don't ask about his PL/1 compiler though). I don't think he would let his team members get away with much less even if he isn't writing it.

      However the kernel is just one part and unless you are writing drivers, you never see it as it sits behind the smoke and mirrors of many different (and not necessarily consistent) APIs.

  • by Chalst ( 57653 ) on Tuesday July 01, 2003 @07:49AM (#6338352) Homepage Journal
    Another explanation as to why open source might start out worse than closed source is Linus' "Release early, release often" maxim. It's meant to get the widest class of feedback as early in the development cycle as possible, but of course it bumps up the defect rate in early releases.

    Again, it would be interesting to see how open source projects that follow this maxim compare to ones that don't.

  • Remember 2.0? It became "stable" in 2.0.twentysomething, iirc.

    So this company is competing a development state open source software against "stabele" commercial software - and it's almost the same (did they ever hear about "Standardfehler" - how do you call them: Standard deviation?)

    Actually, this "result" is an advertisement for Apache, if any.

    P.S.
    One http-server I'd trust is fnord [www.fefe.de]. Last time it was featured on /., it didn't get slashdotted..
  • Software quality (Score:2, Insightful)

    by presroi ( 657709 )
    so
    #include <stdio.h>

    void main(void)
    {
    char *message[] = {"Hello ", "World"};
    int i;
    for(i = 0; i < 2; ++i)
    printf("%s", message[i]);
    printf("\n");
    }
    is free from errors. The Ratio of errors / lines is 0.

    Am I now a zillion times better than Apache with those lousy 0,5 errors per demimillion lines?
    • Am I now a zillion times better than Apache with those lousy 0,5 errors per demimillion lines?

      No.

      void main(void) is invalid ANSI C. The return type of main must be int.

      Cheers,
      Ian

  • It's always the Linux kernel, Apache, and Perl. Always. Every time.
  • Very seldom do you see a commercial entity really bust their ass trying to make their code as clean and elegant as possible. There's just no money in it past a certain point. Why the hell should they care if you can make it .2% faster by rewriting the i/o subsytem interface here? Not crashing is it? Then who cares?

    Turn it around to Open Soruce, and you end up with a whole hell of a lot of people just doing it for the hell of it. And yea, the initial products are probably sloppier than a lot of commercial code, and a lot of that code ends up on the metaphorical scrap heap. But the stuff that is good, the stuff that's really cool, suddenly you've got dozens of people going over the code. Everyone wants to be on the developer team. Everybody is reading through it, scratching their heads and offering little improvements. That's the thing about Open Source.
  • by cacheMan ( 150533 ) on Tuesday July 01, 2003 @09:03AM (#6338808)
    When you are comparing code against closed source code, you must consider that most closed source code has hard time deadlines. There is rarely any cost benefit to revisiting code and cleaning it up.
  • The story on Cnet is a puff piece that's advertising for Reasoning. "We do code analysis, and we found that OSS is as good as proprietary software. Want to know how your code stacks up?" By repeating it here, Reasoning gets more exposure for stating something everyone here knows anyway.

    Way to shill for free, /.
  • by Jouni ( 178730 ) on Tuesday July 01, 2003 @10:18AM (#6339360)
    Unfortunately, with the *quality* of code being separate from how it looks, a lot of time is often spent polishing in the wrong places.

    Many times, this results in bad code crystallized into finely polished and chromed pieces of garbage. Which, incidentally, makes it also more difficult for others to change or refactor it, lest they make it "less pretty".

    I believe it's better for the quality to show the code, in general, but how about trying to formalize code review and other better-coding-through-groups practices with sites like SourceForge?

    Jouni

  • by Marc Slemko ( 6200 ) on Tuesday July 01, 2003 @11:57AM (#6340350)
    First, they ran it on 2.1-dev code as of 1/31/03, which is some time ago now.

    They found 31 supposed "defects".

    29 were null pointer dereferencing, 2 were uninitialized variable use. You got it, they don't do any analysis of defects much more complex than a good compiler may do.

    After looking through a handful of their supposed errors, many of them are pure crap because their tool isn't smart enough to figure out that a variable really can't be null.

    Their analysis also doesn't consider the fact that subroutines may have APIs that are guaranteed to return certain things, so not checking for null is perfectly legitimate.

    Bottom line is this is a company with a fairly primitive product trying to get advertising; some fraction of the alleged defects are actually bugs, most most of them are of a very very minor nature and many of them don't really exist at all.

Your own mileage may vary.

Working...