The “OSS business model” is a misnomer as there are many variations. But the business model that the majority of large and leading OSS vendors utilize has one common aspect. These vendors are all selling support and “other stuff” (indemnification, additional testing, better management, etc) around a product that is indistinguishable from what a user can get freely from the related open source project.
Giving away all the value that a product provides and expecting that customers will pay for the “other stuff” is a mistake. This decision prioritizes short-term benefits at the expense of long-term growth. Yes, this decision reduces barriers to user adoption. But it constructs significant barriers to customer conversion. By the time an OSS vendor needs to sell into Category “B” users, the product has been in use for 2-5 years, plenty of time to form habits. One habit that Category “B” users form is how to get by without paying the OSS vendor for the value received. As a customer, I like this. As a vendor, not so much. And in the long run, this habit hurts all users because the OSS vendor has less revenue with which to fund ongoing innovation.
As Matt writes, to further complicate matters:
“….the better the software is, and the more expertise a customer’s IT department has with it, the less likely a customer is to pay for a support subscription.”
My solution to these problems is simple. Sell products. From day one, offer two options. Offer an open source and freely available product ABC and a commercially licensed product ABC*. Differentiate the two on the product features delivered. Let’s look at the example below for version 1.0:
If the user only needs features #1-5, then they can adopt ABC. If the user really needs feature #7, they have to purchase product ABC*. If the user has adopted ABC and seeks support, sell them product ABC*. Do not offer support around product ABC. Standalone support has no role in the Product Driven OSS Business Model (PDOSS-BM).
When version 2.0 comes along, you’ll notice that product ABC delivers features that were previously only available in ABC* and even includes new features not previously available in ABC or ABC*. Note that product ABC* version 2.0 has progressed up the feature value chain and there is still a gap between ABC* and ABC.
In order to simplify life for the customer, the product architecture should easily allow the customer to go from ABC to ABC* without a complete reinstall. Should ABC* be available under an OSI-approved license? I don’t know. I can make a case for both and will leave this topic for a future post.
It is important to know where to draw the line between what gets into ABC and what is held inside of ABC*. These incremental features should be things that the average enterprise requires, because you’re trying to encourage purchases (not just usage). This is clearly a balancing act between giving away some value (i.e. features in ABC) and seeking compensation for some value (i.e. the incremental features in ABC*). Will the balancing act be easy? Absolutely not. Is it required? I definitely believe so.
I know that all of this sounds like heresy to some OSS purists. It is. We need a dose of heresy to break through the glass ceiling that some of us see ahead. Let’s look forward and leave the purism to someone else.
Next up: How leading OSS vendors can lead us into the future