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