A Personal Blog
Pricing Models
Ahh, pricing models.
Tim Bray argues that Per-CPU pricing is flawed:
To start with, it’s unstable in the face of Moore’s law and things like multi-coring. Second, and this argument is really unanswerable, it’s radically decoupled from both the cost to the vendor and the value to the user.
He argues that Sun’s overall per-employee costs make much more sense. To which I say: “Phooey!”
There is no one pricing model that will work for everyone. For example, we have 100 workstations in our nursing wards. These 100 workstations support upwards of 3000 staff. What model works best for that department? Well, per-workstation of course. Per employee would be ridiculous.
But, then we have over 2000 employees who work on single-user workstations. For them, per-employee or per-resource (mailbox, user agent, etc) billing makes a lot of sense.
Then there are application level things. Database servers, for example. For these, per-CPU makes a lot of sense purely because it scales incredibly well. We buy servers based on 5-year anticipated usage. For most apps that means 1-3 Dell PowerEdge 2850′s. So roughly 20K in hardware. We tack on another 30K for database software and we’re set, for the lifecycle of the app.
Per user doesn’t allow our clients to budget. Per workstation ties them down. For application-level licensing, at least on databases and infrastructure services, per-CPU makes a lot of sense.
I know I’m not really arguing with Tim on this:
But I am completely at a loss to think of a single software scenario where per-CPU pricing is rational or defensible.
I’m completely at a loss to think of a single scenario where any single kind of licensing is rational or defensible. Oh, and Tim, see above for a scenario where per-CPU licensing makes sense: unknown number of distinct users, unknown number of distinct workstations, unknown number of consistent concurrent connections (“from 50-200″, for example). Most of our departmental appliation database servers are this way here at work.
Oh, and speaking of Sun, we looked at pricing out a Sun solution along the same lines, just for kicks and giggles. Per-employee cost? 358$/month. Sorry Tim, that’s gotta come way down.
| Print article | This entry was posted by Jeremy Wright on October 19, 2004 at 11:09 am, and is filed under Business, IT Thoughts, Work. Follow any responses to this post through RSS 2.0. Both comments and pings are currently closed. |
Comments are closed.
about 7 years ago
Aah, see, we at MySQL have them all beat! Just a single per-server license fee, regardless on how many chips/cores/users/workstations/sheep are involved! Now that’s a hard one to argue against! ;)
about 7 years ago
You’re mixing apples and organges, clients and servers – Sun’s model makes total sense for server-side services. Per employee is the only reasonable model, and rewards businesses for being efficient (and for using the net to reach customers).
Client side licenses are just plain dumb, decoupled from the services they render.
about 7 years ago
No, I’m not mixing them. Put it this way, what drives server side requirements? More than anything else, the number of clients connecting does. It’s the whole “where do you store your bread” argument. Some people prefer to store it client side, others server side.
Neither model will work in every circumstance. A per-employee one won’t work in our nursing wards. A per-workstation one doesn’t scale well and requires intricate license management.
Per-CPU makes a lot of sense in a flexible environment where you know your upper and lower license boundaries. One day there might be 7,000 people here and the next day might see 9,000. In that kind of situation we require flexible licensing, something Sun’s licensing just couldn’t give us.