Jeremy asked: > Anyway, we have recently upgraded to the latest version of > their product, and now the custom search code does not work, > and they waht to charge us for fixing the problem. > > Now, to my mind, when I do say a custom report and I change > something in the exe and release a new version, and it breaks > their custom report, its up to ME to fix it, and not for the > customer to be charged for it. > > So in the ace with our CMS vendor, what doe people think? Am > I right in thinking that it should not cost us anything > because "they" essentually broke it and never tested our > custom search etc. ? > OR should we pay?
Well, this question has both an economic and a moral dimension. If you don't pay, then your vendor is essentially doing unpaid work. Vendors who unconditionally accept doing an unbounded amount of unpaid work don't tend to stay in business in the long term. Be careful what you wish for, you just might get it :-) As an aside, this is essentially a 'prisoner's dilemma' situation. A theoretical selfish customer (and I'm talking abstractly here - not about you Jeremy!) would like to never pay for what they get - rather I'd like the vendor to charge all the other unselfish customers instead. But if all customers attempt to operate this way, the vendor goes under and all parties lose. A wiser customer who sees the bigger picture (i.e. we're all in the same boat economically in the long term) wants each customer to fairly pay for the value they receive. So does having the tweaked search working in concert with the added features of the upgraded CMS have value to you? Is the answer is yes, paying _something_ for it is arguably fair. Now, maybe it wasn't written well the first time with a view to later upgrades, so what's fair is negoticable but paying _nothing_ is rather untenable IMO. How do we resolve this bind at Accredo? For the core product itself, in a pretty industry standard fashion. We use an update subscription so we have an economic basis upon which to deal with platform upgrade events in the future. It's a fixed 15% per annum of initial cost so if we don't design/engineer well for maintenance, we wear the difference. For customisations we do in MaxBasic, we either charge a similar 15% subscription (generally only if it's a big $ value customisation) or make sure the customer is knows that in future there may be _small_ amounts of chargeable work involved in upgrading the customisation to work with later versions. We do a lot of backwards compatibility work in the business objects and MaxBasic interfaces to catch most issues but for structural change this is hard to make 'just work'. Ultimately, it's all about managing the customer's expectations. Once you explain the problem (unpaid work), most customers understand - they're in business too! If they are unreasonable about this at the initial stage - that's a large warning sign that your relationship could be rocky. Maybe they had a bad prior experience with a vendor. Maybe they consider avoiding paying a kind of sport. This is already a pretty long answer to a simple question, so I'll stop now. I've written plenty to disagree with here already :-) TTFN, Paul. _______________________________________________ NZ Borland Developers Group Offtopic mailing list Post: Offtopic@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/offtopic Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
