Re: Tim's paradigm shift

>>>>> "Matt" == Matt Asay <[email protected]> writes:

    Matt> And it doesn't explain why MySQL has been so successful.
    Matt> They employ 100% of the code committers to MySQL - no
    Matt> architecture of participation (unless you count QA, and that
    Matt> does count).

MySQL is successful because it's a good product within its
limitations, and does what a lot of people with similar needs, and the
ability to generate revenue to pay for the product, want it to do.
(This is practically definitional.)  Products don't need to be best of
breed across the board, nor do they even need to be best of breed in
their niche.  They just need to meet the customers' needs.  For that,
the QA is probably more important than the code, until somebody comes
up with a product that addresses unsatisfied needs of the mainstream
of MySQL customers, no?

Maybe you should be looking at MySQL marketing practices, and their
RFE-to-release turnaround, rather than engineering per se.  Figure out
how they convince people that MySQL will do the job.

Another thing: we're developers (yeah, even us econ/biz professors),
when we hear "architecture of participation" we think "patch queues"
and "Linus's lieutenants".  I'm not sure that's what Tim was thinking
of, and I'm definitely sure that his killer apps all had participation
by _users_, not by developers.  Maybe MySQL is successful because
there are thousands of MySQL HOWTOs, and lots of little recipes for
making this or that work, and all indexed by Google next to "PHP" so
you can throw up a page in seconds to see how it looks and feels.

    Matt> If few actually look at source (and the fact is, very few
    Matt> end-customers actually do - Microsoft pegs the number at 1%
    Matt> who expect to modify source if they had access, and I've yet
    Matt> to see numbers or experience that widely differ from this,
    Matt> especially since anyone modifying RHAT or NOVL source (or
    Matt> others) would immediately violate their support contracts
    Matt> and be left stranded.  Few Fortune 1000 companies are going
    Matt> to take that risk),

Is it really that big a risk?  That's a real question, I don't pretend
to know the answer.  The logic is Yes, if push comes to shove and
you're going to cost RHAT a million dollars to fix one bug, and nobody
else cares, they'll pull out the fine print.  But if it's going to
cost RHAT $50 to fix it, I don't think they're going to risk p/o-ing a
Fortune 1000 customer.  OTOH, even with pristine source if it's going
to cost RHAT $10^6 to fix something, surely there are plenty of ways
to spend 1/10 as much money, trying as hard as they can while still
meeting other commitments (and did I mention spending only 1/10 as
much money?)

But that's a peripheral issue.

    Matt> then one is left wondering what, other than low cost (as in
    Matt> acquisition cost), is driving open source adoption by
    Matt> corporate customers.

Lock-in, spillovers from other eyes looking, of course, as several
have suggested.  One that I didn't see mentioned directly is that
software is a system, and most components are poorly documented in
places.  Eg, X11 and Motif and GTK sources are one of my biggest
assets as an XEmacs developer, even though I have no intention of
trying to fix them, and in many cases the toolkit developers would
surely argue that XEmacs is buggy, not the toolkit.

Availability of source for the platform, even if it's immutable
because of support contract, is (I suppose) going to make FLOSS (a)
more reliable and (b) easier to integrate 3rd party/inhouse software.

Finally, these days the splashy developments are often based on FLOSS
somewhere.  Google with thousands of Linux servers, Amazon, etc.  I've
heard of a couple of inhouse versions of XEmacs (one guy said "sorry,
if I showed you the code, I'd have to hire you" but unfortunately the
VP of IT had already nixed that idea :-P ) which are apparently
considered relevant to "core competence" (though not "mission
critical" AFAIK).  So even if penetration to the corporate desktop,
and even mail/file servers is relatively small, I wonder if the
mindshare for "this is where cutting edge stuff happens" is maybe
starting to grow for FLOSS.  "We're going to need Linux capabilities
in order to develop mission-critical systems for the next phase,
Windows is not flexible enough at the level we need" kind of thing.
Pure speculation, of course.

I'm surprised Jean Camp hasn't weighed in on this yet.  I would
imagine that there must be case studies etc available on software
adoption, including (these days) the FLOSS v. proprietary industry
leader decision.  A direct query to Jean might be in order.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.