I was reading through some old Jeff Nolan posts and came across this one, and it opened a sore. Jeff comments on this CNET article about Oracle's response to Microsoft's per-CPU/socket pricing. Microsoft made the decision to charge per-CPU/socket, not per-core, which throws a bit of a monkey wrench into Oracle's attempts to price per-core, and has the potential to discount Oracle's database pricing by as much as I was reading through some old Jeff Nolan posts and came across this one, and it opened a sore. Jeff comments on this CNET article about Oracle’s response to Microsoft’s per-CPU/socket pricing. Microsoft made the decision to charge per-CPU/socket, not per-core, which throws a bit of a monkey wrench into Oracle’s attempts to price per-core, and has the potential to discount Oracle’s database pricing by as much as 87%, as Stephen Shankland reported. I feel for Oracle on this, because customers derive real, tangible value from software running on improved hardware. Customers don’t necessarily see it this way, but it’s true. Why shouldn’t a customer pay for wringing more value out of its software (through improved hardware)? Jeff sees it very differently, and writes: Server-based pricing is a dinosaur, time to cut it loose and come up with something that doesn’t penalize customers for investing in their hardware infrastructure.I’m not sure I agree or disagree, mainly because I’m not sure of what the alternatives are. It’s a bit like Churchill’s famous quote:Democracy is the worst form of government, except for all those other forms that have been tried….MySQL charges per server. Alfresco charges per socket/CPU (irrespective of cores, though we discuss this issue at nearly every management meeting). SugarCRM charges per seat. JBoss used to charge per application. And so on. None of these is “right.” None are even necessarily ideal. But what are the alternatives? In my world (ECM), customers hate counting users, and paying accordingly. As nearly as I can tell, they also don’t like paying per server or per CPU. We had one customer at a recent advisory meeting suggest that we charge per support call, but 10 others shot down the idea. We used to kick around the idea of a pure subscription, but purchasing departments hated the idea of losing access to the software when they stopped paying (which is one reason for the subscription vs. licensing debate that Dave points out). The problem with getting clever with new pricing models is that purchasing departments are habituated to the old ones, and “clever” doesn’t help you much when you’re trying to close a deal. It takes an Oracle or IBM pushing the new model for the rest of the industry to be able to shift to it. (But even a titan can’t always force a change. Remember when Microsoft tried moving to subscriptions with License 6.0? Customers groused and grumbled until it went away. Several years later, subscriptions are all the rage, at least in some sectors. Not yet in mine, alas….)The only constant seems to be that people would prefer not to pay for things, and thus any business model that requires payment is always going to induce some grumbling. Unfortunately, all successful business models require payment from somebody. Will we eventually get to a Googlesque future where people don’t pay for anything, and instead stare at ads all day long? I hope not. I think Google’s ads work perfectly for some things, but I don’t think enterprise software is one of them. Which brings us back to the quandary. No one likes to pay for things. Payment for things is critical to actually getting things built. How can we make payment less burdensome, since it’s unlikely to be pleasant?Any ideas? I haven’t a clue. Open Source