Subject: Re: FW: Why would I pay for Ximian software?
From: "Gerald P. Dwyer, Jr." <>
Date: Fri, 04 Jan 2002 07:49:53 -0500

I think that Karsten gives Microsoft too little credit, leaving aside that 
losing a civil case doesn't make anyone a "criminal." There's a related 
issue raised by Karsten's figures for the future of proprietary software 

Why has MS taken over Windows software applications? MS earned much of its 
domination of the desktop by producing better products. Lotus 123 didn't 
lose out to Excel because MS behaved badly. Lotus treated 123 as a cash cow 
and didn't improve it. MS improved Excel in the ways that consumers wanted. 
I think that the evidence on this is clear, which is personal memory backed 
up by Liebowitz's and Margolis's book.

For the future of proprietary software, the question is whether someone 
else (not a producer of the OS) could write a better spreadsheet and 
supplant Excel. The answer here is not so clear. It hasn't happened. It 
strikes me personally as improbable that it'll happen on the Windows 
platform in the foreseeable future, but I know of no evidence to contradict 
the view that it might happen. Improvement is less likely when there's no 

The future of proprietary application software is not obviously rosy. 
Producers of Windows software applications that are superior have fallen by 
the wayside with zero residual value. The firm that owned PC Magazine's 
top-rated personal information manager for Windows simply stopped 
development and found no takers to buy it and continue development. (I 
can't recall the name or find it easily at the moment, although I can get 
it.) MS-DOS and Windows succeeded because they attracted application 
developers. Now they're not.

Given this, it becomes even more interesting to ask: What's a profitable 
business model that would sustain a free software application used almost 
entirely by non-programmers? Will what we think of as applications, such as 
a word processor or spreadsheet, be tied to the producer of an OS for the 
foreseeable future?

Jerry Dwyer

At 07:29 PM 1/3/02 -0800, Karsten M. Self wrote:
>on Wed, Jan 02, 2002 at 08:48:44PM -0800, Tom Lord ( wrote:
> > on Thu, Jan 03, 2002, Bernard Lang wrote:
> >
> > 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.
>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
>The story should be pretty clear:  there's Microsoft...and everyone
>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
>    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
>Free or proprietary, pure-play software doesn't pay.  Unless you're a
> > 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
>     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
>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 +
>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
>     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
>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):
>2.  Source:
>3.  Source:  Software Magazine's "Software 500"
>4.  Source:  Yahoo Financials, 3 Jan, 2002.
>5.  Posted to InfoWorld's now-defunct forums September 4, 1998, archived
>     copy available on request.
>Karsten M. Self <>
>  What part of "Gestalt" don't you understand?              Home of the brave
>                    Land of the free
>We freed Dmitry! Boycott Adobe! Repeal the DMCA!
>Geek for Hire