An Update

[Matthew S. Hamrick]

Depends on the development model. Peter Naur has an interesting take  
on software development, which I paraphrase... The software that's  
released is an artifact of the true value of the organization; the  
ability to efficiently communicate models in the problem space  
amongst the people that are building the solution. [1] My personal  
take on the famous "shallow bug theory" is that successful open  
source projects built by a lead user[2] community tend to be  
structured in such a way that the highest payoff problems are the  
ones most efficiently modeled. In other words, people select models  
and tools for communicating problem descriptions in such a way that  
refinement of the problem space appears very rapid. From an outside  
perspective, this looks like "a bunch of eyeballs fixing a bunch of  
bugs, some of which are serious"

Baldwin, et al. have pointed out that Conway's Law [3,4] applies to  
open-source as well closed-source software.[5] (Conway's law is, as  
the great oracle of the Wikipedia puts it, "Organizations which  
design systems are constrained to produce designs which are copies of  
the communication structures of these organizations.")

So my assertion here is based on observations by Naur, Conway,  
Baldwin, von Hippel, &c... Corporations that view their value as  
being derived from the software they produce are bound to produce  
processes that are less efficient at developing software that meets  
the needs of lead users. I believe this to be the result of interplay  
between software components, requirements and "value extraction."  
Commercial software vendors are rewarded financially by creating  
systems that lead to lock-in: systems that make it easy to change  
from the competition and hard to change away. Lead users are rewarded  
financially by producing technical solutions that solve their  
immediate problems.

(Commercial) software implementations that lead to "lock-in" are less  
attractive to lead users over the long term because once a lead user  
is locked in, the commercial entity supporting the user is less  
motivated to provide a "cornucopia of options" for the lead user's  
next problem. Commercial software vendors know that their systems  
have real costs for users migrating away from their products, and  
therefore have to produce a lower quality experience because they  
know that their customers know that there are costs associated with  
switching implementations.

Many open source components do not have this requirement. If they are  
to be used, they must continue to be useful in the long term, lest  
they fall by the wayside (FreeSWAN comes to mind.)

To recap:

Lead users are individuals with a financial motivation to use  
technology to solve a business problem. Lead users' problems are  
often unique to their organization (or even to individual users.)

Corporations attempt to build "short head" products in an effort to  
reduce the per-transaction cost (i.e - you want to spread the fixed,  
NRE costs over as many widgets as possible to drive down marginal  
costs so you have the option of lowering price (to compete on cost)  
or increasing margin so you have more money to pour into R&D so you  
can compete on features.)

Corporations who make software toolkits evolved a strategy of  
increasing market-share via "lock-in." (Market share is important if  
for no other reason than when it's time to justify your P/E ratio,  
you can point to lock-in as a way to capture revenue for emerging  
markets. e.g. - "Smartphones are big business over the next 10 years,  
and now that we've cornered the Smartphone market, we're sure to  
capture 70% of the revenue.")

Corporations are motivated to spend money on adding features  
attractive to new user communities (in order to increase market  
share) but sometimes less motivated to spend money on adding features  
for existing users communities who have changing requirements  
(because they know that the benefit of a competing solution minus the  
cost of a competing solution must exceed the benefit of their  
solution plus minus the cost of their solution AND the cost of  
changing to the new solution. I call this the "what do you mean you  
don't want to adopt Cobalt?" effect.)

Open source projects maintained by lead users that survive are those  
whose benefit cost minus adoption cost is greater than that of other  
open source or proprietary implementations; AND whose architecture  
supports low cost modification to meet the next generation of lead  
user requirements.

That "given enough eyeballs, all bugs or shallow" seems to have some  
truth is less a statement about the process of finding bugs with a  
bizillion open source developers and more about the fact that the  
source bases whose architecture makes expansion and debugging easy  
have an evolutionary benefit in the darwinian competition for mind- 
share.

I think it also explains why open source projects can be only 80% as  
good as the last guy needed them to be and still be competitive with  
some proprietary implementations. [6]

-Cheers!
-Matt H.

References:

1. Programming as theory building. Microprocessing and  
Microprogramming 15, 1985, pp. 253-261
2. The Sources of Innovation and Democratizing Innovation (by von  
Hippel, available at http://web.mit.edu/evhippel/www/books.htm)
3. http://en.wikipedia.org/wiki/Conway%27s_Law
4. http://www.melconway.com/research/committees.html
5. http://www.people.hbs.edu/cbaldwin/DR2/BaldwinArchPartAll.pdf
6. Lefty's Law : "Open Source : 80% as good as the last guy needed it  
to be."

On Apr 2, 2007, at 7:28 AM, David Schlesinger wrote:

>
>> ..."Given enough eyeballs, all bugs are shallow."
>> I wish there were a way to apply this to hardware,
>> without the costs being astronomical.
>
> Unfortunately, this turns out not to be completely true, even for
> software. Given enough eyeballs, most localized programming errors are
> fairly shallow, but things like race conditions, etc., can be quite
> impenetrable, even with numerous eyeballs to call upon...
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community