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.