Artificial scarcity and open source

Luis Villa has left a placeholder for a larger discussion on artificial scarcity. He has a problem with:

creating artificial scarcity, either through the use of patents, copyrights, or trademarks, or by allowing others to use trade secret and SaaS (software as a service) tactics to take data from the commons and then "proprietarize" it (make it proprietary).

I see his point, and agree, but any business depends on artificial scarcity of some kind. Or, rather, I should say instead that successful businesses are good at creating the appearance or reality of scarcity. Why? Because otherwise, the customer will take forever to buy something, even if they want it today. Right now.

This is actually one of the weaknesses of an open-source business model. Once you release the code, the customer is in control of when she buys. She may decide that she has enough (code, stability, support, etc.) such that she need not enter a paid transaction with you. Or she may decide to delay that decision for weeks or months.

This is good, right? Well, yes. But it's also problematic if you have a quarter to close. At Alfresco, we're constantly improvising with new ways to provide incentives for Alfresco users to become Alfresco customers (or Alfresco co-developers--cash or code, that's all we ask for :-) ). Some things that we've done, with varying levels of success:

• Offer time-sensitive discounts. We've calculated how much it costs us to sell our product (in terms of marketing, presales support, etc.), and offer set discounts if prospects close within 30 or 45 days of first contacting us. (Our average sales cycle is not much longer than this, so we're asking them to shave some of cost of sale in return for our shaving their subscription fees.)
• Put a time limit on presales support. This is similar to SugarCRM's mantra: "Go big, lose early." The software needs to largely sell itself. If we're going to sell at a tenth the cost of our competitors (and we do), then we need to save the hand-holding until after the sale, when our support organization takes over. We are candid with prospects: "You have 30 days of our time to ensure our software and company is a good fit for you. After that, we have to move on to customers that have completed their evaluations." This helps to focus them, and helps us to keep prices low.
• Withhold some value, though preferably not the code. I've talked about this before. There is a wide range of value you can offer/withhold from prospects to ensure that they have an incentive to pay you money. It's tempting to think that one should give everything away for free, but this is a Very Dumb Idea. Maybe a support subscription includes immediate bug fixes, 24/7/365 support infrastructure, a service to educate customers on best practices, enhanced documentation, etc. These are just some of the "proprietary support" services that vendors are tinkering with to keep their code open but ensure enough "scarcity" that customers will pay today, rather than never or after the quarter ends.

These are just a few ideas/tactics that open-source vendors use. You may like some and hate others. Most open-source vendors today simply go the route of keeping some code proprietary to provide a clear signal to customers as to when it's time to pull out the wallet. I prefer to keep all of the code open, but I understand why vendors do this. It would be nice if customers always paid a fair price for value, but they don't (you and I included).

Anyway, to wrap up, Luis, I agree that there are worse ways of creating artificial scarcity. But there does need to be a compelling reason to buy, and open source complicates this somewhat by giving away what proprietary vendors charge for. No doubt, we'll become more innovative over time in figuring out how to provide extra value to customers so that it's crystal-clear why they should buy--and today, not tomorrow. Until then, I'd welcome any comments on what others have done that has been successful.