Selling open-source 'ice' to the eskimos

Savio Rodrigues of InfoWorld tries to parse what makes open-source buyers tick, and how to generate more of them. In so doing, he suggests that the real battleground is over those enterprises with both money and expertise to go it alone with open-source software (so-called "Category B" customers).

Why should they bother buying support when they can self-support?

For me, this isn't the right question. Using his MySQL-derived customer classification system, the real question is, "Can proprietary software serve Category A (companies with more time than money) at all?" and "Can open source more efficiently serve Categories B and C too?"

Implicit in Rodrigues' reasoning is, I think, a belief that if the software is proprietary, A, B, and C companies will all eventually just say, "Aw, shucks. I've got time/expertise/money, but what does it matter, I just have to pay anyway!" So the vendor cleans up on all three.

In fact, my own experience suggests that B companies buy less and less proprietary software (E*Trade is an example). Ditto goes for B, and C companies are willing to pay, anyway, so where is the conflict with open-source business models?

Open-source distribution gets a company to all three categories far more efficiently than proprietary software distribution does, so open source is better than proprietary software in that way. It reduces some development costs, too, even for companies that do the vast majority of development (because ancillary development-like language packs are generally picked up by the user community). And it significantly reduces sales costs because would-be buyers arrive at one's door prequalified.

Having said all this, I do agree with Rodrigues that there needs to be some "proprietary" hook to give would-be buyers a reason to become actual buyers. Where I think we differ is in what we'd keep proprietary.

I believe that keeping the core of one's software proprietary makes poor business sense because it inhibits adoption and increases cost of sale. Rather, "proprietary" services surround the core (think RHN with Red Hat Enterprise Linux or Google AdWords around Google Search, which is proprietary but needn't be) and provide the purchasing rationale or mechanism.

Few begrudge Red Hat for closing off Red Hat Network. It's a service, not the software. JBoss did roughly the same thing with JBoss Operations Network, to very good effect.

A "network" might not suit all companies equally well. For others, perhaps offering their software in a paid-for SaaS product would be the "proprietary hook" necessary to turn an onlooker into a customer. Or perhaps there's a completely different angle on it: think Basecamp (an application written to exploit 37Signals' Ruby).

Or consider Acquia's model: there's a huge amount of code surrounding Drupal, not all of it good. Acquia boils the Drupal ocean down to a coherent distribution with a management network for keeping customers current on the add-on modules, similar to how Firefox manages extensions.

The point is that there's a lot of money in giving away one's core, then charging for the periphery. Providing the core free of charge and encumbrances helps foster adoption, which makes the peripheral add-ons all the more valuable.