The problem with open-source revenue models
Dennis Howlett writes a thought-provoking piece on proprietary maintenance revenue, challenging the value that software vendors provide or, rather, the generic way in which it is provided. Howlett proposes a way to customize maintenance fees to the actual value provided by a vendor:
In software terms, we already know that (differentiation for customers) happens through software implementation, configurations and customizations that are a core part of delivering to customer needs. There is no reason why the same principles cannot be applied to the maintenance element of the business relationship. If you stand back and put aside the notions of the last 30+ years, it is blindingly obvious.
It is obvious for example that in the early stages, customers will consume a considerable amount of resource(s) as they learn and become familiar with the product. They should therefore pay an economic price that reflects the services they consume. However, the software vendors need (to) do three things in order to soften the impact and reduce the long term burden...
I'll leave it to you to read Howlett's post to discover the three things, but even in the short blurb above Howlett unwittingly calls out a fundamental difficulty in open-source software revenue models, one that Savio Rodrigues has been banging on for awhile, and one that NBC iVillage CTO Jon Williams has also called out:
Open-source vendors start making money from their customer base precisely at the point that the customer base is least likely to renew.
Howlett suggests that software vendors are right to charge a big upfront license fee as it helps to defray the high initial cost of supporting a customer's deployment of the software. I hadn't really thought of that before, but it makes sense. Open-source vendors chop off the license fee and only charge for maintenance and support, which means they assume pretty much all of the risk/cost in the first year of a contract.
Open-source vendors get around this by pushing for multi-year agreements, which is a way of evening out risk and fairly apportioning it between vendor and buyer, but this is only one way to even out that risk. Other ways include adding commercial extensions to help compel renewals in order to make the vendor/customer relationship profitable for both parties.
This latter tactic also becomes more inviting given that enterprises increasingly look to open source as a commons to be used but not replenished. This is one reason why Red Hat CEO Jim Whitehurst has been evangelizing for enterprises to contribute code back to the open-source communities from which they derive benefit. Open source has the chance of becoming a nonrenewable resource if enterprises consume it without contributing cash or code back.
Yes, there will always be open-source software that doesn't rely on corporate patronage, but it may not be the type and caliber of code that enterprises require. Even paragons of open source like Apache and Linux have heavily depended on corporate involvement (like IBM's) to become mainstream, enterprise-class software, in many cases.
It may be that open source can take care of itself, but history hasn't been kind to that belief. History shows that noncorporate open-source communities have proved adept at getting code to a "good enough" state, and in some cases an exceptionally "good enough" state. But not usually. Usually, money has to get involved. See, people have to eat, and food generally costs money.
Open source still needs to figure out the best ways to get paid without sacrificing the ideals that make it so powerful. I suspect that we're actually not too far off from this ideal. We just need to find the moderate middle ground between competing extremes, as Dana Blankenhorn recently suggested. I'm confident we can.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 





One of the things companies using an Open Source model need to do is make sure they get paid for up-front costs up-front. For example, in the more traditional model a software vendor would get paid an up-front license fee. That license fee would help defray to costs of sales (including extensive pre-sales technical support for evaluations or pilots) and the extra support costs during initial deployment.
A subscription-based Open Source model does not include that up-front license fee. So to the extent that a customer wants pre-sales technical support or technical support to run a pilot they have to pay for those services. To the extent that a customer needs extra help in deployment they need to pay for those services. This can be a benefit to customers as the costs are explicit (not hidden in a license fee) and incremental (you can pay hourly for what you use as opposed to a big license fee that may or may not align with your actual resource usage).
Part of the challenge is educating customers about this different model. The Open Source company needs to explain to the customer that they can pay for consulting services to support their pilot, and then pay for the subscription service as opposed to getting the pilot for free from the proprietary vendor but now having to pay a large licensing fee when they deploy.
Ultimately I think the explicit and incremental pricing structure of the Open Source model is better for customers in the long run. But it will take some time before more customers are used to buying this way.
Larry
Larry, I always find your feedback and presentations enlightening and interesting.
I posted a response on my new blog (http://alampitt.typepad.com/lampitt_or_leave_it/2008/08/open-core-licen.html), and it got picked up by The 451 Group's CAOS blog by Matt Aslett.
(http://blogs.the451group.com/opensource/2008/09/01/andrew-lampitt-defines-open-core-licensing/). Thanks to Matt Aslett.
Don't you both feel that the "Open-Core Licensing" business model ('GPL + commercial extensions') is becoming the standard in the commercial open source space, followed by perhaps 80% or more of commercial software vendors? I feel like it is the industry standard commercial open source elephant in the room. There are certainly other valid business models that use other licenses or do not add commercial extensions, perhaps not as scalable as business models, but I am just trying to give a name to the most widely used and scalable business model that seems to be working quite well for both customers and communities.
- by bklawans September 3, 2008 12:00 PM PDT
- Mi Matt,
- Like this Reply to this comment
-
(3 Comments)I have to take issue with the claim that "Open-source vendors start making money from their customer base precisely at the point that the customer base is least likely to renew." I only agree if the vendor treats the customers like the traditional enterprise vendor treats their customers - abusively.
From my background in enterprise software and BI, a BI vendor typically tries to take significant license dollars from customers over a year before they can roll out a solution, and then add up to twice as much in services fee during the roll out. This means that a customer may have spent millions of dollars before they start to see any return on their spending, and once they get the system running they may well decide not to spend any more dollars on it - at least dollars payable to the vendor. They typically do keep using the software, but the money goes to internal staff.
With open source software, the customer may not have any incentive to pay the vendor until they are about to go live. This depends on the business model and licensing in use, of course. If the vendor is using any sort of split-license model, and the company deploying wants to use features that are not in the core open source product, they will only need to buy licenses when they are ready to deploy. Then the beauty of a subscription model kicks in - if the customer decides to stop paying, they lose access to the extra-value features. (As I've argued before, this seems fine as long as the core product is a "real" open source product, with an active community and useful in its own right. It doesn't work when the open source core is purposely crippled to force people to buy the "commercial" version.)
As I see it, with the right business model and the right attitude to customer service, an open source vendor should start making money from their customer base precisely at the point that the customer base is happiest with them - which just happens to be same time they are least likely to renew with a vendor they don't like.
-Barry Klawans