What do users REALLY want?

["Leslie A. Walko" <attila@FLASH.BELLCORE.COM>]

    Date: Wed, 20 Dec 89 19:52 EST
    From: Barry Margolin <barmar@Think.COM>

	Date: Wed, 20 Dec 89 16:49 EST
	From: attila@flash.bellcore.com (Leslie A. Walko)

	First suggestion:  
	Sell processors with free "runtime" licenses, and charge for development
	environment.  I think my management would be willing to pay $10-15,000
	per XL and UX *development* environment in return for dropping the
	hardware price by the same amount.

    They already do this with MacIvory, UX400S, and 3610 (which is just a
    runtime-only 3620).  They charge $7-9K for the development environment
    on these.  The don't have runtime-only XL400 or other 36xx; the
    assumption is probably that no one would pay $30-70K for a delivery
    workstation, so there wouldn't be much interest in runtime-only versions
    of these machines.

Yes, I agree that "no one would pay $30-70K for a delivery workstation"
but that is NOT what I suggested.  I believe that is suggested that the
XL400's price be dropped to 25K.  That is a *reasonable* price for
delivery hardware for relative to the level of performance that you can
buy in a 25K SparcStation.  A 25K XL400 should be a superior performer
for large applications to the Sparc, while less cost effective for
smaller applications and for occasional use.  If you factor in the cost
of porting software, a $25K 'delivery box' will make a whole lot of
sense to project managers.  (However, $25K for 3610 level of performance
is not marketable as we all know.)

	Second suggestion:
	Port some of the very attractive layered software to run on Unix.  This
	means porting
		Joshua, Statice, Concordia.  

    At the meeting with SLUG, they mentioned that work is ongoing to port
    Joshua.  Statice would be harder, since there is no standard interface
    from CL to networking.  Concordia would probably be pretty hard, as it
    is intimately tied into Zwei and the Symbolics window system.

Having spoken with the product manager for Statice and Joshua and having
also spoken with the VP of Marketing, it is my understanding that there
is NO funded workproject in this area.  Yes, they are real interested,
but --there is always a but-- I heard them ask, "would we like to kick
some money in, up front, to get the porting going"?

Let's get real! You cannot sell product (Statice, Joshua) by telling
customers to come up with project funding!  If they had some guys
working on this and could show us a prototype running on something other
than a Symbolics, then we would consider funding the project in exchange
for corporate license.  That is how we do it with every company. There
are some very rare exceptions when we pay in advance for software that
does not exist, but most corporations have had very bad experiences in
that area.

As far as the difficulty of porting is concerned, Joshua would be easy.
Statice would be much harder since most of the code is comprised of the
file access and optimization routines which are OS or machine specific.
Since I spent the last several years in data bases, I don't know how
hard it would be to make Concordia run under CLIM, but I suspect that
you are correct.

	Taking this argument one step further, Symbolics should make a serious
	attempt to port the compiler

    The compiler?  No offense, but it is the laughing stock of the industry.
    They've wanted to scrap it for years, but haven't had the resources to
    write a new one.

				    , debugger

    Most of the unique features of the Genera debugger are related to the
    Symbolics hardware and Lisp environment.  Other than those, the Lucid
    debugger seems comparable.  For instance, the Lucid debugger lets one
    examine local variables by name, but the Lucid Lisp system only retains
    the names of parameter variables, not all local variables, so the rest
    must be accessed positionally.  Variable monitors, trap on call/exit,
    etc. are dependent on hardware support.

					      , inspector, Zmacs

    All the major Unix Lisps have a built-in Emacs-like editor; many users
    don't use them, because they don't want to do their editing in their
    Lisp process.  GNU Emacs is just about as good as Zmacs, and there's a
    plethora of extension packages available for it (including packages for
    interfacing it with a Lisp process).  And Zmacs wasn't written with
    portability in mind.

								, Zmail

    Why bother, when GNU Emacs RMAIL is comparable?  Yeah, it doesn't have
    universes -- big deal.  It doesn't have filters, but I believe someone
    has written an extension to provide them.  The hardest part of Zmail is
    the part that allows it to deal with multiple mail file formats, so that
    it can read and save mail in the format that is used by remote file
    servers; this feature isn't as important in a Unix mail program.

								       ... etc.
	to Unix boxes.  By selling it in pieces, anyone would be able to effort
	what they want.  Selling the whole lot together would generate more
	revenue than  the bundled price.  Furthermore, this may be a good way to
	build a survival strategy for Symbolics.  If the hardware market
	collapses, they should remain a viable software company.

    Except there's nothing particularly special about any of those pieces of
    software, except for the ways in which they interact with Genera.

I agree that some of the individual pieces are not very good.  I also
agree that there are other vendors out there who have functionally equal
products, with a better performance and a lower price.  However, it
sounds like that you have made an interesting argument (by implication)
for the superiority of integrated environments and/or in favor of
Genera over other OS.  If that is the case, and for the sake of argument
let us grant that, then would it not make sense for Symbolics to port
all their software to run on Unix boxes?  And isn't that what the
original suggestion was?

So I stand by the original suggestion that
  "this may be a good way to build a survival strategy for Symbolics.  If
  the hardware market collapses, they should remain a viable software
  company."


	Third suggestion:  
	Sell the UX400 at $15,000.  

    Isn't that the current price?

						    barmar I think we
paid $25,000 for ours.  The MacIvory 2 is $15,900 without the
development environment; again, too expensive for what you get; horribly
expensive relative to what it costs to make vis a vis an XL400.  The
MacIvory1 cost 10,900. It came out very poorly in a recent Stanford
University comparison of over 20 kinds of lisp platforms.  There were
plenty of '386 PCs that clobbered it --and they don't need an expensive
MacIntosh as a host.  That suggest to me that the MacIvory 1 should be
pulled from the market and the MacIvory 2 should be lowered in price.

Leslie Walko, attila@bellcore.com