Wednesday, 11 October, 2000
Open Source Software
Almost everything I've said publicly about Open Source software has been negative, or at least appeared that way to most people. I've gotten the reputation of being anti-Open Source. But I'm not. I actually want to see the Open Source movement succeed. But unlike many Open Source fans, I also believe that there is a place for traditional closed-source software.
I like Open Source. What I don't like is the way I see much of the software being developed. The theory is that Open Source makes for better software because more eyes on the project means a better chance of finding and fixing bugs. But coding and debugging are not the most important parts of a software project. A program that requires hundreds or thousands of programmers running it and examining the code in order to ferret out bugs certainly wasn't well-written, and probably wasn't designed well. If a program is running, there's no reason for it to have that many bugs. A running program with that many bugs has serious design and coding problems, and no amount of bug fixing will make it better. In this regard, the Open Source development model is no different from most traditional development. Programmers hack away until "it works," and then QA departments, beta testers, and customers bang on it to ferret out the bugs. If Open Source has any advantage in this area, it's only because the QA department is larger and there's no set release schedule.
Few of the Open Source programs I've seen were actually developed as Open Source. Most appear to have been developed by a small group of people working closely together, who released the program as Open Source only after it was mostly complete. The design of the program and the majority of the implementation was done by a few core individuals. This is true of the original Apache web server, Samba, the Linux kernel, Emacs, and almost every one of the GNU utilities. I know that these programs have subsequently been extended by countless others, but their cores are the work of small, tightly-controlled groups. Adding a module to a solid design is much easier than creating the framework that allows modules to be added. The "million monkeys" approach to software development, which is what the uneducated parrots who make up the most vocal part of the Open Source community advocate, just won't work.
It wouldn't take much to make Open Source software better (technically) than most of the commercial software that's currently available. All we need do is concentrate on solid engineering principles (overall system design, proven high-quality coding practices, and good project management), and good user interface design. Unfortunately, most programmers have yet to embrace even one of these principles, and the Open Source model as it's understood and practiced by the masses makes it very difficult to enforce them on the participants.
I have little doubt that the Open Source movement will continue to grow, and the number of high-quality Open Source programs will increase. Open Source could replace traditional closed-source development, though, if somehow we could educate programmers in and enforce the best practices that are keys to any successful software project.