Subject: Re: FSBs' real competitors are consortiums (was Re: ... mai
From: Tom Lord <lord@regexps.com>
Date: Fri, 15 Feb 2002 02:28:20 -0800 (PST)


   Forrest:

   Tom, what are the traditional effects of applying any labor saving
   technology?  I think you are focusing on how business A internals
   change.  You have not described how the whole business
   environment (competitors, etc.) changes with that same technology.

I think I have, but I don't mind rehearsing a little bit more.

This isn't about "labor saving", it's about "productivity increasing"
with a consequent qualitative shift in the problems to which labor can
be applied.

For the transition from "A" to "B", for patching rather than
making-up-for the deficiencies in current open source processes,
there's new work (with customers for that work) to be done: namely
beefing up the tools and processes and deploying them in the public
projects.  After a transition to business "B", there's different work
to be done: namely, architecting and helping to implement a lot of
needed systems (which I've named in past messages) and implementing
processes by which that architecting and implementing effort becomes
a lasting part of the services offered to customers.

   If Big Business B isn't doing as much work as it used to, (because
   it gets done in the public) then that means that smaller
   businesses can go where only big businesses used to go.

The latter part, that smaller businesses gain access to the business
"A" spaces, is true -- the former part, that "B" isn't doing as much
as it used to -- isn't.  Business "B" has bigger fish to fry.

The activities that we're talking about taking away from "A"-type
businesses, things like testing, source management, and release
engineering -- those are no-brainer fundamentals from the high-end
closed-shop perspective.  We're ultimately talking about a shift in
which the public projects become much less, well, amateurish (and I
hope people can read that without taking offense).  I think that shift
is inevitable, now that certain companies have arrived upon the scene.
In a few years, there won't be much qualitative differnce between the
distro you buy in a box and the one rolled by the bright high school
kid down the street.


   It also becomes possible for customers to do for themselves
   what it used to need suppliers to do.

Damn straight.  Customers need to be able to roll their own distros
and build their own confidence in those distros to complete the value
proposition of Free and Open Source Software.


   Communicating software requirements between organizations is high
   cost, for example.  With an in-house staff, priorities are better
   aligned and change synchronously, transaction costs are lower,
   markup is eliminated, (etc.)  How does Business B sell that they
   could know and service their customer better than the customer
   could itself?  What does Business B do that the customer could not
   do?

A few things.  One is to be the point of coordination by means of
which several customers share costs.  Another is to be the forum of
negotiation in which otherwise competing customers agree on de facto
standards (this applies, obviously, to GNU/Linux as the industry
standard unix-for-servers -- but there's other markets where it comes
up too.)  Another is to be a talent capacitor: some customers have
spikes in their need for expert software engineering and an
independent supplier, serving multiple customers, can smooth those
spikes out.  Finally, one of the surprise lessons of open source
processes has been that "synchronously" changing priorities of the
engineering staff is a way to miss opportunities -- open source fixes
that and a type "B" business creates the brain-pool where asynchronous,
opportunistic improvements can be reliably potentiated. (Even in the
eighties, before anyone even heard of open source processes, the value
of opportunistic development was recognized in the mythology of
"skunk-works" projects.)


   The way you have described it, Business B's unique "service" is
   tending to the public software garden. 

That's just a bad analogy and I'm not sure I can come up with a better
one off the cuff.  Larry Ellison recently quipped about open source
processes beating the "big machines" of proprietary unix companies (he
spoke specifically of Sun).  I don't think those big machines are just
gonna roll over and die, but it's the right idea: it is, in fact, the
experiment companies like Sun are embarking on.  Between here and
there is transferring many of the virtues of the big machines to the
open source world.

-t