Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!helios.ee.lbl.gov!pasteur!ames!elan!tom
From: tom@elan.elan.com (Tom Smith)
Newsgroups: comp.lang.c++
Subject: Re: C++ pricing for AT&T Release 2.0, and 386 binaries
Message-ID: <572@elan.elan.com>
Date: 12 Jul 89 18:45:22 GMT
References: <1379@hcr.UUCP>
Organization: Elan Computer Group, Inc., Mountain View, CA
Lines: 69

Mike Tilson accurately (in my opinion, of course) justified AT&T's
strategy for the notorious C++ Release 2.0 pricing strategy.  However,
many of us who have been using C++ since 1.2 (or earlier), either in
source form or from commercial vendors, are still to a degree being
hung out to dry.  Here's why:

From article <1379@hcr.UUCP>, by mike@hcr.UUCP (Mike Tilson):
> 4.  The price change was a big surprise.
> Yes, this seems poorly managed.  A lot of people expected to buy Release
> 2.0 for a certain amount, and now don't have the funds in the budget.
> The Release 2.0 features and bug fixes are substantial, and there is a
> pent-up demand for things like multiple inheritance.  AT&T never promised
> anything about Release 2.0 pricing, but they could have communicated better
> to their customers.  I think some of the complaints are a result of the
> fact the people may now need to wait for binary vendors such as HCR
> and others to ship binaries on the appropriate platforms.  This will
> not happen immediately on all platforms of interest.

For around a year now the many people complaining about the propensity
of bugs in Release 1.2 have been told "Fixed in 2.0".  This implies that
support of 1.2 by AT&T has ceased.  It would be unreasonable to expect
third-party compiler companies such as Glockenspiel or Oregon Software
to fix problems in their distributions of Release 1.2 only to have
it made obsolete by the 2.0 release when it becomes available; however,
this introduces a support hiatus of at least a full year.  When 2.0 is
released (any minute now, actually), most compiler companies will be
just beginning their porting efforts (commendations to HCR for some
foresight here).  One would expect commercial C++ releases to be
generally available 6-9 months down the road, depending on the individual
company's release cycle and development time.  Unusual machines will
take somewhat longer.

Commercial product development using an "unsupported research" compiler
is not for the faint-of-heart.  Many companies were developing using
Release 1.2 in anticipation of 2.0 availability in the near future.
Now it seems that the expectations of an August release was misleading;
the average development group will have to wait until around first
quarter 1990 for a product-quality C++ compiler.  The availability
of source for a price accessable to the general public would have

On a different vein:
(also) From article <1379@hcr.UUCP>, by mike@hcr.UUCP (Mike Tilson):
> 3.  There is no good way to license a network.
> This is true.  You have to buy a license for each machine you wish to
> use the software on.  I'm not sure this is such a big problem.  Nobody
> seems surprised that you have to pay to buy each machine on the
> network, but somehow buying the software seems to be a big problem.
> I think often the complaint boils down to "I wish it were cheaper/free."

This is a big problem for a company that provides their product on
many platforms, and is willing to do the porting themselves (and swallow
the source cost).  Such a company typically has a set of development
machines roughly of a one-to-one ratio with the developers, and
a set of testing, or "porting lab" machines for qa and release distribution.
Their could easily be an order of magnitude more porting machines, than
developers, yet the number of compilers being used is really at most
the number of people using them, not the number of machines.

This type of environment is quite common, and has caused a demand in
recent years for "floating licensing", whereby a company pays for as 
many copies of a product as will be used at one time, plus a premium
for the ability to float those copies from machine to machine.
Perhaps a floating source-license scheme is called for here.

As always, these opinions are endorsed by no one other than myself.

    Thomas Smith
    Elan Computer Group, Inc.
    tom@elan.com, {ames, hplabs, uunet}!elan!tom