After working for almost a year with Xojo, I discovered its potential and can now say: Xojo is a great concept, a great tool. Unfortunately there are issues that are hampering success:
by the number of existing unfixed bugs (issues) and the number of new bugs popping up each week, it looks like the migration from API1 to API2 is still an ongoing activity
the documentation suffers from split personality, delivering API1 results for controls, their methods and properties as the first and supposedly best entry of the result list all while stating at the same time āthis stuff is deprecated, use API2!ā
Xojoās development team has 5 members plus 1 person doing bug/issues verification.
There is no dedicated technical writer.
While the existing team is doing a remarkable job, there is not enough workforce to catch up with all the work waiting to be completed within a reasonable time frame.
Xojo has an ambitious plan for bringing new things to the platform, which is great, too.
While I am not the type of seasoned developer who fully understands the underpinnings of developing such a huge and complex project like Xojo, my experience as a project manager lets me suspect that Xojo Incās headcount is not enough to deliver all the fixes in a reasonable timeframe, let alone things on the roadmap. Additional evidence: none of the items on the roadmap has a timeframe.
Trade-offs like leaving bugs unfixed while pushing out new stuff will likely hurt the customer base.
To remediate the current situation, the first thing that comes to my mind is increasing the number of developers and hiring a tech writer.
Though, Xojo Inc is not hiring.
This is my assessment and it may be totally inaccurate, based on wrong assumptions. However, Iād like to understand Xojoās choice of keeping team size as it is. My hope is that at the end of the developer retreat there will be some information from Xojo available that allows to understand the how and why, clearing the fog.
The Team size you need is given by the work amount you have. The team size you can hire is limited through the money you get within the time. So it is impossible for a company to hire 100 Developer for example which are costing 70000 each per year when your revenue is only 1.5 Million per year. While it is so that the Developers would cost 7 Millions.
So before hiring in great action it is possibly so that the Company has not enough resources for hiring. In that case all have to live with it like it is. while Xojo is a Niche product it is not comparable with Vaadin, Codenameone or IntelliJIdea for example. All of them are Multi Million Dollar projects.
So for Xojo it is like it is and they canāt do more. The people working their are working like I would expect that. More is not possible with the amount of people they have.
increasing a programming team size MAY be the right solution, but it might also NOT beā¦ It depends on the members of the team, how well they work and communicate etc. When I worked in IT at AETNA, we had 3 main IT departments, each one for a different line of business. My department was responsible for all Provider (Doctors, Hospitals and CLinics), and consisted primarily of 3 people, a Program Manager, and Two developers (of which I was one)ā¦ most other departments had an identical structure
Look at Vaadin for example, they do the same. But they have still 100 employees instead of ten. I believe it is comparable looking on the size of the framework and the targets platforms and the two Design-Systems used with Vaadin: Flow and Hilla.
I counted people on Xojoās website/team page who where identified as developers.
Just wanted to open that Team page in order to put the link here for reference, but it seems to have disappeared.
You can debate but the fact remains, the bug pile is growing and many users feel that is a waste of time to write the āissuesā so the huge pile of bugs it is just a fraction.
But no, you are not alone in that assessment, many users have being said just that to xojo for YEARS. Xojo call those users āA trollā
The bussiness model of Xojo has being the Hope for a log time, maybe next release they will deliverā¦
But the reallity is that they look like to continue for the same path, More platforms that they can chew, half backed features and an ever growing pile of bugs.
It is a small company. To have a product good to sell they need functionality others donāt have. For example Cross platform from all platforms (nearly). So they builded Desktop fĆ¼r Windows, Linux and MacOS.
IOS is the mobile Platform of Apple so they builded it. And here begins the line: it is half baken, even to recolor a Button-background you will need a delegate.
Android (coming soon since at least 2018) is a platform hard to chew while it is a Java based platform. You will have only two choices. Compiling a binary which brings itās completely own visualization or compiling the Java / Kolin Code. First decision was wrong so the rewrote the entire package to Kolin. Makes a good figure when and if they get it to run correctly. But again: the most functionality will not be there. They will have to rebuild all the wrappings they have done for IOS also for Kolin. Good luck for it.
Web 1.0 was a one way ticket. It was outdated when it came but it was nice: writing Web Apps like Desktop was usable for some cases, no question. Then came Web 2.0. Everything changed and the core functionality was and is still reduced. So Web 1 projects could not be loaded into Web 2.0 without loosing functionality and without writing 3/4 new. No styles, many events are not there and so on.
But all of this are functional leaks. There is a Mount Everest 2.0 to add looking on the bugs which are growing up fast and daily.
the āambitious planā is just the tired āRoadmapā that doesnāt mean much in my opinon
but does show me that their direction is as flawed as everyone has said.
1 - ARM64 for Linux : OK this one makes sense
2 - Android : TOTAL WASTE OF RESOURCES... that train left years ago
3 - Modern UI for Windows 11 - maybe good, if it fixes bugs in the current Win controls, otherwise NO
4 - New controls and modern updates for macOS : Same as #3
5 - IDE Navigation : fix the BUGS first
6 - Grid Control : Fix the BUGS before adding a new source for problems
7 - Easy Database Connectivity : Personally how much easier can it get?
8 - Interops - iOS : my opinion, wouldn't be necessary if they had done iOS right in the first place
9 - Plugins made in Xojo : just another "Ooooh... SHINY!" but not much to improve the product
From some reasons it is but also you place them in public. It is sometimes not good to do that, I know that and decided by self that the Team is not exposed to public. And I believe that they have the right to be unknown by the public. Xojo decided - it looks at least so - to remove the team from the Website what I can understand from some reasons reading the texts for example on some Xojo hater blogs. I would not like to read that about me / to read my name under this conditions. So I have no problem with this decision.
It is their decision and weāll have to wait what will come up. I guess one of the reasons is also the rund and rund discussion about the site of the team. I could imagine that they did not wanted that discussion anymore. I would possibly decide also so.
See, for Software Development there is at Xojo no Degree needed, they are hobbyists which got to program by self and learned by doing. That are real practical programmers. No Scientists. Is that needed? I donāt know. At least in my Company we use only Scientists. But we are not Xojo, we are writing medical Software what is regulated and complex to publish at the end. So possibly we could work with non study āengineersā but we could not call them engineers. Since my Engineering Company is named human engineers life cycle Development I canāt place somebody without a degree by Law. But I have no Idea how that works in US. Possibly there you can be an engineer without being an engineer. Here in Europe you need a degree as an engineer to call yourself an engineer.
