AGlauser@xxxxxxxxxxxx wrote:
It's sort of a short-cut way doing
user-based pricing. It's always seemed to me that support prices based on
number of users makes complete sense, but charging for the software itself
makes very little sense. The only argument I can see is that building
software that scales well for large numbers of users is more difficult.
Adam:
I have little or no input towards how our products are priced; but I
am aware of some related issues involving scaling and, indirectly,
CPW. Any comments on this are purely my own from general opinion...
We have one customer who has an unusual requirement. Their system is
hammered with a ship-load of transactions every business morning
when 'The Market' opens. These transactions cannot be noticeably
delayed by our processing. This peculiar flood of transactions is
limited to just those few minutes; the rest of the day is relatively
'normal' processing.
It took a significant effort to create and implement the structures,
objects and procedures that could react to such a drastic change.
Most customers of ours could hardly care less since the changes
brought no significant differences for them; but all of our large
customers with heavy transaction loads benefited from the upgrade
and will continue to benefit. Some System i sites handle very large
transaction counts.
Note that APIs support "tier-based" licensing. This is true both on
the license generation and the license usage side. Processor Group
is a supported machine attribute for generating a unique license.
But 'number of transactions in a 4-minute span'...?
Tiered pricing makes some sense to me when I consider how it focuses
our efforts. It makes little sense to put such focus into
lower-tiered pricing schemes when the vast majority of customers
couldn't tell the difference. We'd be continually catering to the
lowest common denominator and gradually alienating the big sites
that provide a lot of IBM's reason for keeping System i alive.
A good product might sell into 10% of installed sites. Only 5% of
those might be large sites. Without tiered pricing, there seems to
be no good way of justifying some types of effort. If anybody has
suggestions, I'm confident every product vendor on the list will
listen with attention.
I
also realize that there are other matters involved. Whether or not you can
trust customers to accurately report number of users is one. It also
seems much easier to charge x% of list for support rather than requiring a
specific support contract for each customer.
It took me quite a while to figure out how to get the OS/400
licensing APIs to support LPAR licenses for LPPs. (AFAIK, IBM still
doesn't even manage to do it.)
Now, because of IBM's moves in the direction of user-based pricing,
we're looking at how it might work for us. As it is, there isn't
even a good way to determine how many "users" exist, much less work
out how pricing might be associated.
IBM necessarily leads in how licensing is done. A secure System i
product needs to implement its security through the facilities of
the operating system. As we work more into distributing LPPs, the
software product APIs are what we have to work with. The "user"
licensing currently available through the APIs doesn't yet quite
seem to be appropriate, so we have to move slowly.
One of our working assumptions is that a break in OS/400 licensing
security is a break that IBM will move quickly to correct since they
rely on it themselves. Our older 'proprietary' scheme is far less
certain. The need to wait for IBM brings a slowdown that's not easy
to explain to customers.
I got lucky in figuring out LPARs. I don't expect a similar insight
for however "user-based" pricing might eventually look.
Just a final reminder that I'm writing purely out of personal
opinion on this issue.
Tom Liotta
midrange.com
