Subject: Re: People only buy support for bad software ?!?
From: Brian Bartholomew <>
Date: Wed, 2 Jun 1999 11:00:56 -0400

This is more subtle than an application which coredumps every two
hours.  A program doesn't have to be that bad to require a maintainer.
Coding in C is usually sufficient.  Properly done, the world will hail
you for a great program even as you make it deliberately complex,
obscure, or buggy.  It is sufficient to slow down evolution, by not
revising the program to be simpler and more streamlined when that
would reduce the customer's maintenance or training costs (aka your
revenue stream).  Imagine cloning a program with lousy ergonomics or
an unnecessarily steep learning curve, and then not improving it.

Imagine the following scenario, where a program by an free-ish
software business is made too good to function under a "selling only
support" business model.  The program is gratis.  The program works.
The maintainer has built a reputation for excellent code quality and
business stability.  The maintainer sells support, but people don't
buy it, because they are convinced by the code quality branding that
the code works.  When a functional bug is found, the maintainer must
fix it quickly for gratis to maintain his "good quality" brand.  If
users might consider buying support as insurance, they still don't buy
it, because they are convinced by the business stability branding that
the vendor will be around to buy support from, just in time.  Oops.

One might say that any libre, gratis program in wide use that doesn't
already have a paid maintainer is too good for the "selling only
support" business model.

----- writes:

> When I first go into the business, I have nothing but code.  The
> only way to build a sustainable position in the business is to
> develop positive reputation.  I can't do that by shipping buggy
> code.  Later, the code is established, and my ability to ship buggy
> code is bounded by the cost to someone else to learn the code and
> build a support position around it (actually, we also need to factor
> in a cost for the risk to them that I will clean up my act and leave
> them looking stupid, which is a significant risk).

That seems right.  I submit there's a big region in there where
there's only one maintainer, who has lots of room to design their code
to be bad, and ride near the lower edge of the region.


Without attending an fsb's internal strategy meetings, it's probably
tough to tell the difference between a program that is designed to be
bad, and one that is as designed to be as good as possible, but
happens to be boring to work on.

A member of the League for Programming Freedom (LPF)
Brian Bartholomew - - - Working Version, Cambridge, MA