Price per CPU is foolish and price per core reaches its end

I have been scratching my head recently on software vendors policies regarding pricing and multi core pricing. The game is completely foolish and hopefully will reach its end soon, as more and more vendors will show up pricing per user to best serve the SaaS model of their customers, or pricing per instance (read JVM instance, or software server instance in a generic fashion).

Lets give it some background first and take the example of a small software vendor selling a distributed in-memory cache - aka Tangosol now owned by Oracle. Up until very recently before the Oracle acquisition, Tangosol had public price on its website, on a "per CPU" (in clear text) basis.
In August 2007 they shipped a minor version of their software (now owned by Oracle) and announced a new price of about twice more expensive. I dare to raise the issue and Cameron (Tangosol former CEO now at Oracle) kindly dare to answer it: Tangosol was priced per core and not per CPU despite advertised as per CPU on their web site... Due to Oracle policies regarding CPU and core pricing, they had to go thru this price change.
Read it here.
(no offense to Tangosol, it's great stuff and I am glad they clarified this).

Conclusion 1: Don't trust advertised per CPU prices. Anyone advertising per CPU price without disclosing complete details regarding CPU and core policies is lying to defer the price debate, and brings complexity in a TCO comparison if they are in a competitive situation.

Next step, let's recap on vendor policies regarding CPU and cores...

You already know that you cannot buy single core x86 (Intel/AMD) chips anymore, that the norm is dual core, and that quad core per chip (read per socket on the mother board, with 1 socket = 1 CPU) will be the default in a 6 months timeframe (go check on dell.com, you can already buy quad CPU quad core servers).

(disclaimer: this data is from searching in public sources):
For Oracle, you can read that each core accounts for either 0.5 or 0.75 CPU depending if it is a total dual core or quad core. So a double core costs 1.5 CPU units and a quad core costs 2 CPU units.
Read it here and here.
A quad CPU quad core costs 8 CPU units at Oracle.

For BEA, you can read that each core accounts for 0.25 CPUstarting at the 3rd core in a single CPU. So a dual core costs 1 CPU unit and a quad core costs 1.5 CPU units.
Read details here.
A quad CPU quad core costs 6 CPU units at BEA.

For IBM, they switched to a proprietary defined Processor Value Unit that is assumed to better assess various processor architectures. In fact this is quite similar to what Oracle does if you look here and on IBM site here.
A quad CPU quad core costs 8 CPU units at IBM.

For RedHat / JBoss (this is a subscription based business model but still), you can read half about it on RedHat site here and look at the JBoss TCO calculator here.
It works thru 4 CPU packs, but I could not find any information on what their CPU means... so let's exclude it for now...

All in all, you can get a 25% price difference just by considering this CPU unit. Oracle can tell you its stuff is 25% cheaper compared to BEA, you'll give them exactly the same amount of money in the end on a quad CPU quad core hardware.

Fair enough you said ??

Lets consider a few points:
- do the business project people and admins know how many cores total they will need to run on, currently run on?
- do they instead perfectly know how many server instances and apps they have to start stop operate and monitor?
- should your software license price be directly impacted if an application increases or decreases in overall throughput because business project owners asked this and that new feature to be added?
- did you already over-provisionned your hardware platforms to hide this fact?
- did you took time to ask the vendor policies regarding virtualisation? What if you turn the 4 CPU quad core box in 8 virtual 4 (virtual) CPU ""quad core""(they are virtualized now right?) system to maximize its utilization?
- do you have a virtualization or resource brokering project (read dynamic intelligent real time throw in on-demand adaptive capacity) and you are close to the day you'll click a button to move an app instance running on this old 2 CPU dual core to your new 4 CPU quad core hardware when it is on peak load (heard about VMotion and XenMotion already right?) and with no downtime. Did you thought on how you'll be able to optimize or even plan your per CPU license costs in such a scheme?

It's obvious a per instance model (per JVM instance, per server software instance) brings simple answers to all these questions and is perfectly aligned with what IT and project people are held accountable for running real world apps.

The problem for switchers (BEA, IBM, Oracle and all /CPU vendor) is that it will lead them to fairly complex discussions with their switching customers, and the best exit is likely to start selling a (time limited) enterprise wide (project limited) licenses that does not account anything anymore (until you realize it - hey it's a sell/buy game!). The pain the vendor put on you to manage and account all these licenses even becomes part of its value proposition.
... up until a billback system is put in place to enable a pay for what you used model fully aligned on your own business running costs and ROI targets.