• Subject: Re: Software Vendors
  • From: Patrick Townsend <townsend@xxxxxxxxxxxxxx>
  • Date: Mon, 29 Nov 1999 11:37:24 -0800
  • Organization: Patrick Townsend & Associates, Inc.

Jim,

I really don't think it is standard practice for software vendors to put
bugs in software in order to justify the cost of the maintenance
contract. I'm sorry if you've had that experience, but we've worked
closely with several small and large AS/400 software companies and I've
never seen this practice before. Everyone we've worked with consider
software bugs an expensive error to be avoided. It certainly does not
pay to have bugs in the code - almost all of our customers are on
maintenance anyway and every software bug we have to fix reduces our
profitability. I think the incentive is definitely on the side of error
free code!

Patrick

Jim Langston wrote:
> 
> You are not outdated in your thinking, the vendors are.
> 
> Unfortunately, this is an industry standard practice.
> 
> I quit one job because the owner/president actually PUT
> a bug in my code so he could charge his customers for
> maintenance.  His reasoning was that it could not be too
> good or they wouldn't pay maintenance fees.
> 
> If I was his customer and I found this out I would of sued
> him for every penny of maintenance fees I had ever paid.
> 
> Think about it, it pays for software providers to have bugs
> in their code.  If there are no bugs then you don't have to
> pay to get them fixed.
> 
> I believe it is morally, ethically and legally wrong.
> 
> Regards,
> 
> Jim Langston
> 
> Debbie Panco wrote:
> 
> > I have a question that has been plaguing me.  Say you have a software vendor
> > who sells
> > you a package and you have so many days to test the software that you
> > received.  During
> > your test period you find some problems, bring it to the vendor's attention
> > and they
> > get you the fixes.  Now, say that the test period has expired and during
> > some further
> > testing, you come across some other problem that was obviously resident in
> > the original
> > code. You bring it to your attention, but they now tell you that if you want
> > the problem
> > fixed, you will have to pay them to fix it because time spent now comes
> > under consulting
> > fees which are billable to you.  Now, this may be the way it is per the
> > contract and it
> > may be all legal and such.  But, from an ethical point of view, I have a
> > problem with this.
> > My thought is that regardless of how much time goes by, a vendor should be
> > financially
> > responsible for correcting programming or other technical problems that are
> > found within
> > their product.  I feel that their position should be: "Thanks, for finding
> > that error for us
> > and we will get right on coming up with a fix for it.".  But the attitudes
> > that we have
> > come across seem to be, "Well, you bought it as is and if you want it fixed
> > you will have to
> > pay us our current consulting fees to fix it.".  Is it just me or does
> > anyone else see
> > anything wrong with this logic?  Am I outdated in my thinking?
> 
> +---
> | 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
+---

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].