I recently had the opportunity to chat with Pete Malcolm, Chief Executive Officer of Abiquo, about pricing policies of some of the suppliers of virtual machine software. The conversation was prompted by VMware’s announcement of a new pricing model and VMware backing away somewhat from that model a short time later. The discussion started on what Pete was hearing from his customers and from others in the industry and turned into a lovely historical perspective of pricing and value.
Pricing
Coming up with a pricing model for products and services is somewhat of a black art. The goal is setting a price that will encourage customers to purchase a product and produce a reasonable amount of revenue for the supplier. The price, of course, should cover basic costs of product development, testing, production and support. It should also be set based upon the value the customer perceives.
Problems arise when the supplier holds a belief that includes a higher value than the customer does. In cases such as that, the product pricing appears to be excessive to the customer.
What’s a reasonable approach to pricing?
It can be very difficult to determine the value of system software, such as operating systems or virtual machine software (hypervisors). On the one hand, systems won’t function at all if they are not present. On the other, most people don’t really understand what such low level software does, how it does it, its importance and so, think that is has minimal, if any value.
Over time, many different approaches have been tried. None of them have been acclaimed as being universally fair or equitable. Here are a few examples:
- Per physical system pricing— this approach was common for system software running on physical systems having a single processor
- Per processor system pricing — as multiprocessor systems became the norm, some suppliers charged a price based upon the number of processors in a system configuration. As processor suppliers put multiple execution units, or cores, on a single chip, this model was extended to count the number of cores rather than the number of chips. Since this approach didn’t account for the processing power of these processors or the number of users being supported, it was seen as unfair.
- Tiered per system pricing — this approach was an attempt to price system software based upon the presumption that larger/faster machines produced additional customer value, regardless of the number of applications or user workloads were being run. This was seen as unfair if a system was supporting a single, very large workload that was used by a very small community within a company.
- Tier per processor system pricing — this approach is a combination of pricing model 2 and 3. It attempted to deal with the complaint that pricing had little to do with actual system usage. As with the other models, it was the subject of many complaints. This is the approach Oracle uses for some of its products.
- Per user pricing — rather than charging based upon system configuration or performance, some suppliers decided that a true measure of value was the number of users the configuration supported. Complaints rose because often the supplier would charge a fee based upon the number of people using a system or the number of employees in a company without any regard for how many people were using their software.
- Per user plus some variant of system pricing — some suppliers (Microsoft and its ecosystem) tried an approach to capture revenue based upon the number of users plus revenue based upon the systems. This model caused some to be complain because they were expected to pay a client access license fee even when the user was using a system having no software from that supplier. Microsoft and its ecosystem use a version of this model today.
VMware appears to have felt that it wasn’t getting enough revenue for the value it was providing. It put forward a model that was based upon a combination of cores, memory being used and a few other factors to set a price. Customers screamed that this amounted to a “hypervisor tax” on their operations. After a short while, VMware backed off slightly, but is still using a similar pricing model. I still hear complaints from VMware partners and customers.
Snapshot analysis
It is clear that there is no perfect model for system software pricing. Many different approaches have been tried and none of them are seen as universally equitable or fair. What is clear is that VMware has poked an industry wasp’s nest with their approach to pricing their hypervisor. It has given Citrix, Oracle, Red Hat and the open source community the opportunity to present their less-costly approach to pricing and suggest that their products should be considered as replacements for those offered by VMware.
Some IT industry executives I’ve spoken to have indicated that their organization has started a pilot project to test some of these alternatives to see if production environments can successfully be supported by these other products. It is possible that these organizations will just use these projects to extract a lower price from VMware. It is also possible that VMware’s pricing move will open the data center door to others.
