Subject: Re: I wonder if Craig Mundie reads this list
From: Tom Lord <>
Date: Tue, 5 Mar 2002 20:38:02 -0800 (PST)

   From: Brian Behlendorf <>

   On Mon, 4 Mar 2002, Tom Lord wrote:
   > [Mundie's] fallacies:
   > 1. The presumption that "ancillary manufacturing or services"
   >    necessarily can not earn the profits that are possible with
   >    proprietary licensing.  (We on the list all seem to agree that
   >    that's true for the services being sold today, but don't all
   >    agree about the possibility of new kinds of service that overcome
   >    that limitation.)

   Speaking in absolutes in either direction isn't useful.  Looking at case
   studies is better, and trying to get quantitative is best.  There are very
   few companies who i) spend significantly on the production of new open
   source software, ii) release only open source software, and iii) are

   We know of a few, but they make up a statistically
   insignificant amount of the cashflow of the IT industry.  It would be
   unfair of Mundie to call it impossible to create such a company - we have
   existance proofs - but to call it "almost impossible" might not be a
   stretch.  It's also almost impossible to win a gold medal in the Olympics,
   and it takes rare talent, but people still try to do it.

Your empiricism is too narrowly focussed.

I suggest trying to conceptualize the IT industry this way:

First, ignore all business transactions. [Cheap-shot, baiting,
condescending, I-think-i'm-insulting-him-over-his-head replies, be
sure to quote that line out of context!  We will all admire your

Instead, think only of the analysis of needs, the communication of
requirements, the engineering of software, the deployment and support
of results.  You might also think about the R&D that raises the bar
and extends the possibilities.  Think of these things abstractly,
without concern for organizational boundaries, contractual
obligations, software licensing, etc.  In other words, essentiallize
them to just the engineering problem.

Imagine the graph of people and communication paths in which that
engineering takes place.  You can think about the actual graph
implemented by particular companies.  You can think about ways to
improve that graph (again, momentarily disregarding the business
transactions).  You can try to come up with an ideal graph, though I
think that finding a unique, provably optimal graph is necessarily

Now, play with that graph in your mind until you get it into a state
that makes good sense, given all the best information you can gather
on, for example, research into the problem of software engineering.
Have some idea how it should look?  Ok good.

Now, here's the FSB homework problems: 

	1. Monetize that graph.

	   Make up kinds of transactions that can implemented by
	   contracts that could cover that graph, be in accord with
	   the informal practices of all the people involved, and pay
	   all the salaries and other costs needed for that graph.
	   (10 point bonus: use only the GPL in your proposed

	2. (extra credit)  Plot a Tactical Path from the Current Real
           World to the One You Just Designed.

Pretty much every non-trivial message I've ever posted to this list
comes out of my answers to those two homework problems.  

   > 2. The presumption that investors, not customers, ultimately pay for
   >    R&D (exploitation of stock market bubbles not-withstanding).
   >    Service based, rather than investment based funding models for R&D
   >    are potentially more efficient and more effective.

   Control of a company by its investors is exercised by the board of
   directors.  Money spent on R&D is money that is not distributed as profits
   to shareholders, except when that R&D is funded as time-and-materials to
   the customer (which usually means, unless you craft it right, that the
   customer owns the copyright).  While Cygnus did/does have a successful
   business by charging hardware vendors to port the GNU compiler suite to
   their platform, it's not clear to me that funding-ahead-of-development can
   be a model to fund development of most or even much of the software that
   needs building.  Let me show you the battle scars from that crusade, btw.

Mine are bigger than yours :-)  I limp now, a little bit, even.  Really.

   > 3. His presumption that increasing use of publicly licensed software
   >    necessarily results in lower overall IT spending.  It might also
   >    result in similar levels of spending that yield higher quality
   >    results and faster progress.

   Bob Young was once quoted (Bob, sorry if I got this wrong, or you were
   misquoted originally): "I don't want to expand the Linux market to the
   size of the whole operating systems market.  I want to shrink the whole
   operating systems market to the size of the Linux market."  The comparison
   may have been between RH and MS, or some other combo - I can't

   I think we can't tell what effect it will have.  The only trend I've seen
   is companies who are being forced to make cuts looking for ways to cut
   that retains key employees and reduces outsourcing or capital
   expenditures.  So, a solution that means that existing staff is put to
   productive use is preferred over one that costs the same (realizing the
   real costs of headcount) but is more "traditional".  I think that trend
   more than any other has been the driver for the even more widespread
   adoption of open source in the enterprise.  People are sick of spending
   $500K on a big Solaris box & software when $30K of x86 gear & some Linux
   expertise can do the same, even if it means increasing a headcount or
   two to get the same result (or more typically these days, being able to
   avoid laying off one or two people).   It certainly means less IT money
   going to vendors, though.  I just don't know the statistical significance.

I think we are mostly thinking about different scales of operation.

I mean yes, sure, every organization at every scale is happy to spend
30k where previously 500k was needed; somebody gets a nice bonus for
that.  But for some critical market leaders -- trend and standard
setters -- both those amounts are insignificant in the overall budget,
and anyway, Moore pushes all those distinctions aside before very

No, this isn't, in anything other than a tactical sense, a price war.
Certain companies are increasingly twits for playing it that way.
This is a war over quality, tractability, flexibility, rapidity of
evolution, and longevity.  Get with the process, man ;-).