There must be a better way, and users should demand it.
Imagine youre at the store to buy a box of cereal, but none of the cereal boxes has a price listed. You ask a clerk the price; he tells you that it depends on how big your family is or if you plan on eating the cereal all at once or over several breakfasts or how big a bowl and what type of milk you use. He also recommends that you be billed every week to receive new cereal flavors when they come out. Youd like to compare cereals, but you cant because they each use different pricing plans. And you wont know the actual cost of the cereal box until you reach the checkout counter.
Ridiculous? It would be in a supermarket, but, sadly, a similar scenario is becoming normal in IT. A company buying an enterprise application could see a number of pricing plans: per CPU, per server, per client, unlimited enterprisewide and yearly subscription. Even nonenterprise applications can be confusingly priced.
We recently received a set of SKUs for Microsoft Office 2003 that listed more than 40 pricing options.
While this has always been a problem, it is clearly getting worse, as vendors look for creative ways to increase revenues and spark the interest of investors. This is surely whats behind Suns recent announcement of a new pricing model based on numbers of employees at a company.
The real problem with such plans is that they make it impossible to compare pricing. Many of these pricing plans bear no resemblance to one another: Its like dealing with two salespeople who speak different languages and dont speak your language. As an eWEEK Corporate Partner said to me, "Even when you think youve got it figured out, when you get the quote, its not what you expect."
Is this doing the vendors any good? Did Microsoft benefit from the customer backlash to its Licensing 6.0 and Software Assurance plans before it changed them earlier this year? Is confusing and annoying customers worth the "benefit" of customers not being able to tell how much your product costs?
Theres a clear lack of logic behind many of these pricing schemes. What sense does per-CPU pricing make in applications where processor power has absolutely no effect on performance and scalability?
Look at Suns new employee-based pricing for its Java Enterprise System. The plan is to charge $100 per employee based on the number of employees companies disclose to the Securities and Exchange Commission. Sun argues that its a simple plan that can be cost-effective compared with buying the individual Sun enterprise software separately. But picture a large national service company with 100,000 employees. Corporate IT purchases Java Enterprise System for key internal systems in an enterprise deployment. The price: $10 million per year.
Now, picture a high-powered and popular Internet commerce site. It purchases the same system and pushes it to its limits, running large server farms and handling massive real-time transactions. But it has only 100 employees, so it pays $10,000 per year for the exact same system that it will be using in a more high-end fashion.
Of course, this is an extreme example, and the service company would probably do better than that. But its clear that the Sun plan is not based on actual software usage. If you could do a survey of companies one year after implementation, you would find massive disparities in what different companies paid for the same product.
What can companies do about this? Well, if youre lucky enough to be working in a very large and powerful company, you can probably force vendors to comply with standard pricing schemes so you can compare options. But most companies dont have this kind of power over vendors.
There is, however, one thing you can do. Say no to the scheme, and tell the vendor why. IT budgets are much too sensitive now to take risks on unknown costs. When software vendors start losing sales, maybe theyll realize that forcing unfair and confusing pricing plans on customers is no way to do business. Discuss this in the eWEEK forum.
eWEEK Labs Director Jim Rapoza can be reached at email@example.com.