I went into a store the other day to buy a pressure washer to clean the siding on my house. I found a good model and asked the sales person its price. "It's quite reasonable," he said. "How many people are in your house?" I was a bit confused. "Sorry," I replied, "wasn't I asking you about the price of this unit?"
"Sure," he said, with a winning sales guy smile, "but this unit is sold on a per-seat basis. It costs $75 per household member. So how many folks are in your house?" "Well, I'm the only person who's going to use it," I answered defensively. "Doesn't matter," he countered. "We charge by the household size. How many pulses in the place?" "What happens if I don't give you the right answer?"
"Well," he said, the smile dimming a bit, "we can audit you at any time and if you haven't covered every household member (it's your responsibility to keep us up to date), we can hit you with a really big fine." "You know," I finally said, "I think I'll just get out the ladder and scrub the siding by hand."

Okay, that didn't really happen, but something similar happens all the time in the network business. For those who've not run into this phenomenon, many software vendors--software tools vendors in particular--have adopted pricing not according to number of servers, number of processors, or even number of network administrators. Instead, these vendors charge by the employee, regardless of whether the employees use their software. Think of this pricing model as "if it has a pulse, we sell you a license" pricing. It's one of the worst things to happen to software buyers in a long while.

I first ran across per-seat pricing years ago when Active Directory (AD) first came out. As an early AD adopter, I was excited by the potential power of Group Policy. However, Microsoft initially offered little help for diagnosing the new technology, so I was happy to see a vendor deliver a powerful Group Policy management and troubleshooting tool. Then I learned that the product cost $35 per seat. "Ah well," I thought, "I can live without it; I don't want to become attached to a utility that I can't in good conscience recommend to my readers and clients."

But what's wrong with this pricing scheme? Economic theory says that in a healthy market, prices are driven by long-run marginal costs, and that model works fairly well for analyzing other markets. So, what drives long-run marginal costs for the software industry?

You have the cost of developing and maintaining the software, but that's mainly a fixed cost--building a tool that one person uses costs roughly the same as building one that a million people use. So let's look at the per-customer costs. In the software business, the per-customer costs are largely support costs; it seems to me that the number of administrators, not users, drives those support costs up. Let's consider two firms: Firm A has 1000 users and two administrators, and firm B has 1000 users and 10 administrators. Which firm will cost a software vendor more to service? I'd guess firm B--it has more administrators, either because the administrators are less efficient or because firm B does something that's more IT-intensive than firm A. (Imagine that firm A provides legal transcription and firm B is an outsourcing firm that remotely supports a variety of businesses and you'll see what I mean.)

Under a per-seat approach, our mythical software vendor gets the same amount of money from firms A and B, but firm B will probably cost the vendor more money, and that's not good cost management. (Or perhaps firm B recognizes its heavy IT support needs and hires only the best of the best, who can often figure things out themselves. But overall, I think the number of administrators in a firm is a good indicator of the amount of support work that they generate.)

The fixit folks, not the typical user, use AD, Group Policy, and most other network administration tools. Suppose Snap-On Tools priced its wares on a per-client rather than a per-administrator basis. "Oh, you're a plumber and you need a wrench? Sure, I can get you a price on that ... How many clients do you have?" I suspect the plumber's first thought would be "What business do you have even knowing how many people's sinks I install?" It's not hard to understand why an administrator purchasing a tool to get her job done might feel the same way.

We're used to the idea that, at any time, the software storm troopers could kick down our doors and compare the number of machines we have running Microsoft Word to the number of licenses we've purchased. And yes, that situation is annoying. But at least all those Word licenses are being used. By way of contrast, ask Joe User how he likes his license for Wally's Amazing PC Census and Migration Tool and he'll probably feign an inability to understand English as he edges toward the door.

Do you know exactly how many users your network has? How often do you perform that census? Are you sure that you have precisely the number of licenses that you need for your AD, Group Policy, and similar tools? Probably not, but not because you're a software pirate; it's probably because you don't have the resources to determine your licensing requirements on a day-to-day basis, and you're probably busy keeping routers running, resetting passwords, and planning new rollouts.

Maybe I'm just behind the times, and per-seat pricing is the wave of the future. I'm getting ready to update my server book. Perhaps the publisher should adopt a more modern strategy. "You'd like to buy a copy of Mark's book? Great ... hey, how many people work in your company, anyway?"

Naah. I don't think so. Software tool vendors everywhere, please give this some thought: Think of your tools as pressure washers, and consider adopting pressure-washer-reasonable pricing policies.