Comment Re:Bugs are an error in the... (Score 1) 596
Bugs are an error in the process, not the code. If you find a bug, you need to find the process error that allowed that bug to occur.
Well bugs can be created at the code level, such as with typos or indirection mistakes, but otherwise I think your point is sound. I would still reword it to better apply TFA by saying it this way:
More interested observers ("eyeballs") can make flaws ("bugs") in every part of the development process shallow, not just code.
A more valid point can be made than what is in TFA by talking more about process transparency and documentation, in terms of making all those "eyeballs" more effective than they are now. TFA utterly fails to make any such points. Instead, they go on a diatribe against a hand-picked list of OSS projects, on the false assumption that any flaws in the example competing systems makes their own system better.
I think the counter-point to the "shallow" rule, that better applies to the claims here, is that projects that lack "eyeballs" (i.e. proprietary projects, which automatically lack transparency to the interested consumer base) leave open the existence of "deep bugs" at every process level. If any of the few eyes deigned worthy of access to the project misses those bugs, the ability of nefarious third parties to exploit these bugs after release goes up significantly. Lack of transparency at every process level, including code, means that these bugs will be exploited before helpful interested third parties can discover them (i.e. white hats). This simple fact about disparity in process transparency makes proprietary development inherently flawed, and the "eyeballs rule" is a method of simplifying the reasoning behind this fact.