An Update

[Matthew S. Hamrick]

D'oh!

I forgot to credit Dick Gabriel (of Lucid fame (or infamy, depending  
on your opinion of Lisp and C++)) for the concept of how important  
evolution is in software development.

He's penned a number of very interesting papers, available at his  
site:  http://www.dreamsongs.com/Essays.html

-Cheers
-Matt H.

On Apr 2, 2007, at 12:38 PM, Matthew S. Hamrick wrote:

> 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
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community