What can we do to bring Xojo back to PRO
The story behind it is simple: it wasn’t a genius but a good Salesman. And a nice product Vision which is showing that there was a fundamental goody for buying the product in history. And even today the Scene behind looks really good. Mobile, Web and desktop projects in one IDE and one Language are making the life easy.
Hence Xojo needs for Desktop, Web and mobile different UI Designs we need only to build the App once and the different UI Designs. Sad is that it is not possible to write a deep implemented Model-View separation which would help with the needed UI Logic which you always have but with this simple Model it would be able to write Applications with Xojo for this cases. Another way of building this up is to build a view abstraction means that there is inside of Xojo an abstraction which allows all of this job be done. Beside the needed Workarounds and the problems Xojo has with it’s technology there is a possibility for getting that Job done.
If they would take care that the Platform would not be in that desolate condition Xojo would still be a nice platform for Beginners,Citizen Developers and also valuable for semi-professional Developers like it was for long time before. The entire point is that the Company is still not able to fulfil that need. While that needs much more manpower and that needs a totally different release Model. it is not so that the Product itself is bad.
Man Power will help to reduce the problems
That shows up what is needed. Developers for the Xojo, inc and especially a CTO with the leader quality and the technical understanding and knowledge of programming. That can’t be somebody working now in the company while nobody now is able to fulfil that Job with the needed qualification. Sadly they don#t have the chance to change that fast. For that a few decisions from history are in charge. First of all: going away from a C++written IDE and second going away from an own Compiler to compile from LLVM intermediate Code.
And there is the Master question in this quiz: will that change? And there is my simple answer: no. Because the Company has no interest to change this environmental questions. And that has a simple foundation: they have a simple problem with the financial float. they need to get people as customers. New Customers which are starting to implement their Ideas as their next Software Project with Xojo.
Every company needs paying Customers also Xojo
if there is no new Customer and more and more Customers are not paying the Renewing there will be no chance for holding the company in the market. That is a simple calculation. The bigger question is: how we came to this point. And there we are at the Point Jeannot tried to describe with that what he said about the CEO of the Company. while he is not the technology Leader but a good marketing leader he decided simply not to be focussed on pro users but on citizens.
What is the Change? That is simply described. When focussing on pro users my Product needs to be reliable, sustainable, consistent and last but not least: long time api consistent. All of that was Xojo for a long time. In that times there was a focus on professional Software Developers. First on Mac, later also on windows. All of this is the result of blowing up the platforms and loosing in the same moment all important employees like for example the Compiler programmer. But with the years Xojo added more Platforms like IOS and Web. Also Android is in Beta already.
What could be a solution
That would need a massive Change in the Management strategy. First of all: the Release Cycle needs to be changed. Changes of a Release Cycle. The Release Cycle they use now is misleading the Development away from Bug Fixing. Fixing the Bugs would need to have one LTS Version. That could be - for example like it is with Microsoft Dotnet - for three years. Means every three years there is a new LTS Version. With a consistent API for at least three years.
Within the Development there can be always an unstable Version. That Version get`s changes and new Features. But new Features are not deprecating old ones to the next Version: they lead only to a deprecation Warning in the upcoming LTS Version and will end up in deprecation three years later. That makes it possible to have a consistent api on one Side and on the other one there would be the right way for long term development for professional users. The unstable one can be used even for production by citizen users if they want to. The LTS is the way for professional users. so Features and API’s having a life of at least 6 years. A Deprecation is warned long time in front, minimum three years before it will be deprecated in the on the deprecation warning following LTS Version.
Following to this Release Model there is always an LTS Version which is leading to a 6 years consistency. Deprecation Warning can only be done when the new replacing it already active. So new Features which are replacing old ones will have a long period until it is needed to use the new one.
Versioning for all tastes
Really new Features can be implemented every time but have to be in the Short time Supported Version. This one should have a Support Time of one year. So Xojo has only for Showstoppers to build up an Upgrade or even a Patch.
The next Part: coming back to an own true Compiler, a C++ tool chain. Works also cross platform but needs an Abstraction for UI building. Why? simple. While all of the OSses having own UI sets and this own UI sets are not working one like the other. So there has to be an abstraction which the Compiler can do. This abstraction makes it easy while you have your shared properties and abstract them to the native UI when compiling. So you can even have an Abstraction for Mobile and for Web. Look on JavaFX: it can do that. If they are able to do that, Xojo can also do that. And even more while working on it as an Abstraction for the native Desktop UI Toolkits.
Less stresses and Bugs
Since the Compiler would be available it can give us a modern Doe completion. that makes it simple to use any IDE Core, even the Open Source Core of Netbeans could be used for building Xojo Code. And yes, it is no problem to build that Code in a Xojo like IDE. And also no problem to build up a UI designer for all Platforms. That Xojo is able to do even now. Why should that be a problem? So we have a complete set of possibilities and a blazing fast code completion and we could use also the open Source Github Connectors (yes, they are also under MIT License so no problem).
When doing that we have to think about what we want: a native mobile framework for Android and IOS or a not native UI framework with nearly native look through CSS. Why I am asking that? because the first makes headaches. Even Kotlin Multi platform Mobile has not an abstracted UI Building. That is critical. CodenameOne has. And also that is: under MIT License. Yes, it is Java but also yes, it generates Xcode Projects which are native compiled. But this is only a decision we have to make. There is no mantra inside, we have this alternatives.
Cross Platform in best practices would be able with Xojo
So Desktop would be still Cross platform, mobile would be cross platform. And the nice part: when and if we have the View abstraction, we can build it for Kotlin Web. That would make the web application possible also. While the rest we have to do anyhow shows up the need to write a code transpiler. that would be the nice part using Kotlin. Beside the fact that we could even use the native IOS Xcode tool chain and Kotlin only for Android. What ever we do: we can not do anything wrong.
As I was already building a System like this I know: that is a big amount of work. many tasks have to be done. But it would be worth of it. While the Result would be a nice and new Xojo. Would I pay for it? I guess. While it would be a new perspective that Xojo can exist the next two decades.
Why I am thinking about? While it is always good when the makers getting some impulses for new solutions. They are not looking for alternatives and spending time to do framework changes without a target behind. That makes such incredible changes like msgbox is messagebox and then msgbox again but only in Desktop. In web it is still messagebox. I doubt that it was urgently needed to do. More important would be a strategy how Xojo should run in the next decades and not how it could be bug free. We can’t do that I would say.
Back to an own Compiler
One of the big goals of coming back to own compilers would be that we have a technology which we can form for the future. Nobody knows what will be with the LLVM tool chain within the next decades. But with an own compiler and not LLVM we would come to a fast and nice Story.
and while the UI would be still native AND the Compiler would be optimised we would not have all the problems we have now. And Bug fixing would be more easy. And yes: even the change to Apple Arm CPU would be nicer. While the Compiler is nice to port. With the LLVM Compiler we have always to hope that they will build up that target. If one day not anymore than there is not the next platform.
Would this cost a big amount more?
It is so that we would have to wait for new Features for a time. But for that price we would get also something: a Xojo with a better possibility of Bug Fixing and with a higher platform strength. Lie we all know: use Xojo for Linux and you can see what I mean. The performance decreases. Best Performance Xojo has on MacOS. For sure it is not the fault of Xojo, inc by the way. It is the fault of the LLVM tool chain. Therefore we would get a big amount of Speed on all platforms and a complete optimisation of the compiled code. Better.
Also we would get because of the UI abstraction a faster implementation of new UI systems like it was already needed by Apple MacOS. And also mobile Systems would be in a better environment. When deciding also IOS to compile with the tool chain of Kotlin MultiplatformMobile we would also get a complete abstraction of the Hardware layer of the OSses. So we could have less needs of declares which are anyhow a problem when programming for more than one platform. Everything would work from one project target. All needed side functionality would be builded up in one single tool chain. Except Desktop we would compile directly with the Kotlin compiler. That would make sense while we would have a top notch modern structure which is open source behind.
If we do all of this we can have a Xojo which is in a much better condition and which is able to fit also professional Developer needs. While the needed technology is behind with the Kotlin libraries and functions mobile and web are no problem anymore, even transpilations to Javascript are possible. And that would be the result of two years of work. Maybe three.
How can Xojo reach that?
They can reach that with stopping their policy of today, freezing the todays version as long term support version and starting to develop the new platform. That includes also languages changes and syntax changes, nothing should be forbidden, paradigms are not the most needed. To transpile that from old to new is the next thing they should / could do. And the result would be: for show stopping Bugs they do changes in the LTS Version but there NO NEW FEATURES. That reduces the amount of work for the LTS Version to a minimum. And within the time there can come an incubator Version which helps to optimise the technology behind.
When the new tech stack is ready they can release a prerelease. When it is one day stable and accepted then they can change this to the next LTS Version. And after that they would have never again the same problems and n top: the freedom for developing which feature they ever need. In the LTS they fix always Showstoppers and implementing no new functionality. But the Customer has a higher security that the Bug fixes for Showstoppers are coming (not like today) and that they would have immediately the security that they even know when they have to rewrite while a version goes out of Support.
The rapid Release model is exchanged to Rapid release with LTS
And the rapid Release model looses it’s dangerousness immediately while there is always a still maintained and security updated and running LTS. If this does not sound familiar: this concept is in the market for a long time. Made for Java. There is an LTS Version which you can use for Release. Version 17 is the current LTS release. Next coming LTS Release is 21. The Version 17 is supported until 2030, the Version 21 is supported until 2032 and so on. There is always when code breaking features where changed an LTS Version of the old version longer supported, in this case Java 8 until 2031 starting 2014. 17 years of security Support and Updates for new OSses is possibly enough for rewriting an old App.
Exactly that Situation takes care that if you develop an Application today means 2023 and let’s say you release 2024 you can choose to use Java 17 with Support until 2030 or Java 21 which releases in September this year and release 2024 with a JDK with Support until 2032. That is calculable and has low risks for your code. While you have that amount of time you can even say: okay, let’s look for the next upcoming LTS and refit your Project to it (that is what I am doing) or using all time the actual JDK and refitting your application all time for it (what is not much work for example I had between Release 11 and Release 17 nearly nothing to change for my old Software Packages but I had to update many Libs what was also not a real problem and I was even changing all Java 8 and older Packages migrating to Java 17 this year).
So following to this principles will help both: the Developer which wants to have all time the new features with the risk that something will need a rewrite after Version change and also the professional Developer which needs reliability. For the Version between the Changes (let’s say 2023R10) and 2027.1lts there would be a longer Support time needed. Means that the company would have to take care of the old Version for three years more (Showstoppers get fixed, security updates get done). Would be a Code reliability for the next 6 years from now on. And that would result in the possibility to migrate to the new Xojo blend of 2024.x.
Software Development for professionals and Citizen Developer
That would make projects possible and it would help to release the Software without the panic that the next change in versioning will change anything. While this panic nobody needs even the newbies not. Using Kotlin as Language behind for Web and Mobile would result for mobile in both Cases (Android and IOS) in native UI’s and for Web in a secure App generation for webApps as we know them (server driven Web Apps) and in pure javascript Webapps which we can transpile with the technology Stack behind from a written Web App. That would be a big technological step and Xojo would become a product even I would like to use.
