Subject: Re: Motivating support contracts
From: "D. V. Henkel-Wallace" <gumby@zembu.com>
Date: Thu, 03 Sep 1998 09:35:30 -0700

   Date: Thu, 3 Sep 1998 10:52:13 -0400 (EDT) 
   From: Keith Bostic <bostic@abyssinian.sleepycat.com> 

   I'm finding that people often only buy support contracts when they have
   problems, i.e., they only buy support if the software breaks, and so I'm
   looking for good ideas for motivating support contracts.

Do you have enough users to do a 900 number?  Though maybe some
businesses will block their employees from calling one...

   I've thought about making all inter-release bug fixes and performance
   enhancements only available to supported customers, and that may be what
   we'll do.  

Don't forget that the intermediate releases may be _more_ buggy rather
than less, so the benefit of the public snapshot releases are actuall
more likely to flow _to_ the customers rather than the other way
around.

We definately saw this with EGCS.  When GCC snapshots were in very
limited distribution (essentially anyone could get on the snapshot
list but very few people knew that!) releases were infrequent and of
varying quality.  One of the benefits of opening up the process was to
increase the quality and overall reliability of the actual releases.
Of course that was a necessary but not sufficient condition for
quality releases!

Hmm, what about going the _opposite_ way?  Open the sorces via a
public CVS server or regular snapshot process or the like and
essentially stop making public releases.  You can make qualified
releases to your customers of more stable, supported product.

Of course so could someone else, but that's kinda the point of it
being a libre product, neh?

	      However, that also argues for making infrequent releases, and
   putting a couple of good bugs into each release...  :-)

I tend to discount this issue.  It applies to any software business
that charges for upgrades and/or service, and realistically, customers
will know they're being ripped off and will look for alternatives.
Plus most programmers (not only hackers) I take pride in their work.