Slashdot Mirror
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.
You're new here, aren't you?
There's a Mercedes gap too. I want one and can't afford one, but it's not government's job to do anything about it.
"When more people can look at your stuff, you have a tendency to make it look nicer."
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.
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.
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. :-)
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.
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.
Programming can be fun again. Film at 11.
USB, DirectX 8+, Shell extensions, file location service, vastly improved PPP. Sure, nothing.
[Set Cain on fire and steal his lute.]
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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.
Quod scripsi, scripsi.
Win95-->Win98-->WinME--->WinXP is a case in point.
Nothing for a user in XP, that he can't do with Win95.
Not even considering that they are two 'completely different' operating systems, I can probably name at lesat 50 major things off the top of my head that you can do in XP that you cannot do Win95.
Should we start the list?
1.) NT Kernel Layer - Abstracts Win32 Kernel from OS, giving system stability, and the ability to add additoinal OS subsystems on the NT Kernel in addtion to the Win32 subsystem.
2.) NTFS - Journalled File System
3.) NTFS - Object Oriented Based file Security System.
4.) NTFS - File/Folder Encryption
5.) NTFS - File/Folder Compression
6.) System Restore Protection
7.) OS Self Repair and File Protection
8.) DLL abstraction (multiple DLL instances in memory)
9.) Increased Boot & ShutDown Speeds
10.) Suspend to Disk Hibernation
11.) Full ACPI support with Scheduler with Even Scheduler - Wake Up Support
12.) RDP - Remote Desktop
13.) Telnet Server
14.) FTP Server
15.) IIS Server
16.) Application Crash protection that catches bad Memory and API calls in Real-time and prevents application crashes without the user ever knowing it is happening.
17.) POSIX supported naming conventions
18.) NTFS - HardLinks
19.) NTFS - Mount Points
20.) NTFS - Reparse Points
21.) DFS
22.) NTFS - 16exabyte Partions
23.) 4GB of RAM Access - 64bit Desktop 16GB RAM - Server 64GB/512GB RAM
24.) Native CDR-CDRW Support
25.) Intellimirror
26.) Offline Network Files & Synchronization
27.) ZDLabs reports 27 percent faster than Win95/Win98 with more than 64Mb of RAM
28.) Internet Connection Sharing
29.) Basic Firewall (Built In Firewall mechanisms for third party Firewalls to directly Plug In)
30.) Full Unicode Support
31.) Mutli-Processor Support (2 in Professional - 32 in Server)
32.) IPSec
33.) Smart Card Support
34.) Built in WiFi and UPnP
35.) Native Multi Monitor Support
36.) ClearType Throughout the OS
37.) Remote Assistance
38.) NLA
39.) Full VPN Support In & Out
40.) Driver Rollback (Windows Protection)
41.) Network Bridging
42.) Web Folder Support
43.) Fast User Switching
44.) WMI
45.) Group Policy (Local & Active Directory)
46.) Enhanced Power Management (Supporting CPU Throttling in addtion to other device Power control for improved Mobile battery Life)
47.) Kerbos
48.) IPv6
49.) Qos
50.) Volume Shadow Copy (Shadow Volumes - Versioning on Server)
That is just 50 'technical' things I could pull off the top of my head.
Should we also list another 100 other items that are in the UI of XP like common folder tasks, photo printing, built in Zip Folders, Image Acquisition, etc?
"Yeah, there sure is not anything in XP that a Win95 user can't do." - Said the person living in a cave.
You can easily spot the people that either do not get this stuff, or just have not used XP and only base their experience on the time they used Win9x and the FUD they read about XP.
In addition, as I said before, I also use OSX, Mac System 8.1, Mandrake, FreeBSD, Solaris, and Redhat everyday, so I am not a sold MS XP zealot by any sense of the word.
Nevertheless, saying that XP does not offer a user anything more than Win95 is just ridiculous.
Geesh...
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