Update of old apps
Mark Talluto
userev at canelasoftware.com
Thu Jul 17 13:52:39 EDT 2014
On Jul 16, 2014, at 10:36 AM, jbv at souslelogo.com wrote:
> 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.
I see. I misunderstood you. You are more interested in the LiveCode lifecycle as it relates to new/features and operating system compatibility as well as other unforeseen issues as time moves forward. The answer will vary depending on the LiveCode functions you are using. The more basic features like, short name, internet date, copy, paste, put, get, etc will have a longer the lifespan. The more exotic features like acceleratedRendering, sockets, media management, etc. are more likely to change and get better and be more compatible as time moves forward.
It would be very difficult to assess your situation without knowing intimate details about your project. I can give you an idea of how we do it as it relates to our products and services. We are moving more to a subscription/membership/month type model. This has many benefits to the developer and customer if priced correctly. The customer does not need to work about compatibility as your responsibility is to keep the software current and moving forward or you will risk losing your customer base. In turn, you are receiving a regular source of income that you can count on for development. This model is starting to work for a lot more products than it did in the past. Software as a Service is the future for many of the big companies. Microsoft just announced that cloud technologies and SaaS is their model moving forward. Google has done this forever.
Making the leap to this model sometimes is difficult to do for exiting products. It is much easier to do with new products. But, it can be done. Pivoting to this model can be achieved gradually by offering both models to your customers initially. Once you gain enough traction on the new model, you can forgo the older model. There are a number of considerations as you do this. Inevitably, you will upset a portion of your customer base that is not accustomed to paying monthly for software. This is really a business decision that you might have to make.
Aside from sales models to help you work around LiveCode life cycles, you can probably live with a given version for a couple of years provide the OS vendors do not throw a wench into your plans. The OS guys are changing things regularly to keep sales going. One obvious example that will affect you is Cocoa. At some point, Apple may not allow Carbon APIs in your shipping app. There are signs of this already if you use their store. But, this might affect those of us that not using their store. LiveCode 6.7 will be Cocoa compliant. But, I suspect, we will see more Cocoa support through future iterations of LiveCode. Thus, you want to keep on top of that. There is also the decision on how far to support your customers on older OSs. Supporting older version of a given OS might cause you to fork your code base for legacy and modern computers.
I can go on for a long time on this subject, but I am sure this email is getting a bit long. I will stop here and respond to you again if you want.
Best regards,
Mark Talluto
CanelaSoftware.com
LiveCloud.io
More information about the use-livecode
mailing list