The FTE pricing gamble (for vendors)

September 23, 2013

A popular move with a number of vendors that we've tried to deal with is to offer us site licenses based (only) on how many FTEs we have (for those that have been lucky enough not to encounter this term, it means how many 'full time equivalent' people you have). In the process of this I've come to feel that offering FTE-based pricing is a high stakes gamble for a vendor, one that doesn't necessarily work in their favour. One way to put it is that FTE-based pricing is an artificial attempt to make us use the product everywhere.

In an FTE pricing model the actual per-unit price of the product depends on how widely you use it. If you use it everywhere or nearly everywhere then its price can be quite low. If you use it in only a few places and only for a few people, its effective price is very high. Compounding this is that FTE based licensing is generally priced with the assumption (either implicit or explicit) that the product will be widely used.

(Another way to put this comes from Windows licensing; you pay a 'FTE based product tax' for every person whether or not they use the product. The vendor goal is what it was for Microsoft, to make any alternative the more expensive choice because you are already paying for the vendor's product.)

Some vendors come to us with FTE pricing when we already use their product widely or near universally. These vendors can get away with FTE pricing even if it doesn't save us money (and sometimes it makes internal political sense). But other vendors have come to us with FTE pricing when they are not so widely used (and the vendor should know this), or even worse used only a bit (or not yet used at all). These vendors are playing a very high stakes gamble: they are betting that they can force us to pay their price and as a result push their product throughout the organization. This can and does backfire and when it backfires, it often does so violently. For obvious reasons, this goes especially badly when a vendor is trying to change a much cheaper long-standing pricing model to an FTE model.

(You would think that vendors would avoid doing something like this, but apparently not. I've been a (distant) spectator to just such a backfire recently, which is why this issue is on my mind.)

By the way, this FTE pricing model is especially dangerous with a larger organization because the absolute dollars involved are much bigger. If the only organizational unit a vendor will license for is 'the entire University of Toronto', well, I believe we are at something over 10,000 FTEs. You can imagine what that does to prices, among other things.

Sidebar: the problem with expensive university-wide licenses here

In some universities, IT and the IT budget are centrally provided and centrally managed. That is not the case here; faculties and departments and groups fund their IT individually. This means that there is generally no one place to fund an expensive university-wide license in one decision; instead it must be funded by running around to lots of different people to get them to chip in. This takes a lot of time and work and injects a lot of uncertainty into the process, especially if it must be renewed on a year to year basis (since next year a particular department may not have the budget or may decide that they don't have that much need and so on and so forth).

Written on 23 September 2013.
« ZFS filesystem compression and quotas
A semi-wish for an official 'null MX' standard »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Sep 23 22:44:04 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.