Opensource Code More Refined Than Closed?
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. ."
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.
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 :-)
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.
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. 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.
Search 2010 Gen Con events