[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd #2: Re: Scale Economies at Microsoft?]

  Pieter Nagel wrote:
  > On Sat, 15 Nov 1997, charles mueller wrote:
  > >         Scale economies--the savings (in unit costs) that come with higher
  > > volumes of output--are typically exhausted rather rapidly in most
  > > industries.
  > ..
  > >
  > >         Is the computer software industry an exception?
  > Development and distribution are not the only costs of software.
  > If you take into user support into acount, there would be a point at
  > which it would be less profitable to sell more copies of software
  > because you would not be able to deal with the volume of support
  > calls.
  Actually, that does not follow. If you assume that customer support
  increases in direct proportion to number of units sold, then this is a
  cost that remains constant per unit, but it does not increase. It is
  arguable that even conventional tech support cost decreases somewhat per
  unit with scale. For example, major player will have a great deal of
  third-party literatuure about their product marketed at no cost to them,
  and can have specialized tech support personnel who can operate more
  efficiently. While neither of these is the sort of devasting push
  towards monopoly that the zero marginal cost of production (MCOP) is, I
  see no significant forces pushing in the other direction.
  > (This presuposes that customer support is part of the product
  > delivered; if you discount that then monopoly is suddenly much more
  > profitable. Maybe that explains a lot about the current state of the
  > industry...)
  It does, and it explains why customer support is increasingly offered in
  the form of FAQs and searchable websites where the zero MCOP phenonmenon
  > Also, I guess there would be a point at which having too many
  > customers would lead to astronomical upgrade expectations - everybody
  > wants something different in the new version and at some stage you
  > can no longer please all nor even please most. The choices would be
  > to not bring out an upgrade (and lose revenue) or bring out an
  > upgrade and let only a smaller section of your current market choose
  > to upgrade.
  People who have purchased your product have an investment in you.
  Switching to another product means buying that product at full price,
  rather than an upgrade price, and, more importantly, losing productivity
  while you adjust to a new tool. Depending on the nature of the product,
  it may also mean having to port your data or work to some other format.
  Therefore, other things being equal, the thing to do is always to stick
  to the same tool.
  Also, the MCOP gives you more money to throw into new features and
  therefore be able to please more of the people more of the time. Oracle,
  the hegemonic database player, is a superb example of this. Oracle 8
  both does things a lot of people want, like go out to the Internet from
  the database, and highly specialized things like provide bit-mapped
  indexes, which are highly efficient for certain kinds of searches, but
  useless for everything else (of course, using them is optional).
  Informix and Sybase are increasingly unable to match Oracle feature for
  feature; they simply don't have the capital.
  > (Unless you controll a large section of the market, in which case you
  > can create a synthetic need to upgrade by causing one product's new
  > version to render other products obsolete; and by deliberately
  > introducing new functionality in a way that will render software
  > obsolete.)
  And, of course, since the MCOP generates monopolies, you will have a
  large share, indeed most, of your niche market or you will die. The
  proof is in the pudding: the personal computer opened up the whole
  field, so it was very competitive for a while, but now it's being
  reduced to niche hegemonies: Oracle in database, Adobe in desktop
  publishing, AutoDesk in CAD, etc.
  > > My understanding is
  > > that the costly part (development) culminates in a "master" disk of some
  > > sort.
  > No offense, but you should rather not use that kind of language in
  > this technical debate. Software is an intangible product, which
  > renders it extremely difficult to discuss it within old frameworks.
  > Talking about a "master disk" as the ultimate product of a software
  > company's labours just reveals a desire to have something tangible to
  > refer to. There is no tangible, physical end-product to point to.
  I think you're being pendantic. The point is that the final product is
  infinitely reproducible because it is intangible. Obviously, the "master
  disk" has no value; it's what's on it that counts, but I think this is
  >      ,_
  >      /_)              /| /
  >     /   i e t e r    / |/ a g e l