Aspects of Developing With, and Using, Open Source Software
I guess the cynical would say that open source is very good at producing Linux development tools! There is, I have to admit, some truth in this view. The open source movement has produced some excellent tools. However, this is by no means the whole truth. I suspect it would be more accurate to say that the open source movement is very good at developing reliable software. The open source movement's flagship products - Linux, Apache and MySQL, for instance - show very well how the system excels when it comes to reliability and responsiveness. Incidentally, a very important part of open source is the idea that because you have the source code you can fix/customise/tamper with it yourself. This is simultaneously true, and a myth! Of course, if you have the code, you can alter it and recompile it (assuming you don't make any syntax errors) and contribute the fix back to the project. Let's be realistic, though. How many people are capable of recognising (say) a bug in the Linux process scheduler? Come to that, how many people would even consider changing the scheduler code to 'fix' it? Most people would, I suspect be content with reporting the problem. So why is open source product so reliable? Well basically, putting a program into open source is the ultimate code review! If you are going to go into open source, you need to have good quality code to start with, and a skin like a rhinoceros as people comment on its quality. But, like all code reviews, it works. As one Eric Raymond once pointed out, "All bugs are shallow if enough eyeballs are looking at the code." I'm not so sure about this as I once was, but there is certainly a strong element of truth in it. I personally think that where open source really scores is not so much in spotting the bugs, as in fixing them once they have been reported. When a commercial product bug is reported there are immediate pressures for the owning companies to hush it up. And, since they are the only ones who can see the source code, fixing it has to wait until the company can spare the resources. When an open source bug is reported anyone interested can see it and if they feel competent to do so can submit a fix for it. You may have no one in the company who can fix it, but if you report it clearly there will undoubtedly be people out there who will fix it rapidly. In an era where bugs are often exploited immediately, via the Internet, timely fixes - preferably ones that don't break something else - are very valuable. |
If you have any questions or comments about the articles on my web site, click here to send me email. |