The open source community has a saying: With enough eyes, all bugs are shallow. When enough people look at a piece of code, someone is going find and fix the bugs.
A related principle is that with enough users, all bugs will be reported. With enough people use the software, someone else is going to run into the problem. Someone will report it. Someone will talk about it in an online forum. Someone will blog about it and post a work-around until the bug is fixed. This principle deserves more attention; it’s not cited as often as the shallow bugs principle.
Ideally, you want to use software with lots of eyes and lots of users. Firefox is an open source product with lots eyes and lots of users. But more often you have to pick eyes or users. You have to choose between open but obscure software and closed but popular software. Open source projects may have more people looking at the source code, and so they have the “many eyes make shallow bugs” maxim working for them. But the user base for many open source projects is tiny compared to their commercial counterparts. The number of users to find and report bugs is small, and the number who document fixes and work-arounds is even smaller.
I’m not ideologically attached to open source or commercial software. I use both. I just want my software to work. And when it doesn’t work, I want to find a solution quickly.
Find yes, fix no. I was thinking about your post about the success of some open source projects and R was mentioned. R has worked as open source as it is relatively simple. One of the problems with open source is that it is always going to be difficult to build complex software, the sort of thing that requires a solid foundation. If this isn’t done correctly from the start it is almost impossible to build software that works properly.
But in some fields, like development, open source products are both: open and the ones with most users.
Take for example programming: PHP it’s the defacto programming language, I don’t like, try to don’t use it, but it’s a fact that is the most common programming language, sames goes for a database, MySQL it’s widely more used that SQL Server or Oracle counterparts. And Firefox it’s growing in userbase (it’s still not #1 but it’s going that way).
The problem with “with enough users, all bugs will be reported” it’s that it doesn’t gives user a chance to fix their bugs, I don’t mean the user itself but there are features en comercial, closed source products, with years (I can say decades now) that aren’t implemented, and that the open source equivalent already has it.
That’s terrific when you can find open software with lots of users. LaTeX is one of the best software applications I use. Many people use it, many people have studied the source code, many people contribute to discussion forums etc. LaTeX is solid as a rock.
But I doubt users fix their own bugs very often. Certainly it happens sometimes, especially with software development tools. And when it does happen, people talk about it, so we get an exaggerated impression of how often this happens. I wonder how many people have tried to fix bugs in open software and made things worse by editing code they don’t fully understand. When that happens, they don’t blog about it.
Bugs of omission begin in the requirements. But, since we don’t begin in the requirements, you can’t say that, although it is still true.
Bugs of omission begin with the notion that whatever is being coded is known to the programmers. This is utterly false. Programmers know their carrier content. Programmers do not necessarily know their carried content. Programmers in data processing shops might know their carried content. But, there is a dependence on expecting a user to know their carried content and to know its implicit knowledge. This goes even further because we expect that user to be a teacher of their implicit knowledge. They forgot most of that, their struggles. Someone had to clue them in, but once clued in they ratchet up so they forget what they didn’t know when they were butting their heads against the wall. Who remembers pain?
I once took what looked like a bug to me to a programmer. He had used radio buttons when he should have used checkboxes. I had a dependency, otherwise, it would have been entered into the bug tracker. When he looked at it, he had omitted choices. The underlying infrastructure had changed since he wrote that feature. So even carrier functionality gets omitted.
We need to go back to the underlying cognitive model and start building from there, but we start somewhere else, somewhere in a 101 intro class to the underlying subject. That 101 class is a long way from competence. Most of our software is surface.