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

Re: AN IMPORTANT MESSEGE FROM SYMBOLICS SOFTWARE SUPPORT



     Date: Fri, 18 Aug 89 14:59 EDT
     From: pan@Athena.Pangaro.Dialnet.Symbolics.Com (Paul Pangaro)
     Subject: Re: AN IMPORTANT MESSEGE FROM SYMBOLICS SOFTWARE SUPPORT
     
     I respectfully ask that all those interested in software bugs and
     fixes read the following and respond. Your opinions are important
     during a phase when we (SLUG) again push to get some action on a
     long standing issue: getting Symbolics to provide timely
     information about the existence of, work-arounds for, patches for and
     future fixes for known bugs as discovered by users (and Symbolics
     developers too, presumably).

Sorry that it has taken me a while to get around to responding; I wanted
to wait till our situation here was more clear (see below) before
responding.  I do have to say that I was a bit disappointed in the
amount of net traffic that this request produced; especially from
Symbolics personnel.  Disclaimer; Please note that these are my personal
opinions, not NIST.

In view of prices vs. budget vs. service (Remember the `Deficit' ?), we
decided to go with the subscription service this year, previously we had
the equivalent of contract service.  In view of the IMPORTANT MESSEGE
(sic),  I am now wondering what it is we're going to get.

With the  contract  service,  it  turns  out  that we had relatively few
occasions to phone in. We don't  need handholding here (much :)),  but we
do need a  clear mechanism  for dealing  with bugs.   Unfortunately, and
probably unfairly,  the  most  memorable  of  those  occasions were also
unfavorable. Its rather frustrating  to call in  over a period  of years
(and pay a premium for the phone #) to check on the status of a bug  and
each time have to start from the beginning with explaining "what the bug
is, yes it IS possible for this  bug to exist, here is how  to reproduce
it, yes i DO know what I'm  talking about; the bug IS possible",  and so
on...  OK, mark it up to the `DNA Syndrome', the original developers are
gone, etc, etc.  I know things are being improved...

The point is not to get myself into a flame mode here (calm down!), but
it raises two points:
   1) For our purposes, I dont feel we got very much extra for the
contract service. I have found SLUG to be more helpful.  However, using
SLUG as an alternative does raise issues that have already been
discussed here: fairness to Symbolics (`free' maintenance, esp. when Sym.
employees respond), the ethics of passing symbolics fixes to non-paying
users, etc.
   2) Does Symbolics itself know what the bugs are?

It seems to me that we are offered three options for Software maintenance:
  1) None; buy it and shut up. (This is Chris's designation `AS IS')
  2) Subscription: pay monthly, get updates & documentation.
     (This is Chris's `Supported')
  3) Contract: pay more and get telephone & email `Access'
     (Or is this what Chris meant by `Supported' ?)  

But just what does `Access' mean anyway;  for the price I would hope  it
means `conversation'; in particular, hand-holding, discussions about how
to do something, how  to get something  to work, just  what is this  CAR
thing anyway... Certainly discussions are expensive to provide &  should
be paid extra for.

But what about a simpler form of transaction: 
  User: "We think we found a bug in (x)"
  Symbolics: "Thank you, we'll look at it", or "We know, here is the fix"

It doesn't  seem  all  that  expensive.  But,  as  I  read  the infamous
"IMPORTANT  MESSEGE",  they  wont  even  ACCEPT  a  bug  report  from  a
non-contract site, much less respond or even acknowledge it!!!  [I guess
if they get no bug reports, they dont have to fix em right? :)]

Let's remember that updates involve both rewrites, new features, etc, and
bug fixes.   I cant say enough good about the creativity, ingenuity  and
usefulness of  the  software  and  how  it  has  evolved over the years.
Release 4 was way above anything else available at the time, and compare
that to Rel 7.  I  would also say that  for the most part  Symbolics has
been very sincere about bug fixes.  Yet there is clearly a problem  with
records of bugs and communication.

We recently had a discussion about `Corporate Memory'.  I think that
there can be a good solution to both of these problems; something along
the lines of Brad's and others suggestions. IMHO, it should include the
following.  
  1) Some form of database/bulletin board accessible via
email/internet/? Or possibly emailed digests; but if so, they must be
frequent and back copies should be available.
  2)  Should  be  coupled  with  an  internal record of bugs & progress.
[This should  be  designed  for  corporate  memory] Symbolics presumably
would only want to release somewhat sanitized information to avoid dirty
laundry & secrets; but if access is limited to PLA (NOT just contract!!!)
then perhaps they would be less worried.
  3) Should not require excessive labor on Symbolics part to maintain the
`public' version beyond that of maintaining the internal version.

I think that such a system would help Symbolics internally and provide a
very useful service to its customers.  There would be a lot of initial
overhead in setting up the system, but I think that maintaining it would
not be so hard.  In any case, the labor would be essentially independent
of how many people were accessing it.  

I would bet that such a system is far ahead of what any competitors
provide, and yet I cant help but think that Subscribers (at least)
deserve something more that what the IMPORTANT MESSEGE seems to imply
"Go away; we'll send you a new tape when we're good and ready" 

In lieu of that, I would hope that at least symbolics would accept email
bug reports from  subscribers.  The  report should  be acknowledged;  not
just its receipt, but a comment on status, known workarounds, etc.

     Do you respond?

Belatedly, but emphatically, Yes!     
     
I am interested in what Symbolics feels about all of this.

     Best,
     PANgaro
Bruce
Miller@cam.nist.gov