7/21/2004

Per CPU RIP!

Oh how I have been waiting to see this issue really tackled This article titled: New server chips carry hidden cost points to a wonderful boondoggle in the world of proprietary software. The age old pricing model of charging for the number of CPUs you use a piece of software on will finally come to an end.

So there was a time when the cost of software was actually measured in man-years. I don't know if it was described that way at the time but, your sofware was written (for the most part) by staff programmers. The sale of software changed all that.

So now we need to come up with a new metric... The way I read current EULAs and licences you don't actually own anything when you buy software, so why not just whole hog lease it? I seem to remember that IBM only leased computers and software at one time... Microsoft would love it so of course that won't work.

Per seat / per user could work for some sofware. Per user licenses are common in the desktop and server world (perforce springs right to mind).

Maybe a tie to capacity... Oracle could charge based on the size and performance of the database. With regular audits, MySQL would rule...

OK, what do you get when you buy sofware? Someone to sue? Support? A warm feeling knowing that the BSA won't kill your company? Manuals? The permission to use?

Finally one that is real.

Looks like my above list contains one more... Support. So how about support? What is that worth? If it breaks you have someone to call and they will hopefully be able to fix it. This works in the Open Souce and proprietary worlds since the smelly hobbit at the end of the hall might not know that the problem is in a missing Xlib file called by some obscure AWT function buried in a preproccessor somewhere in your pipeline.

So how does support scale? Following the per user model, you could guess that each user is going to generate 2-3 support calls a year. Say $10 each call and we get a nice number to work with (again Perforce springs to mind).

Now what about server software? I'm still mulling that over, but the only differences between my little database supporting 2 adminstrative users tracking about a thousand people's medical insurance data and Kaiser's simmilar DB are cpacity and complexity. They have many more users though and I don't think they pay per seat for the terminals (though I could be wrong).

More pondering on this in the days to come. I'm fairly certain that perCPU is rightly dying as being irrelevant and unfair. I once blogged on this because of hyperthreading and 64-bit. Multicore makes it that much more apparent.

I leave you with this little one to ponder though: What is the difference between installing software on a 2Ghz uniprocessor computer and a DulaProcessor box clocked at 1Ghz?

Should you really pay twice as much money for the software?

Answers come later...

0 Comments:

Post a Comment

<< Home