Re: Software Vendors -- MIDRANGE-L

Buck,

You are right, of course. I assumed that everyone agreed on what a "bug"
is. That's not always the case. For us it is usually pretty clear what
is a program failure and what is an enhancement to the panel flow or
business logic. But in complex business applications there can be some
cross-over between expectations on how software *should* work with
errors in how it actually works. I suppose it can get messy to sort that
out. For us its not much of an issue. Whenever we encounter customers
who want enhancements in our product we tend to treat that as an
opportunity to make the product better. 

I do think software vendors can be clear about their policy for
providing fixes for errors in software. Ours is: we fix any errors
during the trial period free of charge (like, what else would you
expect?). If there is a cost in shipping the fix to the customer we pay
for it. All of our software is covered for bug fixes and planned
releases for 90 days after purchase free of charge. After 90 days you
need to be on our maintenance agreement to get new releases and
immediate bug fixes. 

There was a time when most software included free support for the life
of the product (back in the good ol' days). With the unbundling of
services, software and support, it became almost universal for vendors
to charge a separate contract for maintenance. User's demanded it - they
wanted to know what it cost and wanted the freedom to take it or leave
it. Most of our customers take it. But some don't. That's OK. Over time
a lot of the folks who don't initially take maintenance pick it up
later. They like to get the enhancements when they come out.

It looks like the new model will be "software subscription". I think
Microsoft and IBM are both pushing this. I don't like it very much
myself, but we probably won't get much choice, eh?

Patrick

Buck Calabro wrote:
> 
> Patrick,
> Very humbly, may I suggest that the model you use would break down if the
> customer insists that every thing that they don't like is a bug.  Anybody
> who's ever replaced a competitor's package has heard "But we always did it
> THIS way when we used ZZZSoft."  Sadly, "bug" or "software problem" is
> rarely spelt out in the contract, and the vendor has an unpleasant handful
> of choices: Make the mods and eat the cost, make the mods and charge for
> them, don't make the mods and explain that "this is the way it works".  When
> the customer thinks "their" package shouldn't need mods in the first place,
> which of these options will please the customer the most?
> 
> What a bug is should be reasonably clear in the contract language: any
> deviation from proper operation.  How many packages have good enough specs
> to be able to make out what that means?  In reality, "bugs" exist on a fuzzy
> dim spectrum, ranging from white messages (divide by zero, record lock, etc.
> - clearly a bug) to report spacing/level breaks (less clear, especially if
> the totals are correct) to missing reports/displays ("ZZZSoft had a report
> to do that" - incorrect expectations?) to user interface questions ("why do
> we need to go through 3 menus to reach this?") to corrupted data ("but WHY
> can't we run the month close in the middle of the month?  We want to see how
> we're doing!"- user error) to ease of use ("I can't find the purge menu -
> where is it?" - the documentation tells you that each sub-system has it's
> own purge option, unlike ZZZSoft).  A user may legitimately argue that all
> of these examples are bugs, whereas a vendor might legitimately argue that
> only white messages are bugs.
> 
> If this were Utopia, the vendor and customer would negotiate the "what's a
> bug" question before the sale.  The customer would also make every effort to
> let the line people understand that the new package is replacing ZZZSoft
> because it's better, not because some executive had a whim.  The customer
> would view the vendor as a partner, not an opponent and vice versa.  Ahhh,
> if only we were in Utopia...
> 
> Humbly, quietly and very respectfully,
> 
> Buck Calabro
> Aptis; Albany, NY
> 
> > -----Original Message-----
> > From: Patrick Townsend
> > Sent: Monday, November 29, 1999 2:04 PM
> > To:   MIDRANGE-L@midrange.com
> > Subject:      Re: Software Vendors
> >
> -snip-
> 
> > And I can't imagine a software vendor charging you for
> > consulting time to fix a software problem. I'd be inclined
> > to send the software back!
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---

-- 
IBM AS/400 communications, FTP automation, and network security
software and consulting services.

http://www.patownsend.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---