Jump to content
Sign in to follow this  
mgh

Support

Recommended Posts

There are often complaints posted about the support offered by add-on developers. I sometimes wonder just how realistic the expectations are?Add-ons typically cost around US$50. For that For this unlimited personalised support on a one-to-one basis seems to be expected That is,an e-mail is sent, it's dealt with by an individual and a personal reply is returned. In the USA, current average hourly earnings are US$22.21 for people engaged in professional and business services.http://www.bls.gov/news.release/empsit.t16.htmAllowing a factor of 2 to cover costs of employment (accommodation, computers, holidays, social security, etc) the equates to a cost of US$44/hr. So, if it takes half an hour to respond to an e-mail that's cost the developer US$22. That's almost half the cost of the add-on and almost certainly all the profit. It represents a very significant cost to the developer.I have software on my PC from leading suppliers costing many times US$50. Those suppliiers don't offer that level of service unless I take out, and pay for, a maintenance/support contract. The most I get is access to their standard on-line help.Is it really reasonable to expect such a higher level of support from add-on developers? Reading hese forums shows that questions are often asked that are answered in the documentation provided - in which case the obvious response is RTFM. Other problems relate to the inability to run the add-on on a particular hardware/software combination. If that was a general problem with a particular add-on then it would surely have been raised here by many other purchasers. In an ideal world that should result in a full refund of the price. The world is not ideal and. sadly, many would use that to avoid paying at all.It seem that the realistic solution is to buy add-ons only from sources that offer no-questions-asked refunds. They will cost a little more but that may be worth it for peace of mind.

Share this post


Link to post

I suppose expectations of support are in part, a function of the quality of the product released. When a developer releases a product with numerous bugs, he should expect that buyers will want "support". That is, buyers want a product that functions as claimed by the seller's representations. Of course, there is the prospect of the customer with expectations that exceed what the seller offered, and for these a refund is probably the best solution. Too, there is the problem for both seller and customer that the basic Windows platform is so fragile that it is difficult to isolate a product problem from system problem. Don't know any fix for that one.scott s..

Share this post


Link to post
I suppose expectations of support are in part, a function of the quality of the product released. When a developer releases a product with numerous bugs, he should expect that buyers will want "support".
A developer who releases a buggy product is probably the least likely to provide support.
That is, buyers want a product that functions as claimed by the seller's representations. Of course, there is the prospect of the customer with expectations that exceed what the seller offered, and for these a refund is probably the best solution.
The developers representations are invariably very limited - check theto see what I meane. Many complaints I've read are based on buyers reading too much into thedevelopers' description and then having their expectations dashed.
Too, there is the problem for both seller and customer that the basic Windows platform is so fragile that it is difficult to isolate a product problem from system problem. Don't know any fix for that one.
Some add-ons as well as Windows can be fragile. Developers often go beyond the SDK to improve their products and then get caught out. One obvious example was some FS9 scenery that failed to work in FSX because its developers had gone beyond the FS9 SDK. Scenery from other developers who had stayed within the bounds of the FS9 SDK still worked. Also some aircaft add-ons rely on FS to initialise their aircraft by requiring the default aircraft to be loaded first. That's fine but seems a bit fragile because it's not really under the developers' control. They can't guarantee that a SP won't subtly change this. As an illustration, a few years ago clever programmers found undocumented APIs in Windows and exploited them. Unfortunately they were undocumented for a reason - they weren't finalised! When they were finalised and documented their effects had changed. This caused some working applications to crash when the operating system was updated.I still suggest that buying from sources that offer no-questions-asked refunds is still the best (only practicable?) solution.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...