Mark, Thanks for your reply. From the economic side of the client/coder relationship, that's more or less what I had in mind. Nevertheless, I would once again like to see the strict technical side of the problem. And perhaps another way to put it is to ask : what is the life expectancy of an app developped today with LC 6.6, especially with all the big changes announced for the near future ? Of course, future versions of LC will provide backwards compatibility for both the IDE and the language on one side, and for various OSes and platforms on which they run on the other side; but when will all this stop being great features to become a burden, especially regarding maintenance of the app ? And then, the question of "how's gonna pay for the upgrade/rewriting" adds another layer to the problem.
One situation might be when a new version of Mac or Win OS requires recompiling the app with the latest LC version and doesn't lead to a 100% bug-free standalone (which BTW can be caused either by non-compatibility with original coding options, or by bugs in the latest LC engine)... I'm afraid the final answer might be a case-by-case decision; but I still wonder if any of you has already faced the problem and how it was solved. Thanks, jbv > > > I think this is very on topic. The answer may differ depending from > contracting projects to products/services one sells broadly to more than > one end user. > > If this is a contract situation, I would contact the companies you work > with and actively offer upgrades to their software. I would know > everything possible about their industry and provide strong points that > would interest them in hiring you to update their software package. You > might even look into a yearly support option for clients that use your > software in mission critical environments. Casual users of your software > will not desire this though. > > If a client calls and requests something new, I would call that a billable > item. If they find a bug in your software you have the option to generate > good will and fix it for free or offer them a reasonable rate to fix the > issue if you think it warrants charging. > > I dont there there are hard rules here. You have to gauge each situation > individually. Considering the long term value of your decision is helpful > in determining whether to charge or not. I hope this helps a bit with > your decision. > > > Best regards, > > Mark Talluto > CanelaSoftware.com > LiveCloud.io > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
