[haswell]

I think you overestimate the degree to which some software can be standardized and sold in a set of well-defined SKUs, and the degree to which some buyers want to be intimately familiar with extremely granular pricing (e.g. something like AWS).

Again, speaking only for the places I worked, part of the reason pricing wasn't simple was that larger customer deployments were tuned to the customer based on a myriad of factors ranging from the specific software modules the customer purchased, use cases they intended to deploy and the load characteristics of those use cases, etc.

Setting aside for a moment any potential bad behavior, the bottom line is that for some kinds of software, bespoke pricing is a more accurate reflection of the reality of the deployment than trying to force some kind of standardized label on it. The places I worked also had pricing books they'd show customers, but due to their complexity, they would not publish these publicly.

> bespoke pricing is a cynical tactic, no matter how you dress it up

We'll have to agree to disagree. Having worked with quite a few large vendors over the years, there are clear and obvious differences between them, better and worse reasons for this type of pricing, and there's a reason that some companies have earned a negative reputation while others have not.

It's also not clear to me why you've concluded that this is all inherently cynical.

[GuinansEyebrows]

maybe i overestimate. maybe i just appreciate the difference between the product and support for the product. for support, i understand a more-bespoke pricing model, but it'd be nice if there was at least some upfront inkling of how much i have to open my organization's veins in exchange for a working implementation.

interacting with capital is a cynical act. capitalism is predatory but it's necessary to interact with it. if you're not cynical, you risk being taken for a worse ride than you have to be. this isn't me handwaving things; it's a fundamental aspect to how i see the world. cynicism doesn't have to be a simple doom-and-gloom "well, everything is bad, end of discussion" (regardless of my personal feelings about it) - it can be a tool to make sure you're able to interact with systems in ways that benefit you and others while retaining whatever modicum of control you can - because even if you aren't, your vendor is (or they're on their way to being out of business as a profit-motivated entity).

[haswell]

> maybe i just appreciate the difference between the product and support for the product. for support, i understand a more-bespoke pricing model

I'm trying to frame this sentence so it doesn't sound like a jab because that's not my intent, but based on what you've written, I don't think you understand the kind of software I'm describing.

In your mind, what is the distinction between the two, especially for an enterprise solution hosted by a vendor? In my experience, the two are often not so different at all, and the clean lines you imagine here are not lines that exist in practice. This will depend on the nature of the software, and the kind of support customers need (i.e. infrastructure vs. implementation).

> but it'd be nice if there was at least some upfront inkling of how much i have to open my organization's veins in exchange for a working implementation.

You are assuming this is not part of the model, but it is. Not publicly listing a pricing sheet does not in any way mean a customer doesn't have clarity about how much their deployment will cost before they sign a contract.

> interacting with capital is a cynical act.

Your use of "cynical" is in a different category than what I was describing above. If we go with your definition, there is no reason to differentiate between bespoke pricing and up-front published pricing.