Subject: FSBs' real competitors are consortiums (was Re: ... maintainership)
From: Tom Lord <>
Date: Mon, 11 Feb 2002 14:39:06 -0800 (PST)

       Forrest writes:

       This business B sounds like a nice company to work for.  But
       your analysis dismisses most of the barriers to competition
       that Business A uses to maintain margin, and did not replace

A very important observation, though it isn't accurate to say that B
does not replace the old barriers with new.  Yes, business B gets rid
of some of the barriers that keep business A going, but B adds new
(and better) barriers of its own.

Business A has barriers like "the public software is poorly tested: we
make up for that" and "the public software is poorly release
engineered: we make up for that."  "There's no automated distribution
mechanism for the public software: we provide one."  Those are
schizophrenic barriers for an FSB to rely on because they impede the
multipliers of collaboration.  They even give FSB employees a
_positive_incentive_ for doing some aspects of their work on public
projects in a shoddy manner.  Moreover, those barriers are only equal
to a couple of hundred people, at most -- so they aren't even very

Business B recognizes that those barriers have straightforward
solutions.  Not only will eliminating them improve the productivity of
the collaborative efforts, but it also is a big win for some emerging
large customers of free software. Rehearsing the list once more:
Compaq, HP, IBM, Sun, telecom, big-IT, et al..  Those markets are
turning to free software as a way to fight a war on microsoft and as a
basis on which to invent and deploy the next round of Internet and IT
infrastructure.  I don't think such customers have more than a small
amount of patience for branded distribution mechanisms or a QA team
with well under 300 people: they're trying to overcome the limitations
of teams that size (and even a bit larger) that characterized
proprietary unix solutions.  Those customers will drive the business A
barriers away, one way or another (e.g. look at the "carrier grade
Linux" initiative at OSDL).

The new barriers in B are all about expertise and networking.  Given a
big library of public components that can be assembled in many ways to
"solve" a particular problem, it takes experts to design, deploy, and
maintain a solution to fit a particular customer's needs (and even to
help customers fully understand those needs).  Given an intersection
of multiple computing-influenced industries that need to develop
novel, complex solutions in a coordinated way (e.g. for various kinds
of communications convergence), it takes experts to work on and
communicate the design and implementation problems from a neutral
stance, and to carry on that work simultaneously in two contexts: with
the customers, and with the free software developer community.  Really
three contexts: there's work to be done with existing standards
bodies, too.

	 How does business B get revenue, and how does it maintain

I doubt that custom development contracts, standard support,
FSB-hosted web services, education services and the like will ever
entirely disappear -- but I do think they will eventually wind up
being the minority revenue source: a purely tactical service (like
grounds-keeping compared to landscape design).

From the big customers listed above, revenue will come in the form of
big, simple retainers, large enough to cover the expenses of a
fully-staffed engineering team, customer visits, speculative R&D, and
ancillary activities (e.g. micro-conferences and programming contests
to reinforce open source processes; business analysts to help study
and continuously quantify the value being returned to customers and
industries).  The skill required to execute effectively and seriously
for these customers is high, and the value of what they're working on
astronomical -- so a standard premium margin for the best brands is a
fair deal all around.

(With individual consumers, the retainer model doesn't work without
modification, but if you impose intermediaries between individual
consumers and the FSBs, those intermediaries acting as purchasing
agents, then the model does work.)

	Assumably the only reason they are in transition is due to
	market pressures.  

The overarching market pressure is the need of the emerging big
customers to have a large, coherent engineering process working on the
public software.  That that pressure will cause something to give is a
technical issue: distributed testing, release engineering,
working-group design processes, and other aspects of the Business B
world are not rocket science.  If the FSBs don't do it, we'll see a
return to the consortium model of the 80s in a big way -- only now
they don't be squabbling over licensing or keeping the core
development teams starved because, with little experiments, those
customers have figured out how to do open source processes for

	Can you explain those pressures in each point?

There are a lot of interesting bits in your point-by-point reply.  I
think I've covered the high-level response above.  The detailed
response to many of your points would involve lots of talk about
specific engineering practices.  Feedback a couple of months ago was
that lengthy and detailed discussion of engineering, even though I
happen to think it is a central issues for FSBs, isn't welcome on this
list.  Anyway, those details would be more like part of my job than
part of my PR :-).