Hi,

The discussion (under the subject "street performer protocol" --
gotta love that thread drift) on pricing software and services
for FSBs hits close to home just now.

Sleepycat is well-established as a vendor of embedded database
software to ISVs building high-end server systems, and to those
building single-user desktop packages.  Our price list is set up
to close those deals.  We've got different competitors in the
two markets, and the markets will bear very different pricing
because of them.

Our strategy so far has been to charge based on the database
services that the application requires.  High-end server apps
care about recovery, high concurrency via fine-grained locking,
and so on.  The desktop apps generally need fast storage and
retrieval, but aren't as worried about concurrency (for example
-- there's a lot of variability, but you get the idea).  By
charging differently for those services, we've been able to
compete in both markets.

We make a good living in the desktop/server market.  We're
very interested now in the embedded systems market.  Our potential
customers there are building things like wireless application
protocol gateways, set-top boxes, mobile computer systems for
emergency vehicles, hand-held inventory control devices, and so
on.

The operating systems down there are VxWorks, QNX, and a host of
others.  Embedded Linux is starting to show up.  eCos, from the
Cygnus part of Red Hat, is there, too.  But the vast majority
of deployed systems run VxWorks or QNX.

We see a high-end/low-end split in the embedded systems space.
Some systems are single-user, and need simple services, and some
are critical infrastructure components, and need speed and
recoverability.


The problem is that the pricing structure in the embedded market
is all screwed up if you're coming from the server/desktop
market.

First, end-user volumes can be astronomical, so nobody does
royalty deals.

Second, the embedded platforms have historically been seriously
underpowered, so the tools and software that ran on them didn't
do very much.  They were usually pretty small and pretty cheap
to develop.  Disruptive innovation has changed that:  you can
carry a pretty nice computer around in your shirt pocket these
days.

The established pricing in the embedded market has been set
by the existing OS vendors and the tool vendors.  Software is
generally very cheap.

If you try to bring your expensive server product down to the
embedded world, you have a problem.  People look at your price
list and say no before they even try your product out.

So why not just drop the price?

It's hard to figure out how to do that.  One vendor (Centura,
whose RDM product is available for "embedded devices" as
db.linux -- not specifically an embedded product, but they're
pushing it there) discriminates against operating systems.  The
product is priced on one list if it's deployed on embedded
Linux, and on another list if it's deployed on a proprietary OS,
like Solaris or VxWorks.

If you're truly Open Source, of course, your customers can just
take your code and port it to the new OS themselves.  So these
kinds of licenses need to forbid that, which makes the products
not really free software.  After all, how free can it be if you're
legally forbidden to compile it?

The disruptive innovation from below is going to eliminate the
pricing differences between the high-end client/server software
market, and the historically low-end embedded market.  When
embedded Linux does as good a job as desktop Linux for most apps,
and when you can get small, cheap hardware packages to install
it on, you'll look at your software costs pretty hard and pick
the cheapest strategy you can.

So here's the business issue:  We've got a sales strategy and
a cost structure that relies on the peculiarities of our current
market.  We make a profit because we understand what this market
will bear.

We'd like to move into another market (in fact, we believe the new
market is going to eat the current market from underneath over the
next several years).  We'd like to preserve our profitable business
in the current market, and start building share and making new
money in the new market.

Because we're an Open Source vendor, we have a hard time treating
the operating system vendors differently.  Our customers can port
our code to whatever platform they like; that's been a good thing
for them and us.  The Centura strategy won't work for us, and I
haven't been able to figure out a good analogous strategy.

I'd welcome advice on how to handle this.  My frank preference is
to leave my current pricing for my current market alone, and figure
out a way to do new pricing for the new market.  Is there some kind
of friction point that I'm not seeing that we should exploit?

I'm not very interested in advice that says, "Cannibalize your
current sales to win the new market."  That's good on paper, but
we've got employees with mortgages, and we need to keep paying their
salaries.  We can't burn capital like a dot com.

					mike