Subject: Re: FW: Why would I pay for Ximian software?
From: "Karsten M. Self" <kmself@ix.netcom.com>
Date: Thu, 3 Jan 2002 19:29:46 -0800
Thu, 3 Jan 2002 19:29:46 -0800
on Wed, Jan 02, 2002 at 08:48:44PM -0800, Tom Lord (lord@regexps.com) wrote:
> on Thu, Jan 03, 2002, Bernard Lang wrote:
> 
> > If you go back to the "tragedy of the commons paper, you will see
> > that it does not apply to software ... very precisely because of
> > these qualities you mention that make it naturally a public good.
> > The tragedy of the commons occurs when the resource made public is
> > rivalrous.
> 
> The bits in a distribution are not rivalrous.  The "commons" is the
> engineering infrastructure which produces, maintains, and deploys the
> software, not the software itself.  

You're not being clear.  This engineering infrastructure isn't a
commons.  An arbitrary user can't lay claim to my own resources.  An
employer or client can hire my time.  I can volunteer it.  It cannot
simply be taken.  I have the equivalent of a fence and gate.  To the
extent that a shared network and communications structure exists, there
is a commons, but it has historically operated far below its theoretical
carrying capacity (Odlyzko argues that it will remain at a fraction of
same -- 20-50%).

There are few control points within the free software development
dynamic which are both rivalrous and which can have arbitrary,
effective, claims laid to them.  I doubt your premise, though frankly
it's sufficiently vague as to be meaningless.

> Proprietary software companies have figured out how to administer this
> resource.  FSBs, for the most part, have not.

Proprietary software businesses (PSBs) "Profit by", in some cases.  As
do FSBs.  In some cases.

> The problem seems to be that FSBs are selling what they know how to
> sell, and what their customers know how to buy and receive, rather
> than what they ought to be transacting over.  For what they *are*
> selling, prices are naturally low, so the engineering infrastructure
> becomes "over-grazed".  Some FSB execs even try to valorize this
> situation: arguing that underfunding engineering is an example of
> "focus".

The problem seems to be that some people look at the dot-(com|bomb)
phenomenon and roll all FSBs into the same rubric, while assuming that
the PSB model works.  The analysis provided by Mr. Lord is a wee bit
simplistic in this regard.

First, the most active, aggressive, FSB at the moment is IBM.  Which,
indubitably, sells what it knows how to sell, and what its customers know
how to buy and receive:  big iron, midsized iron, small iron, handheld
iron, and little itty bitty iron.   Software, boxed and otherwise.  And
services, services, services, services.  IBM's own "grazing grounds" are
known as Watson, Almaden, and RTP.  Well funded, certainly, but not
over-funded, methinks.

> FSBs sell things like boxed sets, custom development, and support
> contracts.  Those things have very limited value in isolation -- so
> FSBs have trouble collecting enough money to sustain the operations
> that should be going on behind those points of contact.




> Proprietary software companies sell the same items, but get to charge
> much more for them through licensing restrictions.  

Sometimes.

Microsoft does OK on desktop operating systems.  But BeOS doesn't.
Neither did IBM or Novell with DR-DOS.

Microsoft does OK on desktop office software.  But Lotus doesn't.
Neither did Corel, WordPerfect, or a fistful of other firms.

On the desktop, there's Microsoft, and a bit of table-scraps for firms
like Symantec (fixing problems that shouldn't be there in the first
place), some high-end apps (Photoshop, PageMaker, Quicken (though MS
Money haunts it).  Actually, I've been asking friends (as I haven't used
MS software or platforms for years), and that's about the size of the
list.

The story should be pretty clear:  there's Microsoft...and everyone
else.

Moving out of the desktop market seems to show a more competitive market
-- Unix servers, Mainframes, handheld, and embedded space.  There's some
clustering and consolidation, but not the unhealthy situation we've got
on the desktop.

My impression is that PSB matters a whole lot less than exploitation of
lock-in and market abuse.  Aside from Microsoft, there are  no  major
desktop software companies.  From an industry list of the top 100
computer companies by sales for 1998 (latest numbers I've got), there is
only  one  pure-play software company in the top ten, it's ranked number
ten, and that's Microsoft.  You have to drop to number 56 to find
another (Novell), then 63 (Adobe).  The other companies are largely a
mix of HW + services (e.g.:  IBM) or SW + services (e.g.:  Oracle).[2]

For more current listings, Software Magazine's Software 500 lists the
following among its top firms.  Revenues in millions.  I've flagged the
firms which note no services revenues[3]:

    #    Company                        SW Rev     Tot Rev    Service   R&D
    -    ---------                      ---------  ---------  -------   ---
    1    IBM Corp.                      $44,900.0  $87,500.0  37%       6%
 *  2    Microsoft Corp.                $21,591.0  $21,591.0  0%        15%
    3    PricewaterhouseCoopers         $17,300.0  $17,300.0  100%      N/A
    4    Oracle Corp.                   $9,328.6   $9,328.6   58%       10%
    5    Andersen Consulting            $8,941.0   $8,941.0   100%      N/A
    6    Hewlett-Packard                $8,734.0   $42,370.0  15%       6%
    7    Compaq Computer Corp.          $7,779.0   $38,525.0  17%       4%
    8    Computer Associates            $6,268.0   $6,268.0   21%       9%
 *  9    Hitachi Ltd.                   $5,900.0   $74,300.0  0%        N/A
    10   SAP AG                         $5,071.1   $5,146.0   61%       14%
    11   Sun Microsystems Inc.          $3,237.0   $13,150.2  15%       11%
    12   Bull Worldwide                 $3,147.0   $4,296.0   65%       5%
    13   Compuware Corp.                $2,148.7   $2,148.7   60%       4%
    14   Ernst & Young LLP              $2,000.0   $2,078.0   96%       N/A
    15   BMC Software Inc.              $1,561.8   $1,561.8   31%       25%
    16   EMC Corp.                      $1,554.0   $6,715.0   11%       9%
    17   SunGard Data Systems           $1,444.5   $1,444.5   83%       9%
    18   PeopleSoft Inc.                $1,429.1   $1,429.1   76%       23%
    19   Novell Inc.                    $1,272.8   $1,272.8   14%       18%
 *  20   Unisys Corp.                   $1,207.1   $7,544.6   0%        4%
    21   Cadence Design Systems         $1,093.2   $1,093.2   54%       20%
    22   NCR Corp.                      $1,090.0   $6,196.0   12%       6%
    23   Parametric Technology          $1,046.5   $1,046.5   49%       12%
    24   Keane Inc.                     $1,030.8   $1,041.1   98%       N/A
 *  25   SAS Institute Inc.             $1,020.0   $1,020.0   0%        30%
 *  26   Adobe Systems Inc.             $1,015.4   $1,015.4   0%        19%
 *  32   Autodesk Inc.                  $820.2     $820.2     0%        20%
 *  37   Symantec Corp.                 $728.1     $728.1     0%        15%
    38   Network Associates             $683.7     $683.7     31%       22%

Of the flagged firms, the following note software revenues as the bulk
of all revenues:  Microsoft ($21,591), SAS ($1,020), Adobe ($1,015),
Autodesk ($820), and Symantec($728).  I'm excluding consulting firms
(e.g.:  PW-Coopers, Andersen) whose "software" revenues are largely
associated with consulting services.  SAS's reported financials exclude
service revenues.  Only two of these firms (other than Microsoft) could
be considered to have a significant desktop presence: Adobe and
Autodesk.  The delta between them and Microsoft is 20 to one.

So, of the top fifty "software" firms, there are four which derive the
bulk of their revenues from software itself, for a total software
revenue contribution of $25.1 billion, 86% of software revenues from
 software  firms comes from Microsoft itself.

If you look out over the remainder of the SW 500, you'll find that a
typical organization has software revenues of $75 - $200 million.  By
this measure, Red Hat, as an exemplar of an FSB, is downright typical,
with revenues of $102[4]

Looking at the entire 500 list, one finds the following revenue
statistics:

   Max:   87,500
   Min:        1.6
   Mean:     840.8
   Mode:      40.6
   S.D.:   5,924.6

The model "write a program, sell 100 million copies, retire" pretty
clearly doesn't exist.  For the one company that can extend its leverage
over the field, it works.  For the rest of the universe, technology
means a lot of heavy lifting (hardware) or hard work (services), or
both.

Free or proprietary, pure-play software doesn't pay.  Unless you're a
criminal.



> That's OK though -- its just a facade.  The *value* customers get from
> the proprietary software companies is a relationship (and the
> customers know this and count on it).  Sales and engineering teams
> visit the customers regularly -- study their operations and needs;
> provide ad hoc advice and assistance.  They feed-back what they learn
> to the engineering organization.  

Yes, they do, don't they...

    MS struggles to discredit GNU/Linux
    http://www.theregister.co.uk/content/4/23518.html

    It's crucial that you get out there with your TSP/SE/MCS folks and
    do actual walkthroughs in your accounts. Ask open ended questions;
    find out what they're evaluating for both key projects as well as
    smaller, more tactical projects. Ask about the 'connector' pieces --
    you'll potentially find Linux in these areas.

...not that, to a certain extent, this isn't just good business.  It's
ominous when you're dealing with a criminal monopolist.

What's being provided is services, hardware, technology, integration,
and/or operation, in some mix.


> Would customers benefit from a new feature?  Nobody has to contract
> for its custom development (how inefficient!).  Rather, it gets paid
> for out of the general pool of license fees: customers get a heads up
> that its on the way, an invitation to help review the design, and
> finally it simply shows up in a future release.

This is actually largely untrue.  For minor feature additions to
existing, widely used software, yes, features tend to come out of
general requests.  However, there are two significant exceptions.

  - Significant features can be presented by customers themselves.  Not
    as requests, but as completed product.  Pivot tables in MS Excel are
    one of the more notable instances of this[1].  I don't know what
    other examples there are, but many features come from this route.
    From my background (SAS), a number of procedures were developed as
    user features or external programs (PROC TABULATE).

  - Funded feature development happens far more often than you'd think,
    particularly in enterprise systems.  Virtually any specialized
    industry feature was likely rolled out initially for a specific
    customer, then formalized.  Again, from SAS and Oracle, their
    "Clinical" products were initially developed for specific
    pharmaceutical clients.

The other issue is that feature selection is an indirect good.  As with
defense spending, insurance-provided healthcare, and commercial radio
music, the decisionmaking and use of the "good" in question are
divorced.  Additional features are driven by the needs or motivators of
the software company.  In competitive markets, this tends to work
relatively well.  In the absence of competition, feature lists tend to
be driven by objectives such as promoting or preserving lock-in or
monopoly status, as has been seen.



> One solution here 

Multiple.  Some good, some not.

> is to sell the relationship itself, not (usually)
> the products, the formal support, or each separate new feature or
> port.  

AKA:  Service plan, support plan, subscription, or sponsored
development.  Well-established practice, in both FSB and PSB sectors.

> Sell the mutual site visits.  Sell the informal, friendly,
> engineer-to-IT department email assistance.  Sell the newsletter that
> describes what's in the engineering pipeline and how it can have
> positive impact for customers.  Sell the data sheets that characterize
> the testing effort so that customers can use that information for risk
> assessment and planning.  Sell the right to review designs and
> participate in R&D.  

The problem with all of these suggestions is that they're of mutual
benefit, and denying ready access to them is ultimately harmful to the
(P|F)SB.  Information sharing, mutual debugging, and informal support,
all tend to provide benefits to  both  the vendor/developer,  and  the
customer.  Direct email assistance might be the exception, but in
general, I'd discourage "productizing" any of the items listed above.
These are essentially marketing materials -- you might as well charge
for your advertising.  As services move up the value chain, charging
starts to make sense.  Managing this issue is tricky.

> For customers who themselves are doing software engineering, sell them
> advice, design review, coordination with their industry siblings,
> mediated cooperation with their competitors over the non-contentious
> issues, and help contributing back the changes they make to the public
> code base.  

Again, there's a mutual benefit issue here that belies ready
"monetization" of services.  At the low end, general design specs, patch
incorporation, and informational events are going to be a cost of
business.  I'd draw the line at direct contacts of substantial duration,
outside a core development team.  For a typical free software project,
there's a set of a half dozen to a dozen core developers, another score
or so significant contributors, and then several hundreds to multiple
thousands of users, mailing list participants, bug reporters, etc.
Managing groups of substantively similar nature should be relatively
straightforward.

My experience was that insulating core development staff from direct
exposure to user issues (compounded by other sins of management) is
highly deleterious to the free software development effort.

One significant problem IMO with the FSB model is perceiving free
software development as the analog of proprietary development.  Largely,
it's not.  

You're not building a large staff of dev + QA + marketing + sales +
admin.  

Rather, there's a development effort, mixed in- and out- of house.  QA
is largely shifted to the user base, preferably through a "stable" v.
"unstable" dev tree.  Transparency matters tremendously.  At Zelerate,
one of the problems was that nobody inside knew what the goals were,
partially driven by marketing concerns (hold it tight and make a
splash).  Users didn't know where we were going.  Dev didn't know what
professional services was doing (largely:  more, better, and better
targeted development than dev:  prof'l services saw the customer issues,
dev didn't).  And professional services didn't know where dev was going.

Scale on top of that a marketing organization.  Again, Red Hat is
something of an exemplar:  there's some development, a professional
services organization, but in large part, the company repackages
existing software and pushes it out.  The technical tasks themselves can
be completed largely without a formal corporate structure, viz Debian.



> Sell these mostly-intangible things at prices close to what you could
> get via license fees and concentrate on generating the bulk of cost
> savings to customers by giving them the much better software and
> support that we know open source processes can produce.

The service model.

My assessment in September of 1998 [5] was that the business model best
suited to free software was that of Price Waterhouse, IBM, and Self
Analysis (my own sometime one-man consultancy).   In the same post, I
suggested:

    In five years, OSS will have changed the commercial SW and IT
    industries beyond all recognition.

    In five years, the commercial SW and IT industries will have changed
    OSS beyond all recognition.

Aside for a preference for "free software" to OSS, I stand by both
comments.  It's the service, stupid.  Companies based on large-scale
custom services, tightly integrated to business practices, companies
with a broad-based technology offering, and small operations consisting
of individuals or small teams with focussed expertise, are likely to be
the type of firm best suited to free software business models.

Adoption by Big Six consulting firms has been rather lower than I'd have
hoped.  I believe the issue here is the financing leverage which can be
applied by Microsoft.  With US$36b in the bank, the company can afford
to finance and sweeten a bunch of deals, which I suspect (and have
heard) is what happens.  One thing most FSBs do lack is wheel-greasing
material.

Peace.


----------------------------------------
Notes:

1.  I'm working from memory here on the pivot table history, and may be
    misremembering.  Research shows a rejection of an "innovation" award
    for Microsoft on this feature (among others), but not because it was
    a customer-provided feature (it existed in an earlier Lotus
    product): http://www.vcnet.com/bms/departments/innovation.shtml

2.  Source:  http://www.netvalley.com/sales98.html

3.  Source:  Software Magazine's "Software 500"
    http://www.softwaremag.com/SW500 2000/index.cfm?StartRow=1&RowsPer=50
    http://www.softwaremag.com/SW500 2000/index.cfm?StartRow=1&RowsPer=500

4.  Source:  Yahoo Financials, 3 Jan, 2002.
    http://biz.yahoo.com/p/r/rhat.html

5.  Posted to InfoWorld's now-defunct forums September 4, 1998, archived
    copy available on request.

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?              Home of the brave
  http://gestalt-system.sourceforge.net/                    Land of the free
We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire                      http://kmself.home.netcom.com/resume.html


["application/pgp-signature" not shown]