IBM’s Processor Value Units
Being a customer of Big Blue can be pretty painful sometimes. We recently learned that IBM has conveniently decided to radically restructure their licensing agreements around Websphere. Their plan to make sure they get all possible revenue is to charge per core on a processor and per processor type.
According to our contract they can just change things midstream like this without consultation. So our say 50 current processor licenses for Websphere have now been converted with the following formula:
Current per Processor Entitlements x 100 = New Processor Value Unit Entitlements
Thus instead of 50 CPU licenses we now have the wonderful 5000 processor value units. The whole thing reminds me of the Bill Cosby Noah routine:
Big Blue: We shall convert your CPU licenses to processor value units.
Noah: Right…, What’s a processor value unit?
David Ogren thinks it’s the worst licensing model he’s seen yet:
But perhaps worst of all is what IBM just announced for it’s middleware pricing. They’ve brought back the idea of “power units” or MIPS based pricing, this time calling it “processor value units”. IBM portrays this as providing for more flexibility and simplicity in pricing. (I think flexibility in this context means “we can charge you more”.) Most disturbing is their announced intention to “differentiate licensing of middleware on processors .. [evolving] to differentiate processor families based on their relative performance”. Meaning that if a faster processor comes out, IBM plans on charging you more to run their software. Or they might charge you more to run on Sun SPARC chips than IBM chips.
As I remember Oracle tried a similar scheme back in 2000-1 and had to drop it after their customers screamed and sales dropped. From a customer standpoint this is just a really problematic policy. As soon as you upgrade your hardware in the next few years your licensing costs could jump through the roof, probably something your company never budgeted for.
I think IBM is just making the open source software model even more tempting with JBoss or even IBM’s own Apache Geronimo. Suddenly my licensing problems go away, and I can deploy on any hardware I want or setup clusters without forking over the dollars. At the end of the day Big Blue is a services company and this licensing model isn’t my idea of service.
Hi Ed,
not sure if this is an entirely bad thing.
On one hand you need to pay more if you utilize the software more, but on the other hand you can stick with old machines if that makes sense to you.
I have often seen that new, smaller, projects could have been deployed on boxes that larger projects had outgrown and that weren’t really used anymore. But because of the traditional licensing scheme it would sometimes make more sense to buy more “current” machines in order to reduce the number of licenses.
Of course it is always annoying to care for that stuff at all. But besides getting it all for free, there aren’t so many options for a fair licensing scheme. Licensing based on users or something like that is also annoying to monitor and report. Any ideas?
Cheers,
Mariano
ps. Full disclosure, I work for IBM, but am not part of our Software Group and not directly involved with selling or pricing our software.
On sticking to old machines, that works fine for now and the next year or two. We won’t be buying a lot of new servers. This gives us plenty of time to find out how the licensing scheme will shake out.
The issue is if the current scheme is still in place. Two years out I’d expect 8 or 16 core processors will be the standard CPU in servers. Buying dual core or lower may involve shopping on eBay or the like for old processors. That doesn’t make a lot of sense, and likely vendors like IBM will add powerful new features that assume you have more processing power and are running 8-16 cores on a 2 CPU server. And you probably don’t want to downsize to a single CPU even if it has 8 cores since you get no redundancy if it fails.
A ironic development for us soon may be that we are possibly buying 4 core processor desktop machines for all the developers, so our desktops might be more powerful than quite a few of our servers.
I agree that the licensing scheme is difficult, and I don’t pretend to know the best answer. The simple answer is to go open source and be freed from the licensing hassle altogether. For vendors like IBM who make more on consulting anyway this appears to be one option.
I suppose if I were CIO I’d like some sort of Enterprise license agreement where for some sufficiently large negotiated lump sum I could use as much as I wanted of the software. Then once negotiated I have zero surprises over the next 2-3 years on costs, and we don’t have to spend our time doing things like we do currently like pulling 2 CPUs out of a 4 processor server to stay in license compliance. Obviously this sort of thing has all sorts of issues, but it does heavily reduce the licensing tracking pain.
Hi Ed,
I tend to agree. Oracle has a real stronghold in the database segment because of their enterprise licenses. I am not sure though how they come up with a price. I guess that a company with 100 employees pays less than a company with 100.000 employees.
The other thin that is bad about traditional licensing schemes is that they block grass root adoption.
If you wouldn’t have to pay for a Tivoli license to monitor your own dev servers, maybe that would help to spread the adoption of Tivoli as a whole. My personal experience is that Tivoli is not known to developers, because it is only used in the data centers or “in production”, so there is not much exposure.
As a developer with commercial licenses I prefer the ones where there is no licensing fee unless you use it in a production application. You’re free to try things out and decide whether it’s worth paying for.
As for Tivoli I’d agree. I know the name, I realize it’s somewhere in the server monitoring software space and has things like HP Openview as a competitor, but thats the most I’ve ever learned about it.