Revisiting the many eyes theory

1 points by arca_vorago 11y ago ↗ HN

For a long time I have mentioned my main issue with FOSS/open-source development as it relates to the traditional Cathedral and Bazaar models. Eric Raymond's main point, as most of us know, is: "given enough eyeballs, all bugs are shallow."

I no longer think this is true, if it ever was. I would like to propose an alternative, more correct statement about the shallowness of bugs.

"The simpler, smaller, and more readable code makes most bugs shallow."

Or, more frankly, "Modern code is too voluminous for there to be enough eyes to keep Raymond's theory working in practice."

As we have seen with the PRISM revelations and multiple security issues recently such as shellshock, heart bleed, etc, much of what comes to mind is that there simply aren't enough eyes available to review code for bugs or other issues, and to me the only way we will ever get past this problem is to reduce code complexity and size.

The example I often use in conversation is that the linux kernel is at over 10 million lines of code now. No single entity could ever hope to fully parse all of that. As a counter-example, Minix 3 is at ~10k lines of code. (not a perfect comparison, granted)

What do the readers of HN think about this issue? Is it even possible to reduce code bloat in such a fragmented bazaar model we seem to live in? What can be done to reduce code size and complexity?

1 comment

[ 3.3 ms ] story [ 13.4 ms ] thread

deangiberson 11y ago ↗

I think these are two overlapping non-linear functions, the intersection of the two is a minima.

"Many eyes" worked for a while but the benefits were lost as scale increased. You are saying that we need to focus on reducing code size. This other extreme is many small unrelated pieces of small functionality, which also breaks down. You would just have a bunch of small programs, some of which are ignored. The complexity remains constant.

Software inspection has shown to have good benefits, this is the heart of "many eyes", the trick is getting coverage. "Many eyes" worked when applied against small enough problems for self organizing groups. As you hint when you say "Modern code is too voluminous for there to be enough eyes to keep Raymond's theory working in practice." Isn't this a management issue? A problem of getting enough people to look into the dark corners and communicate the results?