Thompson, Steve wrote:
How do you price maint, upgrades, hardware swaps, etc. to ensure that
you have sufficient revenue to continue in business?
Steve:
Thank you for providing a thread for this discussion. It does indeed
need community input and should have ISVs contributing to the
discussion as well.
Unfortunately, many ISV participants here are developers for ISVs
rather than from upper management. The pricing policies certainly
aren't set by us developers where I'm currently employed; rather,
they're set somewhere in the sales/marketing/finance groups. I'm not
at all clear that sales/marketing/finance management from many
significant ISVs will have much to say here. I don't know if many
know much about these forums at all.
However, some of us _do_ forward things we find here to our
management. Not much more we can do.
As developers, we have both general and specific restrictions on
what we can say. That's how stuff works when you have an employer.
You don't hand out the really good and useful knowledge that is part
of the value of your employer's products (which sometimes means we
stay quiet when we have something that could be said) and you don't
put out many statements that cast negative light on employer
policies (which also means we stay quiet, etc.)
But I can say something about lawyers.
When you're in business and contracts get involved, there's a near
guarantee that lawyers are in there somewhere. (I'm already
wondering if I've said too much! :-) )
Lawyers are paid by the "company" and are pretty much dedicated to
the "company" perspective. They are not interested in whether
company customers are happy. They are paid for their expertise in
business/contract law. If they say something that contradicts a
developer viewpoint, there's little doubt which way it gets resolved.
So, licensing...
We have begun conversion from a proprietary licensing scheme to take
advantage of IBM software product APIs and related licensing
functions. It has /not/ been a trivial undertaking.
The IBM documentation was far from perfect when I started with it.
The product code wasn't well structured for it in its existing
forms. The understanding of its implications wasn't fully developed
in the various company divisions.
And the available IBM-supplied methods for setting license
attributes weren't exactly suited for handling any of our products
in the ways that finance/sales/marketing wanted it done.
Further, lawyers gave input on how to protect "company" assets.
Let's say a prospective customer obtains a copy of a product with a
license key. The install is on a 'test' system. A couple weeks
later, that customer calls to say the product is going to be moved
to the 'production' system and can they please have an appropriate
license key?
The "company" owners, or the venture capitalists, or the
stockholders, whoever has been financing things, want to be sure
that this is really moving the product to a new system, rather than
just getting a new license for free.
Or maybe the customer consolidated ten systems to a new 10-LPAR
system and now wants just a single license key for the new serial
number. Somebody near the top of the "company" is on the hook for
protecting "company" assets; a license key for a given serial number
can work in each LPAR. (It's possible to generate unique keys per
LPAR, but it's kind of a kludge.)
So, here we are, trying to improve the product by jettisoning old
proprietary license code, by standardizing on LPP creation through
IBM-supplied APIs, by enabling standardized PTF handling, by
standardizing on reasonably familiar SAV/RST/DLTLICPGM, by using
standard ADDLICKEY and WRKLICINF and all the other things that most
customers have already seen.
And it mostly revolves around the licensing APIs in order to provide
protection so that the "company" owners can get lawyers to 'OK' the
structure.
But, IBM hasn't been particularly consistent in its licensing
definitions. Per CPU? Per user? Concurrent user? Registered user?
(LPAR? Fractional LPAR? LPAR w/AIX? Linux?)And IBM hasn't been
particularly consistent in the image it's presented of what "AS/400
or iSeries or System i or..." has been. Original flavor? Server
systems? Back-end database servers?
How is it possible to provide an appropriate level of quality for
any given customer? One customer might have mostly green-screen apps
doing traditional interactive work. The next customer might have a
monster system with (near) zero interactive CPW and all host servers
running transactions under QUSER. The next customer might be under
restrictive regulations where almost every connection has its own
specified user.
IBM gave us really only a few options. Basically, we can license by
serial#/processor group, or we can license by user. If we want to
off-load the effort needed for proprietary licensing, proprietary
install, proprietary upgrade, proprietary PTFs and any related
stuff, and put effort where it really should be -- into real product
code -- we are mostly dependent on the licensing technology that
goes along with it.
Here, we have mostly gotten through the 'software products APIs'
mine field. We're finally well into serious product improvement on a
significant scale.
So, what can be done about pricing?
What should I forward to my management? It's clear that there are
major dissatisfactions with some approaches to licensing. What
suggestions are out there that will get my bosses to pay attention
and to come up with a rational pricing structure? Assets need
protection or they simply won't be sold (licensed). How can
protection and customer satisfaction be balanced?
I will gladly see to it that my management sees meaningful replies.
I'm pretty sure other ISVs have members here that will do the similarly.
Maybe this group can outline a truly useful strategy. (Hmmm... a
policy kind of thing in the Midrange Wiki? Eventually. Maybe.)
Tom Liotta
midrange.com
