It's Time for Seat-Based Software Licensing to End

Economic downturns tend to accelerate change in the IT world... Given the situation we're in, now might be as good a time as any for potential buyers of software systems (and licensees whose contract renewals are coming up) to declare war on per-seat pricing.

Kas Thomas, Contributor

April 10, 2009

4 Min Read

Economic downturns tend to accelerate change in the IT world: People with budgetary authority find themselves taking a fresh look at what they're spending money on, how and whether IT investments are paying off, why bad investments are not paying off, and what to do differently going forward.

Given the situation we're in, now might be as good a time as any for potential buyers of software systems -- and licensees whose contract renewals are coming up -- to declare war on per-seat pricing.Seat-based pricing has been declining in popularity for some time (everyone I know hates it), but like a weed growing out of a crack in the sidewalk, it never seems to go away entirely. In theory, per-user pricing is rational because it allows costs to scale in a predictable (and fair) fashion, according to an organization's size. But in reality, there are many problems with the "headcount equals usage" notion, the most obvious being that if nine people touch the system once a month and one person uses it eight hours a day, seven days a week, you still need 10 seat-licenses even though nine out of ten users are offline at any given time.

Some vendors try to address the idle-user problem by taking a "concurrent users" approach in which you pay according to how many simultaneous sessions you think the system will handle in times of peak demand. In the previous example, you might be able to get away with a two-concurrent-user license if the nine infrequent users could space out their sessions. But there are still problems. What if you can't anticipate what your "peak demand" will be? What if the demand is not uniform, but occurs in "spikey" fashion?

In a sales environment, it is common to have one sales manager servicing many sales reps on a day-to-day basis, but at month's end everyone in Finance may need to be on the system concurrently. The last thing you want is for someone in Finance to be prevented from doing a month-end analysis just because you don't have enough concurrent user licenses. So what do you do? You overbuy, of course. You purposely overestimate the number of concurrent users you think you'll need to support -- and then buy that many licenses. (Not a good way to save money. Nice for vendors, though.)

Another popular scheme is the "named user" approach. Here, the vendor requires you to list the names (and quite often the roles) of each and every person and process that will access the system in question. But questions arise: What if User A changes roles (or leaves the company)? If a whole department is laid off, will you get reimbursed for unused licenses? Are licenses transferable across departments -- or geos? Even if you can abide the basic terms, named-user licensing tends to be a compliance nightmare -- especially for large organizations, where administering partially overlapping license pools for dozens or hundreds of users and products can be hideously time-consuming, even when the process is semi-automated.

In general, seat-based licensing is burdensome, complex, and difficult to manage. It also encourages overbuying. One wonders: Why does it still exist?

One reason it still exists is that it enables vendors to put together 5- or 10-seat "entry level" packages at price points that are seductively low. Rarely do "starter packages" include all the various add-on modules and connectors you'll need to roll out a real-world system. "Starter" pricing is usually just a conversation-starter. It's a ploy to get you in the door.

These days, buyers of enterprise software are looking for simplicity -- simplicity in licensing, simplicity in accounting, simple APIs, uncomplicated UIs. If IT experts have learned anything in the past five years (years that have seen fast/simple technologies like Ruby on Rails, REST, and AJAX overturn a lot of apple carts), it's that complexity is costly. And in the current economic environment, there's no room for excess costs.

Per-seat licensing is a complication; it's out of step with the times. I suggest you point that out to the next vendor who insists on making you pay through the seat. Demand simpler terms. You're the customer, after all.Economic downturns tend to accelerate change in the IT world... Given the situation we're in, now might be as good a time as any for potential buyers of software systems (and licensees whose contract renewals are coming up) to declare war on per-seat pricing.

Read more about:

20092009

About the Author(s)

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights