Software Product Pricing - The "Old Way"

Open source (maintenance only), Ad based revenue models and Subscription based pricing within the context of SaaS has truly redefined (and continue to do so) the way software products are priced. Although, open source and Ad based model are still in their nappies, Subscription based pricing is witnessing steady growth as more and more vendors move their software from On-Premise to “On-Demand”. Although, On Demand doesn’t necessarily guarantee “subscription based pricing” as proved in the case of “Oracle On-Demand” but most "On-Demand" players have a subscription based pricing model. Probably the right word to use here is SaaS and not On-Demand as analysts are increasingly mandating “subscription based pricing” as an important criterion for a software to be qualified as SaaS.

AMR Research defines SaaS as an application that:
· Has no upfront license fees associated with the use of the software (a subscription fee is generally billed monthly with a one- to two-year contract).
· Requires no IT infrastructure at the client site other than desktop devices and Internet access.
· Is deployed as multitenant (multiple customers sharing a single copy of the software) or single-tenant standard code maintained and upgraded by the vendor.
Has support and upgrades included in the monthly service fee.

Alright, I digressed a bit. This article is not about SaaS or subscription based pricing but it is about the traditional way of pricing software – Software Licensing. As I mentioned in my previous post (Software Pricing - The first P), one of the ways in which software companies have been able to link pricing with the benefit received from the product is by relating pricing with the “extent of usage” of the product. Although, this is not the best way of establishing the price-benefit equation, it is the easiest. In this article, I plan to describe some of the more common / traditional approaches to software licensing.

Per seat / Per named user - Traditionally the most widely used approach to software licensing was per seat or per named user. In this approach, for a given price a minimum no. of “named user” access is provided and for every additional seats an extra per seat price is charged. The client organization is required to comply with the agreed upon “number of seat” for the price charged. This approach works best when the user base is “named” i.e. clearly identified. And the extent of usage of the product directly correlates with the number of users using it. E.g. any desktop application.

Concurrent User – Another way in which the “extent of usage” of a product can be regulated is through ensuring restricted concurrent or simultaneous access within a slice of time (usually a fraction of a second). This works well when the size of the user base varies within a range. For example a knowledge management solution running behind a customer self-service website. The extent of usage here depends on the website traffic looking to get a problem solved. Client organizations typically pay for upto 75% of the peak concurrent access.

Per CPU – This approach to pricing assumes that the extent of usage is decided by the processing capacity of the processor. More the CPUs more the capacity and more the usage and hence more the price. Although, this mode of pricing is being increasingly abandoned most vendors still offer the “per CPU pricing option”. In fact, with the evolution of processors and the wide adoption of dual and quad processors, software companies have faced some interesting challenges in designing the per CPU pricing model. You can read about an interesting article on Oracle in this context here - http://news.com.com/Oracle+shifts+multicore+licensing+model/2100-1012_3-5788788.html

Per Server – This approach is a derivative of the per CPU model, typically used in situations where the extent of usage is a function of server capacity and not processing alone.

Other usage based pricing options - There are a few other usage based pricing options that correlate the price with number of units of the final work item it produces or work upon. For e.g. an analytics product company can price its product based on the “size” of the raw data it would be working on or a search product can price itself based on the number of documents it indexes etc.

The enforcement of these pricing options is still primarily being implemented through Legal Contract (in the case of as many as 51% of all software vendors) followed by Electronic / Digital enforcement (as in the case of around 45% of software vendors). Less than 5% of vendors are able to enforce their pricing options through online logging, these are primarily the SaaS providers.

SaaS has really opened up multiple new avenues to price software with aspects like subscription based pricing, correlating pricing to unit of work/transaction and so on. I plan to discuss the SaaS way of pricing in my next post. Till later. Ciao.