Subject: Re: People only buy support for bad software ?!?
From: "Michael A. Olson" <mao@sleepycat.com>
Date: Wed, 02 Jun 1999 09:09:48 -0700

This is an interesting thread, but of particular interest to
me.  Sleepycat Software distributes Berkeley DB, and makes a
substantial portion of its income on support.  Brian and others
argue that the only reason Open Source companies can sell
support is that their products are (a) unreliable or (b) too
boring to appeal to an unpaid maintainer.

I start from some pretty straightforward beliefs:

	+  We distribute high-quality code.  I think this is a
	   safe bet.  It's in widespread use, has demonstrated
	   its ability to handle high loads of different kinds,
	   and wins enough technical evaluations on reliability
	   that we're sure it works.  You can read the source.
	   The design and implementation are solid.

	+  Database management is interesting enough to draw
	   the attention of numerous unpaid maintainers.  There
	   are lots of free packages available with active
	   developer communities.  PostgreSQL is a good example.
	   It came out of UC Berkeley at the same time as Berkeley
	   DB, and though some of the Sleepycat staff contributed
	   code in the past, none does now.  Releases are
	   maintained by an active user community at postgresql.org.

We don't make all our money from support and services, but
we make a fair chunk of it there.  Why should that be so?

I think we're a little different from some of the other
service companies that support gratis or libre code.  When
you use Berkeley DB, you embed it in an application that
you ship to customers, paying or otherwise.  Frequently,
people choose us when they need to manage large volumes of
data (100GB or so) or have stringent concurrency demands
(thousands of users).

In complicated, multi-threaded applications where performance
is critical, paid vendor support is more than an insurance
policy.  When the application exhibits a bug, it's generally
very hard to track down.  It could be in the application code,
or in the database code.  Usually, the cause of the bug is
somewhere in the distant past of the program counter.  By the
time you notice it, you only see the symptom, and figuring
out what went wrong is hard.  It can take us weeks of working
with customers to come up with a reproducible case that

demonstrates a problem.  After that, of course, the fix
only takes a few minutes :-).

This isn't because we write lousy code, or because our
customers do.  It's because in running systems, bugs happen.

People who buy support from us get the full attention of our
technical staff whenever the sky falls.  We have relationships
with our support customers; we know a lot about their apps,
just from chatter back and forth, before they ever come to us
with a problem.  We help them with performance tuning, answer
design questions, and find out from them what their applications
do.  That relationship has ongoing value to our customers, and
it lets us fix their problems faster than we could if they bought
support just in time.

					mike