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