For reasons that I can’t explain, members of the XOJO forum regularly ask why I and others are questioning the Xojo release model.
After all, we would luckily live in free countries and no one is forced to upgrade.
Another argument of those people: if you use a new version of Xojo, you can continue to use the old version indefinitely at the same time.
Stop crying, everything is perfect!
Is this true? Let’s see.
Okay, apart from the definition “infinite” that is not to be contradicted, new OS, new browsers, and new chips will eventually make the old version obsolete. But even then, that is indeed right, you can still help yourself for a while by virtualising the entire OS.
Whether that’s useful is another question: the compiled app is unlikely to be of much use to most users, who certainly will be using by then a more modern technology stack and your old stack won’t compile for that new stack.
What is the real issue with having no patches?
From my point of view, the problem and root causes are slightly different. If I find a bug in release “10” and this bug is not fixed in release 10, but in release 12, 13 or 14 only, then I’m forced to update “everything” exactly for this single bug fix (it is NOT a patch, but an update or even an upgrade).
I don’t know what you can’t understand about it. This has 2 important consequences:
The new release brings new functions, often new bugs, a new look, new concepts (API2 e.g.). In short, to get your critical bug solved, you have to accept a completely new release with all consequences.
You have to update and spend money every year, so the software becomes de facto a subscription model.
I’m still not convinced, do you have a real-life scenario?
Let’s assume Xojo Web 1 is a convertible.
The convertible was released, and you bought it.
At some point, you noticed that the top didn’t always close properly. You opened a ticket. The answer followed on foot: “we cannot reproduce the problem”. Okay, it probably only happened in cold and humid climates, after much back and forth the problem was acknowledged in principle. The issue would be fixed in a future update — good news, not ideal as you had to wait, but at least it got solved!.
But the update took days, weeks, months, and ultimately years. By the way, you paid your annual license while waiting (smart business model).
Full of joy you brought your convertible for maintenance on the release day only to notice when you picked it up that your convertible changed to a station wagon and got called Xojo Web 2!
The manufacturer said you shouldn’t get too upset: firstly, the problem with the top would finally be solved, the car would still get you from A to B, it would even consume less and now also has LED lights and a trailer hitch. And yes, there would be a way to somehow integrate the convertible top (“we are on it!”), they would have to look into that.
During your first test drive, you noticed that the navigation system no longer understood your local language, the speedometer showed miles instead of kilometres and the first exit with a trailer (the new feature was quite cool) got stopped by the police because the brake lights didn’t work. So you got a ticket before you could open a ticket with Xojo.
Did I forget to mention that the window regulators stopped working?
That’s the dilemma with the Xojo release model: you regularly get with every update a completely new product, rather than bug fixes through patches. To summarise:
NEVER patches, but ALWAYS new releases.
There are good reasons why an LTS concept has become more and more popular and a de-facto industry standard.
What would be different with an LTS model?
Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period than the standard edition.
Listen Xojo: it is called SUPPORT but it means MAINTENANCE! Not your definition of “that you can be called and you will look what you can do”. Big difference!
In an LTS concept, you have an LTS version and a standard version. The former is only patched, and the latter gets new features. The latter can even change dramatically and be a complete re-design. If necessary (technically possible and stable), new functionality can also be transferred from the standard to the LTS version. But that rarely happens, usually, there is a new LTS version a few months before the expiry date of one LTS version so that you can test and plan your migration to the new LTS upfront. This “overlap” of LTS n and LTS n-1 gives every developer AND customer enough time to plan the budget and resources for a smooth transition.
In my opinion, Xojo has no will to implement such a concept and that’s IMHO a big mess for every developer who takes his customers and his job seriously. No clear roadmap, and no patches mean that you can’t promise your customers anything.
From my experience it is as good advice not to promise your customers anything, planning is impossible with the Xojo technology. That’s good enough for quick prototypes but “suboptimal” for any sustainable product.
Security aspects of non-LTS release models
Last but not least: even if it is true that a particular Xojo version could be used “infinitely”, the fact that there are NEVER patches also means that this version quickly becomes a technological risk.
Let’s take a bug like the one found in Log4j. At the latest when a library that Xojo uses in a specific release would get compromised, there is no other choice but to update IMMEDIATELY for business-ethical and security reasons.
The fact that so many Xojo developers don’t mind these hard facts is a completely different problem but likely one reason why pro users are no longer the target audience for Xojo.
The irony behind the curtain
It’s ironic that Xojo doesn’t think much of an LTS model itself, but forces you (cf. Web1) to implement exactly that for your customers as a developer. After all, no customer wants to get a new car but wants a fault in the current car to be corrected.