1Re: Symbolics Marketing Strategy0

[Mabry Tyson <TYSON@WARBUCKS.AI.SRI.COM>]

    Date: Thu, 25 Jan 90 11:50 EST
    From: miller@CS.ROCHESTER.EDU (Brad Miller)

        Date: Thu, 25 Jan 90 08:08 CST
        From: dmitchell@backus.trc.amoco.com (Donald H. Mitchell)

	    Date: Wed, 24 Jan 90 09:15 PST
	    From: taylor@CHARON.arc.nasa.gov (will taylor)

	    [...]
	    I propose that Symbolics bundle CLIM, Concordia, Statice, & Joshua into
	    Genera for NO increase in software purchase/maintenance costs to users.
	    Then agressively market these capabilities which would now be part of 
	    the basic Symbolics Genera operating system. 
	    [...]

	    - Will Taylor         taylor@pluto.arc.nasa.gov

        I strongly second the idea that CLIM ought to be bundled (perhaps
        eventually becoming THE interface). 

    The problem I see with this strategy is that it reinforces the idea that
    Symbolics has to make their money on the hardware. People buy their systems
    for the software, and NOT the hardware. I'd much rather see them price their
    software according to what the market will bear, and make it available on a
    variety of platforms. Concordia, for instance, needs to be price competitve
    and marketed as an alternative to FrameMaker.

    And lest we forget, some of us bought our Symbolics machines as, essentially
    CASE machines. To increase our productivity writing our own applications. We
    really don't need or want the additional cost of this added software (other
    than CLIM which does relate to development) passed on to us in future
    hardware or software costs, because we don't use them. To us, Symbolics
    machines are development machines, not application engines.

When Symbolics indicated it was planning to have CLIM as a layered
product, I responded (privately to Symbolics) that I thought it was a
bad idea.  I gave several reasons why (more system configurations means
more room for errors and costs in testing, more irritation by customers
to be dinged for yet another part of the system, duplicate efforts
between CLIM and DW, etc) but my main complaint was that if CLIM is
layered, then Symbolics can not use it as the interface for all the
software they ship and the customers will be forced into not using it or
to require everyone who uses their software to purchase it from
Symbolics.  

If Symbolics doesn't use it thoroughly, then it will probably be more
buggy and slower than it should be.  They will also be giving the
message that this interface is not the one they use and therefore is not
really worthy for other people to use it unless they have to.  (They
have indicated that any support for DW has been suspended in favor of
CLIM.)  How would you feel if CLOS was a layered product?  (I would
expect the namespace server would be better if STATICE were standard.)

In our case, we supply software to various sites.  Do we now have to support
two interfaces (CLIM and DW), or require those sites to purchase CLIM,
or just stick with the buggy DW?  I'm afraid the last of those is the
correct answer if CLIM is a layered product.


I'm glad that a number of people have spoken up to say that layering CLIM
is unwise.  I have made a suggestion to Symbolics as to how it would be
better to finance it.  If anyone else would like to, I suggest you make
your comments to SLUG-LIAISON@AI.SRI.COM and/or to your salesman.