another marketing ploy… “Hey we are gonna start doing something special with each release!”
NO… you unit test, you regression test, and you resolve any and ALL failures … that is how products are built. Not throw them out to the public, and THEN fix bugs…
I think it was a clarification of an even earlier statement that they were going to dedicate 2 weeks in each cycle to attacking bugs that had low upvote counts or something like that
Still seems to me to be more a marketing statement than anything
radical !
There are bugs aplenty to fix before throwing it at paying customers. Don‘t know why they are making such a fuzz about fixing only a few of them.
Like I said it is pure marketing… an attempt to make ti seem like they are going above and beyond, when in fact they are barely doing what any good software developer should do
Open bug count in issues is simple proof
They are trending UP - not down - despite the summer bug bash and this new commitment to a two week bug bash each release
When I first started looking at this # it was at 2018 open
Today it sits at 2101
EDIT - never mind the 4189 archived bugs
Endless work-around-the-bug sessions. A low coder’s most horrific nightmare 
There’s something truly sad about people going around soliciting up-votes for their bug reports, as if that should be any sort of input into fixing any reproducible bug. I would lay awake at nights over ANY bug, however trivial, however limited in scope of how many users it supposedly doesn’t impact, if it were just sitting there unaddressed for any length of time. I simply can’t get my mind around the bug backlog.
I can say that when I worked there it bothered me in this way as well
But the sad reality is that there are so many in any developers specific areas that you have to triage in some way
Up votes was one. Whether the reporter was Pro+ was another. If it was a crasher, unhandled exception. Was it reproducible ?
All those factored into what got fixed
And then what features were going to be added
There are/were only so many hours in so many days for any cycle
Most of the dev staff worked well beyond a normal 8 hour day in every cycle
The loss of control apparently happened some 3-5 years ago. Now, no resources and no process to get it straight, to recover. It seems that currently they are producing more bugs than they are fixing, when they fix bugs.
What remains is marketing sugarcoating (‘turn a liability into an asset’) like vote it up, bug bash and so on. What surprises me is how many people happily buy into that spin and add money on top.
I have always sensed that it was a lack of resources sufficient to the task. I don’t get an impression of incompetence or under-qualification from the devs at all. Perhaps just sort of collapsing around the problem / ceasing to care but not inability. It is rather a leadership / management issue, and probably too entrenched now to easily dig out of the hole if they wanted to.
This is why I’ve said all along that it would take someone with $ to burn to invest in the product to bring it up to snuff (probably double the dev team as well as get their process under control) plus to make its roadmap sustainable for the product to hold over time given current market trends. And/or … open source part of it, or the whole thing and let the community rally around it.
But if the owner can turn a profit in the short run or at least until he retires … he might elect to coast as-is 
And that’s his choice to make. It’s old-school capitalist, owners or shareholders first, users and community / ecosystem be damned approach, but it’s certainly an approach. I can’t say I’ve seen anything different at M$FT or even Fox Software, etc. over the course of my career; they’ve all lost sight of the big picture and reduced everything to a bean counter-driven mentality such that the only reliable winners in this game are the owners / managers. I also don’t know that open source has exactly covered itself in glory for different reasons. So … I don’t judge it particularly, I just try to protect myself and my sanity as much as I can.
The staffing levels have been pretty static for many many years even prior to my joining
They’ve fluctuated a little - not not a lot - despite adding iOS and Web targets and, eventually, Android
From my perspective it is/was an issue
There are just too many things for the small team to do
Expanding it would be a good start to making a serious dent in some of the bug reports
Others though are much more fundamental and require serious overhauls - autcompalete for one. Project IO for another.
I’d agree that coasting is a good way to describe it
The argument over the years has been that some targets were ‘basically free’ which, to anyone looking at it realistically was pure BS. Every new target takes some resources. So if the development team stays the same size but new targets are added that means fewer resources to spread out amongst all of the targets. Fewer resources means less time for research, less time to code, less time for QA, and so on.
I think they could double the development and QA teams and still not be adequately staffed.
I’ll just bite my tongue here
I mean these are not insurmountable issues assuming there is enough budget to hire people. So I can only come up with 1 of 2 conclusions: 1). There is no money to hire additional developers and QA; or 2) The owner does not want to hire additional developers for reasons other than financial reasons.
I suppose there are other reasons that I guess are even worse: 3) The owner feels that there is no problem; 4). The owner does not see the problem. 5) The owner doesn’t care.
I’ll repeat myself
That may well be.
What’s certain is, there’s lots of wishful thinking going on. If I’ve learned anything in 41 years in this business it’s that “things take longer than they take”. Everything has knock-on effects and interrelationships, so nothing is truly free.
In fairness even Microsoft with its massive resources does some triage and has a tendency to close out TRULY obscure bug reports if no one seems to care enough to discuss them, will thrash around on parts of their API / technology direction over the years, etc. But what you can take to the bank is you will VERY seldom see regression bugs and if you do they are fixed pronto. And any subset of functionality or API that is sunsetted enjoys generous LTS (FoxPro being a notable partial exception, due to NIH syndrome and having less of a native / typical MSFT user base they felt beholden to).
I believe it does come down to money, in that the CEO doesn’t believe hiring more staff and fixing problems or overcoming limitations will increase the profit/revenue from Xojo.
I am 100% sure that when they started 2.0 all the things, they were aware it was going to cost them customers and revenue, my guess is they’d come up with a number and felt that was acceptable. I am certain that they felt either 2.0 all the things would make Xojo more suitable to a specific market they wanted to target, or 2.0 alone would encourage new developers to choose Xojo.
We know this plan backfired, as evident by Xojo’s price increases. 50% increase on the cheapest plan, suggests two possibilities. 1. Their lite plan is expected to be the most popular. 2. The lite plan is their least popular and they don’t want to risk losing more customers from higher tiers.
I do get the feeling that this became personal for the CEO when it was realized just how many customers were not happy. Which is why they aggressively persisted, ignoring all criticisms from the Testers, only to be bombarded with the very same criticism upon public release.
My guess is that Xojo will persist for a fair few more years, but the market growth they expected won’t materialize. At the end of the day, it doesn’t really matter how many new customers you snare, if there’s not enough reasons for them to stay.
It occurs to me also that they would hope for revenue from renting managed servers for Xojo web apps. Licensing isn’t their only income stream; managed servers is a diversification.
Question from a noob here: what was the actual problem with web 1? Were problems with that more real than those alleged with API 1? Does web 2 actually solve some sort of architectural misfire or retire some kind of technical debt? ISTR reading somewhere that web 1 was a misguided hubristic attempt to go entirely their own way and web 2 is bringing in some standard outside frameworks / libs like – what was it – jquery and one of the popular CSS frameworks?
What strikes me as still limiting is a web target being its own black box web server. I was kind of surprised by that; I was looking more for something that would deploy like any other IIS or Apache site; I wanted Xojo to provide the tooling to make such sites much more easily. But then there wouldn’t be that proprietary tie-in to give them the opportunity to sell specialty web hosts, either.
Seems like it would be hard to sell corporations on deployment via a custom proprietary web server with unknown scaling abilities and resource needs, and any issues that need fixing you’re at the mercy of this little vendor with a somewhat checkered past about minor things like bugs.
Lack of updates and bug fixes 
HTTP 1.0 protocol, now they have… HTTP 1.1
suposedly, but introduced their own architectural misfires and others just passed down
That is BS, the one who designed web2 make a really lousy job. Xojo brag that they integrate popular frameworks, like bootstrap for css BUT they dont even use it as intended. The Web2 framework still use individual styles (but they remove the webstyles feature)… plain $"#¡&.
To have just the look, they could have upgraded the css of the web1.
The same problem as Web2 - they send client events to the server. There maybe other problems too but I wouldn’t know because the former is just so off-putting …