|
I worked for an ISV years ago with a S/36 package. When alternate indices came out, our owner told our clients that, unless they upgraded to the new release within (I think) a year, they would not be supported. But he decided that he could not afford to (a) have multiple /36's for development (and two different levels to the package), and (b) spend money on developers maintaining two packages, basically.
Very little grumbling from the customer base. Most of the feedback (I was Level 1 support) that I remember was, "Yeah, I've been meaning to do that. Now I guess I'll have to get off of my butt and do it." Some customers even paid us to do the upgrade for them; I got a few frequent flier miles that year.
For the most part IBM has the right idea: Support stops here. They have figured out more or less that the pay back for maintaining, say, V5R2 has ended; let's devote our (limited) resources to upgrading the system.
A lot of this is pure laziness. I know of a company locally that's doing development on a V4R5 box while production is running V5R2. The only reason I've heard is that "Admin just hasn't had a chance to install another LPAR on the 5.2 box," but I've heard that for over a year. No ISV, that I know of, involved there. They (the developers) come to sessions I give at the LUG even though the sessions are all 5.3/.4 level. I've had they ask me, "How could you do that on 4.5?" My response is always either, "I forget," or "You can't."
I find it very hard to believe that a vendor is taking maintenance fees for a v4 (or earlier) system and actually updating it. But I'm sure that's just the cynic in me.
* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>
Buck wrote:
Charles wrote:
Aaron,I'm not Aaron, but I did work for an ISV for a decade. Everyone seems focussed on new sales (as in what customer buys new software to run on an antique machine?) From my perspective it's more a matter of supporting the existing customer base. When you sell your package to a customer who's on V4R4 way back when, then time passes and despite your advice, cajoling, wheedling and prayers they simply refuse to upgrade _but_ are willing to pay you your monthly support fee, what do you as a software house do? Tell your customer to buzz off? We don't want your money, your loyalty or your patronage? With upset existing customers, who do you turn to for referrals to sell the package to new customers?
Have you considered simply making available an older version of your software for those older
releases?
I'm sure there'd be differences in functionality, but if a customer is willing to accept the
difference in OS functionality, why should they expect the available software to be up to date?
If I was running Win95, I don't expect to be able run WinXP applications.Probably not. But like most midrange vs PC analogies, this one's weakness is the matter of support. It's very unlikely that you are running your business on a Win 95 package that you pay support on. It's way more likely that you are running your business on my package on V4R5 and paying me for support. You want bugs fixed and you want new features for your monthly fee.
The ISV is in a difficult spot - telling a customer he can't have the new goodies is very likely to see him stop paying for support. We had better luck writing the cutoff into the original sales contract, which larger companies shrug at - of course they're going to stay current in their OS software. Little companies are not nearly as happy go lucky about buying the new OS, installing it or getting PTFs for it.
If you're an ISV selling to small organisations, you have a very different customer base compared to large organisations, which is a very different problem from standalone companies with their own IT staff.
--buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.