It is comforting to know that satire is alive and well in IT. How boring life would be without it.
>However, as I recall it being explained to me by another, the "tier >based" pricings started when a big outsourcer (EDS?) would bid for >small companies' IT business. EDS was cheaper because they had a >huge data center which they would "parcel up". But that big data center >paid the same software cost as the smaller ones. So, instead on "n" >small accounts (all paying they same), the software vendor ended up >with one big account, again paying one license instead of the "n" small >accounts. Is this "fair"? IMO, no, it is not. Of course, now that software >is a bigger slice of the income, the effect is magnified. It is called "economies of scale", not price gouging, and yes, it is fair for EDS (as much as I don't like to admit it) to realize the efficiencies of such "economies of scale" because they have incurred the "business risk" of building said large installations and are justified in trying to improve their utilization, efficiency, to defray that risk. What is not just or equitable is for IBM to view EDS' efficiency and profits from "economies of scale" as a loss of revenue to themselves (IBM) and then create a pricing scheme that appropriates those profits from such efficiencies for themselves. Since when have monopolies ever been interested in efficiencies except for their own profitability. Monopolies do not optimize the efficient allocation of resources in the economy. They maximize their own profitablity at the expense of efficient allocation of resources in the economy. The is the basic evil of monopolies (Microeconmics 101). It is opposite of "The greatest good for the greatest number". On Mon, Mar 8, 2010 at 1:32 PM, Scott Rowe <[email protected]> wrote: > Wow, what an inappropriate analogy. > > >>> George Henke <[email protected]> 3/8/2010 12:24 PM >>> > Agreed. > > So the next time I fill up at the gas station the price should be based on > horsepower. All the SUV's should pay vastlly more for the same gas that I > use for my Honda Civic. > > I always use high-test since high-octane is always better even for small > cars, better mileage and cooler running engines. The grade of gas used > affects the temperature of the engine. It is one reason, why airplanes use > special high octane gas. > > Capacity based pricing has nothing but "greed" written all over it. > > How can IBM even keep a straight face when they say "shipping capacity that > isn't used 'doesn't make sense'" > > What doesn't make sense is "capacity-based pricing". > > Rationalization: Completely logical, just not true. > > On Mon, Mar 8, 2010 at 11:55 AM, Ted MacNEIL <[email protected]> wrote: > > > >The contention was that IBM shipping capacity that isn't used "doesn't > > make sense". > > > > A contention which I disagree with. > > It's cheaper to build one type of chip/card, and use other methods to > limit > > capacity, which is what software pricing is based on. > > > > I knew, in the mid-1980's, when IBM introduced model groups, that > > capacity-based pricing was going to introduce headaches. > > I told IBM this, at the time, but they didn't appear to care. > > > > My job has been, for over 30 years, to manage, forecast, and configure > > processors (and other hardware), and I do not like performing unnatural > acts > > to conform to flawed pricing models. > > That takes away any value I can bring to the business. > > > > IBM, and the ISV's, don't get this. > > Each pricing solution, IBM comes up with, seems to be more flawed (and > > complex) than the previous one. > > Unfortunately, when it's the only game in town, you have no choice but to > > comply. > > > > Complaining (especially to IBM), gets you nothing but a chance to vent > your > > spleen. > > - > > Too busy driving to stop for gas! > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > -- > George Henke > (C) 845 401 5614 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains > confidential and privileged information intended only for the addressee. If > you are not the intended recipient, please be advised that you have received > this material in error and that any forwarding, copying, printing, > distribution, use or disclosure of the material is strictly prohibited. If > you have received this material in error, please (i) do not read it, (ii) > reply to the sender that you received the message in error, and (iii) erase > or destroy the material. Emails are not secure and can be intercepted, > amended, lost or destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by email. Thank you. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- George Henke (C) 845 401 5614 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
