I think it’s more a case of Pros find more bugs because they’re pushing what can be done with Xojo, while citizen devs and Xojo’s target audience don’t use it that way. So those features or bugs never have the same “impact” area or get as many votes.
Pro users should be a priority as they help to elevate the quality and capability of Xojo, which improves it for Xojo’s target audience. It also makes Xojo more appealing to more experienced developers who use other tools.
I stopped renewing because I realized that my money was not being spent on things that benefited me. The only reason I recently renewed was because I HAD to build a UB console application for App Wrapper, and my Lite license wouldn’t let me.
But they don’t ask people who stopped renewing why they stopped, so they’ll never know.
They have finally added pre-emptive threading, which is a good thing, once it is stable, but there are so many other things that I’d like to see from Xojo, but I’ve come to expect that I won’t.
Right now Xojo is adding a basic App Wrapper, which is going to make it even less profitable and more difficult to support, and I bet their solution only works for some apps, unlike App Wrapper.
There was a time where nothing new was added to the product, for months. I feel they are “more prone” to add things these days. Perhaps you may see what you no longer expect
You really are a bunch of frustrated guys.
We all understood perfectly that you don’t like Xojo. I don’t think that’s a problem but insisting on it is getting really stale. Don’t you have another job or something?
Many moons ago in a chat with Aaron Ballman he said that the bugs the Pro’s submit are generally complex and hard to fix and therefore those weren’t the priority. He said it way nicer than that but that was the general gist.
Now that I’m working on a very large product I get it. In nearly 5 years we’ve taken care of most of the easy bugs. The one’s that are messy and complex tend to get shunted to ‘the future’ or we wait until we’re adding new functionality in that area to fix it.
That if often the problem. Therefore we try here to fix the most complex ones with priority. Otherwise they will not be fixed at all with a good chance. Looking on Xojo there are many messie bugs and many many Bugs at all. The low hangin fruits are done early and fast. The other ones not
That’s exactly our experience. We are able to come up with workaround to 99% of the problems. Of course that leads to ugly code when they finally do get to fix the bug, but that’s a side issue.
This leaves us with the most insidious bugs. They’re really complicated for Xojo to fix, they’re really hard for us to fix. And they’re usually quite esoteric because they’re an edge case. (meaning, no one else even understands them let alone votes them up)
If I was the only one that had these, that would be one thing. But that seems to be the land mine for every professional developer. Eventually, you step on it.
When I first read the announcement, I chuckled and thought, “Welcome to the 1990s” (well, a tad later for Mac. ) Having said that, I have been pleased with this. I have already converted one project that used Workers–which itself was a conversion from cooperative threads. Both gave me better performance than the last.
As to the TOF thread, it is frustrating to see Xojo staff, MVPs and fans circle the wagons. “All software have bugs” is a straw man, because no one is saying otherwise*. Nitpicking the methodology of the original poster, or otherwise insinuating that the complainers are the problem, is likewise non-constructive. Just say “Thanks for the feedback, we always try to do better”, and mean it.
I write this as an overall satisfied customer, albeit with some frustrations, who has been with RB/Xojo since Day One.
*among possible exceptions was the flight control software for the space shuttle. I once read a fascinating article about that. I think I remember Geoff mentioning that in the TOF thread, but brushing off such a goal as too expensive. Again, no one is asking for that!
Plus all the people, including me, banned for pressing on fixing bugs.
Xojo just isn’t a reliable “partner”. Xojo worked for me when I created shareware, but not at all creating business database driven apps. It was like driving around an apartment complex where you hit a speedbump every 300 feet.
Xojo is REALLY inexpensive until you add in the time and effort dealing with Xojo bugs. That’s when it all falls down.
Indeed the lack of any observable progress in reducing the # of bugs released into the wild and the lack of apparent speed in getting bugs fixed are the point
Fixing bugs is reactive - a bug got out and needs to be fixed
Preventing bugs is proactive - having processes in place to see they dont get created in the first place AND having processes in place to see the dont reoccur
The first is public - we can see is in Issues
The second isnt - but its apparent they dont have any as the # of bug reports in Issues is pretty constant (I tracked it over several years and its basically flat lined) And at a rate that per release there are more bugs reported than are fixed
I will stipulate that, aside from some high school BASIC in the 1970s, I am self-taught. So yes, it was terrific in my hobbyist/shareware days. I guess it’s no coincidence that, as I’ve advanced, I’ve run into the stuff. I also am very thankful for MBS and Einhugur, for making it possible to do what I do.
For a while, they had a good track record on fixing tickets that I submitted, but I guess now that they were low-hanging fruit. More recent tickets have languished. This includes stuff like event handlers that simply do not fire on Linux. Am I being too picky?
That Xojo prioritizes feature request & bugs about the same is bad for creating a reliable platform
Rapid release HAS turned REAL/Xojo into perpetual beta (@MarkusWinter was right so many years ago)
Its why anyone making software professionally with it has many versions they use
Bug X is in version Y but I can work around it
Bug A in in version B and I cant but I need it to make product D but cant use it for product C
and so on
Blindly updating to the very latest version simply ISNT viable except for much simpler projects
Personally I have 5 versions in my dock and I use them all for various projects
I’ve had many more than that at times
Rapid Release needs to be revised to something else
Maybe tick tock where they do bug fixes only, features, bug fixes, features
At least then it should result in more stable release with its of bug fixes & new features that CAN be skipped
as long as they can add new users at a rate thats at least consistent with those now renewing or leaving then revenue remains roughly the same
I have a hard time believing their revenue has remained stable over the past several years with the # of reports of we’re ditching it I’ve seen over the past 5 years
More than I recall in the decade before
For me, this became particularly frustrating with a consulting job, where I ran into issues that did not affect my own projects.
Heck, over the years I’ve found and reported MBS and Einhugur bugs. But Christian and Björn have been all over them. This makes hash of the “we’re a small company” excuse.
) Having said that, I have been pleased with this. I have already converted one project that used Workers–which itself was a conversion from cooperative threads. Both gave me better performance than the last.