HP3000-L Archives

January 1997, Week 4

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:
John Alleyn-Day <[log in to unmask]>
Reply To:
John Alleyn-Day <[log in to unmask]>
Date:
Tue, 28 Jan 1997 12:24:04 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (81 lines)
Tier pricing is something that has bothered me a considerable period of
time.  I have been on both ends of this controversy; as a consultant to
various HP shop I have seen the sometimes unfair and unfortunate aspects of
tire pricing; as a software vendor, I have had to wrestle with the decision
of how to price my own software.

A great deal of the controversy arises from two points.

Firstly, software is not hardware and can be reproduced and used by many
people simultaneously.  Analogies with hardware break down very quickly -
of course it is not reasonable to pay an upgrade fee when you transfer you
car radio from your VW to your Mercedes - but if you want it in both places
you'll have to buy a second one.  If you have sixteen people using a
program on two machines, eight on each machine, it shouldn't cost any more
or less if you combine the two machines into a single more powerful machine
with all sixteen users.

Secondly, it seems reasonable at first sight, that software on a big
machine is going to get more use than on a smaller machine - this model
goes way back to the days of IBM mainframes, when it was probably a
reasonable assumption.  Although this may be true in some circumstances,
for most multiuser systems this assumption is not true and never has been
true.  This is particularly noticeable when you upgrade your system and get
charged all of these upgrade fees.

Now to put on my other hat.  A software developer invests a great deal of
time and money in producing her software, but sells it at a cost well under
what it costs to develop.  She does this on the basis that she will sell a
lot of copies.  If, for some reason, she doesn't sell enough, she will go
out of business.  This is the problem with piracy of PC products.  In the
HP3000 environment with a user-oriented product, she will also suffer if
she sells copies without regard to the number of users, because, when
systems are consolidated, only one copy will suffice where many were
required before.  Tier pricing is a very crude attempt to correct this.

I think that software can usefully be divided into two categories - user
software and system software.  Most application software is user software,
in that it is used by many users on a single system.  It seems reasonable
that a system used by five people should cost less than the same system
used by 100 people, regardless of the machine size.  Not only would this
help in selling the system to smaller users, but it avoids the sometimes
extortionate fees extracted on a system upgrade.  This is basically the
Symantec approach "treat the software like a book - if more than one person
needs to use it AT THE SAME TIME, you need another copy".  It is also the
general licensing pattern on networked software - it should be easily
implemented on an HP3000.

System software is in a different category, since it is more likely that
the benefit is proportional to the size of the machine, and some kind of
tier pricing seems to be justified. However, the details may need to vary
depending on the software concerned.

I think the biggest single source of unhappiness lies with certain software
which I guess we have agreed not to name (I imagine we could be in a lot of
trouble if we publicized their names).  This software is usually in the
category of programming languages that require run-time software.
Companies using this software have to face the problem of either paying an
outrageous fee just because they are moving to a bigger machine (or worse
still, consolidating several smaller machine) or eating the time and cost
of rewriting in a more conventional language that doesn't require a runtime
license.  There's not really very much that can be done about this, except
to hope that HP will pressure these suppliers to change their policy and to
vow never to buy one of those systems or to write another line of code for
them..

In conclusion, I would like to see HP put in some kind of general method
for controlling running copies of software.  I described in an earlier
message my own workaround for this, but I see this as only a stop-gap.

I presume that this issue is going to discussed at IPROF.  Which SIG will
take it up?



John D. Alleyn-Day
Alleyn-Day International
408-286-6421
408-286-6474 (Fax)
[log in to unmask]
http://www.Alleyn-Day.com

ATOM RSS1 RSS2