sacco@eileen.mga.com (Joseph E. Sacco) (07/13/89)
in response to article <1379@hcr.UUCP>, by mike@hcr.UUCP (Mike Tilson):
Michael,
I saw your posting to comp.lang.c++ in which you address a number
of issues surrounding AT&T's pricing strategy for Release 2.0 of
the C++ translator. Since I posted the original pricing information
I thought I would respond. Let me begin by reiterating my observations
on their strategy. In my posting of June 27 I stated:
"I was under the impression that AT&T was interested in making C++ the
next 'standard' language of choice. I see the five-to-ten-fold fee
increase to be counter to that goal at this time. It would appear
that AT&T is pushing end users toward third party suppliers of binary
versions of the translator. I believe that action to be premature.
John Carolan described Release 1.2 as $2000 worth of bugs. He was
correct. However, given access to the source code and the C++ community
through the net, one could work with Release 1.2 to learn the language and
sketch inital designs. Given the current state of flux of the language
[and the translator], I would not consider it prudent at this time to to
undertake the development of a commerical software product without access
to the source code. It is shear folly to attempt to schedule a software
product when that schedule will be dependent upon some third party vendor
providing timely fixes to translator bugs that will most certainly be
present. Without source code and access to the C++ community, the response
time to fix a bug will be measured in months rather than days. You just
cannot plan ahead with any degree of confidence.
Eventually the language and the translator will stabilize sufficiently
that access to source code will be unnecessary for most development
of applications software. Afterall, I do not have source code for either
UNIX or my C compiler and yet I get along quite well without source. Here
it is a matter of degree. There may be bugs in these products but
their effects upon my development efforts are minimal. They are
mature products that have gone through many release cycles."
The point, Michael, is that AT&T's actions appear to be premature. It is
not that I WANT access to the source code but rather I NEED access to the
source code AT THIS TIME. Eventually, this situation will change. However,
I am trying to use C++ to build a commerical product that is to be brought
to market in a timely fashion. Eventually, isn't soon enough.
As to the points you raised, let me address them in sequence:
(1) the price is too high.
You argue that:
(i) unlike 1.2, Release 2.0 is a mature, supported product.
That remains to be seen, given the net chatter on the fixes and
features of Release 2.0. As for support, I have made a number of calls
to AT&T Software Licensing in Greensboro. If I use these calls as a
metric to assess AT&T support, I am not encouraged.
(ii) Compilers are not cheap. Major commerical compiler
manufacturers don't even sell their source code ...
Cfront is not a compiler. It is a lex and yacc based translator.
You are in the business. You certainly know the difference
between a translator and a compiler.
(iii) To it's credit, AT&T offers considerable educational
discounts for source ...
A jump from site licensing to $300 per CPU will not be viewed
by the academic community as a great leap forward. Images from
more recent events come to mind.
(iv) One thing people haven't considered in their calculations is
that AT&T also offers binary sublicensing rights. A large site
can get the source code it needs for porting or modification,
and then distribute MUCH LOWER COST binary copies to the
machines that need them.
Fine for a large site with a language support group or for a company
[like yours] that wants to get into the binary sublicensing business.
For small applications companies a $20,000 source license fee for
a lex/yacc translator is prohibitive. The alternative of purchasing
a binary from a third party is not attractive at this point for the
reasons I mentioned above.
(v) The AT&T licensing policies seem to be aimed at compiler vendors
and OEMs rather than end users.
Absolutely! That is the problem AT THIS TIME. Again, It is
not that I WANT access to the source code but rather I NEED access
to the source code AT THIS TIME. Eventually, this situation will
change.
(2) AT&T could have "owned" the C++ market with a lower price.
The issue is not the ownership of the C++ market but rather the issue
is making C++ the next "standard" language of choice rather than some
other object oriented language like EIFFEL or OBJECTIVE-C. It order
to make a product a "standard", it is necessary [but not sufficient]
to convince people that the product solves their problems, and
make the product readily accessible. A case in point is the
the X-Windows system. If X were being distributed using the same
price strategy as Release 2.0, how many people do you think would
be using it? In this regard you might also consider the rationale
behind the pricing strategies of major hardware vendors for
universities. It is not based on altruism.
(3) There is no good way to license a network.
There are a number of floating license schemes available that use
licensing daemons and such. These are beginning to appear in offerings
from major hardware vendors. However, that is not an AT&T issue.
(4) The price change was a big surprise.
YES! I appreciate your sense of understatement.
(i) 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.
YES.
(ii) However, since licensees of C++ 1.2 can upgrade every
previously licensed CPU for $10,000, I'm not sure this is such
a big problem.
Depends upon whose $10,000 [U.S.] your spending. Release 1 cost $2000.
Release 2, after 30 Sept, costs $20,000. What price release 3.0?
I would hope that by the time Release 3.0 comes to market I will
no longer have a need to access the source code. That may be
because either the character of the market will have evolved as you
have described or the use of C++ will have waned into provincial
insignificance.
(5) "The price is too high, let's all get behind FSF GNU G++, except
it's not practical for me to do this...."
At this point in time, the compiler [native code generator] and
source level debugger from the Free Software Foundation offer
a realistic solution the the problems generated from the AT&T
pricing strategy. The combination of a real compiler and a matching
source level debugger provides a significant advantage over
the cfront translator when doing real development. Debugging
translated code, as you know, can be a very, very painful experience.
(i) I am aware of a case where a local firm paid thousands of
dollars to a consultant in order to get FSF compilers up and
running on a common workstation. Since this firm has no
compiler gurus, if they ever want an upgrade or if their
base OS changes, etc., they'll probably pay the price again in
the future.
I am certainly not a compiler guru and yet I got the GNU stuff
up and running on a SUN4 in a few hours. The GNU build utilities
and installation instructions are crafted with a high degree of
professionalism. I can not say the same thing about cfront 1.2.
However, even cfront 1.2 took only a day to get up and running.
(ii) When you buy a commercial package, you have an expectation
that you can "plug it in and go." This is worth something.
Agreed. And that is why, AT THIS TIME, purchasing a binary from a
third party vendor is not an attractive alternative to having
access to the source code. Without source code and access to the C++
community, the response time to fix a bug will be measured in months
rather than days. You just cannot plan ahead with any degree of
confidence. Eventually, that will change.
(iii) As a software vendor, we are investing in product development
in the hope of receiving a return on that investment.
We too !!! I don't do this for love.
(iv) We think our investment will produce useful software; the
market will tell us if we are right.
Agreed. Besides, AT&T has rigged things so that folks like you may
be the only other financially viable alternative.
Joseph