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...

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.

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.

About the author

Matt Asay is chief operating officer at Canonical, the company behind the Ubuntu Linux operating system. Prior to Canonical, Matt was general manager of the Americas division and vice president of business development at Alfresco, an open-source applications company. Matt 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. He is a member of the CNET Blog Network and is not an employee of CNET. You can follow Matt on Twitter @mjasay.
See full bio