HP3000-L Archives

November 1998, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jim Alexander <[log in to unmask]>
Reply To:
Date:
Wed, 18 Nov 1998 09:12:52 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (45 lines)
OK  Here's my .02 worth.  After working for two HP3000 software vendors and
watching the pricing discussion from both sides, here is what I think.

Software should be priced on a per-seat price.   That is, by the number of
concurrent users of the product.  If there is an environment like (just an
example)  Powerhouse with a development and run time portions, then it should
be priced so that the development is tied to the number of people using the
development tool (or the number of concurrent users of the development tool
which would be one use having more than one iteration running counting as
multiple users) and then the run time portion being charged with the actual
number of run time executions of the product in use.

There could be the possibility of a company having only one developer and
thousands of user utilizing the software.   This seems to spread the cost
equally.  No matter what kind of box you are running on, you pay for utility
nature of the software, not the perceived value base on the power of the box.

I don't offer methods for doing this, I don't have too.  I am not the one
charging for software, but this method would seem to be the most fair.

Going back to the supermarket example ... it transforms perfectly.   I only
have to purchase enough food to feed my wife and myself.   If I three kids, I
would have to purchase more food.   Not pay a higher price for the food, just
purchase more food.     Conversely, if we have 10 programmers using a
development environment we should pay for 10 development 'SEATS', if we have
300 run time users, we should pay for 300 run time 'SEATS'.   When we add
either development or run time people, we add more 'SEATS'.

For any vendor on this list, I challenge to explain why this is not
reasonable?   There may be exceptions, but generally this seems to be the
most fair way to do pricing.

Discounts:

If a vendor chooses to discount the per 'SEAT' price because of quantity
chosen, that is their business and no one should be offended.   Just like I
can go CostCo and buy a large quantity of something and get a better price
than I get at Safeway ... but that is because I decide to buy the larger
quantity, not because of who I am.

--
Jim Alexander   Longs Drug Stores
Sr. Systems Programmer  925-210-6901
The opinions expressed are Mine and not Longs Drugs

ATOM RSS1 RSS2