Given enough eyeballs make all bugs shallow login
There's only one problem: in real world you don't have enough eyeballs, therefore the argument remains purely theoretical.
Here's a little story: I found an interesting (judging by screenshots), open-source software meld (which is a GUI for CVS). It only runs under Linux so I fired up my RedHat 8 (a mainstream Linux distribution) and tried to run it. I've downloaded the sources and tried to run it but failed because it depends on pygtk that I didn't have installed. Looking for rpms for obscure packages is usually a waste of time so I just grabbed the latest sources for pygtk, compiled and installed it (at which point I did something that a majority of users isn't capable of (and they shouldn't be)). Then I run meld:
[kjk@localhost meld]$ ./meld Segmentation fault (core dumped)
Which basically says that there was something wrong with the software. I'm a software developer by profession and I'm capable of fixing the problem, whatever it might be. Segmentation fault is usually caused by trying to access memory you're not allowed to access and, if you have things set up properly, you'll get dumped into a debugger in a place in the program exactly where the problem happened. From that it's usually simple to look up the callstack, see the sequence of calls and figure out why you're playing with invalid pointer. The thing is: I won't bother. This software is not crucial for me, I can live without it. If I had a machine set up for debugging, had everything compiled with debugging symbols and assuming that the debugger would work (which is not given at all, for a long time gdb didn't support threads) it would probably take me a few hours to figure out the problem in the code I see for the first time. But I don't have this so it would take me a few days to get to the point I can start useful debugging. So I give up without thinking.
In real life:
- your environment isn't comfortably set up for immediate debugging
- getting started on any software project of decent size has a steep learning curve; in practice this means that no-one will do that just to fix a bug - too much work for too little gain
There's no argument that having the source is better than not having it but I argue that, with a few exceptions, it doesn't change the quality of open source software because no-one bothers to look at the source and contribute small fixes. Just look at any open source project that isn't Linux or Apache (those are 2 examples of very few exceptions) - they are all desperately (and mostly in vain) looking for contributors.
|« On difference between amateur and professional shareware||•||Is software industry a place to be - Greenspun perspective »|