Its no secret that I hate the Rapid Release Model. I know that many like new features as quickly as possible, but I need my programming environment to be stable and as bug free as possible. At the introduction of the Rapid Release Model I predicted that Xojo would become a perpetual beta quality product, and given that the forum sometimes seems to have more complaints than actual questions about programming I would guess my prediction wasnt far off.
Now other environments had to deal with rapid evolution - Linux comes immediately to mind - and the solution there was the introduction of Long Term Support (LTS) versions that add bug fixes but no new features. Is there any reason Xojo could not do the same? Let others play with half-implemented and buggy features but let me get on with my work.
if the process were approached differently, a special “LTS” version wouldn’t be required.
I think the problem is that the engineers would rather work on “fun stuff” (read “new”), rather than spend time “fixing” “old stuff”
And if this were not a commercial product that we all have a vested interest in, I wouldn’t have a problem with that… Heck I’m guilty of that in some of my own project as well…
I’d call that a little unfair. 198 bug fixes. 34 changes. 28 new items in the R1 release and the R1.1 was ONLY bug fixes.
I think it may be fair to say that bugs stay on the books for far too long, new features aren’t fully vetted before release, changes don’t always get thought through fully and impact more than they expect. But to say that they’d rather work on new and fun stuff is a mischaracterization. The engineers use the product too and they need it to work too.
The sad fact is that the way they use the product for the IDE is vastly different that what a majority of us do for our projects. Otherwise, we’d have a better reporting tool, database editor, database tools, better RTF and PDF support, to name a few things that many of us deal with every day.
Part of the problem is that feedback is heavily biased towards new features because by their nature feature requests are cumulative but bugs are insular (a control might have ten bugs but different people are affected by different bugs).
As has been said many times before, that list does not dictate how the engineers spend their time. It does guide Geoff into setting the very high level priorities, but does not affect day-to-day operation.
Bob I think put it best. I was literally just thinking this morning that I’ve never worked on a real project that didn’t need a database. His comment made me realize that wasn’t true: the IDE. Though technically the IDE uses a database for the licensing and an in-memory for the inspector, that’s not really the same thing.
So Bob is right, many of these features have absolutely zero impact on the engineers. That makes them difficult to both design and maintain. For example, if you asked me to design a reporting tool, I’d probably give you what Xojo has already because I have never needed one and I probably never will. I have no experience with reporting tools, so I don’t know what’s good, what mine could do better, what weaknesses mine has, etc. For the record, I did not do Xojo’s reporting features, I’m just using the feature as an example.
I wish I had a solution to the problem, but I’m pretty confident an LTS release isn’t it.
I mean, I could just write the phrase bug fixes over and over again, but that wouldnt help anything.
I talked about a specific scenario to explain how some of these situations happen. You havent mentioned any specific bug fixes, so what would you like me to say?
As Bob pointed out, LOTS of bug fixes happen every release. Far more than get introduced. So why would making Xojo maintain two active releases at a time help anything at all? All that says to me is theyd spend more time on doing what they already do. It just sounds like a great way to waste productivity.
Thom, if you would be right then there should be no users being stuck on old releases and unable to upgrade. But there are. Just ask Michel.
What use are many more bug fixes if a new bug makes a release unusable? There were three releases in a row in 2016/17 which were unusable for different reasons (StyledText, Database problems, cant recall the third). Because of bugs being introduced but not corrected till the next release which had its own major bug making it unusable. [and yes, Im well aware that unusable depends heavily on what you are doing].
Now if you are stuck on an older version, having paid good money, and you dont even benefit from other bug fixes because there is no LTS, just unusable Rapid Release versions then something is seriously wrong in my opinion.
And it all comes back to that stupid Rapid Release model. Apple tried it, and ditched it. Because THEIR software quality and stability suffered. So now they moved all major features into 2019 and this years releases will be mostly maintenance releases.
[quote=390185:@Markus Winter]Thom, if you would be right then there should be no users being stuck on old releases and unable to upgrade. But there are. Just ask Michel.
What use are many more bug fixes if a new bug makes a release unusable? There were three releases in a row in 2016/17 which were unusable for different reasons (StyledText, Database problems, cant recall the third). Because of bugs being introduced but not corrected till the next release which had its own major bug making it unusable. [and yes, Im well aware that unusable depends heavily on what you are doing].
Now if you are stuck on an older version, having paid good money, and you dont even benefit from other bug fixes because there is no LTS, just unusable Rapid Release versions then something is seriously wrong in my opinion.
And it all comes back to that stupid Rapid Release model. Apple tried it, and ditched it. Because THEIR software quality and stability suffered. So now they moved all major features into 2019 and this years releases will be mostly maintenance releases.[/quote]
Im not saying there arent problems. Im saying asking Xojo to actively maintain two versions at a time is an unreasonable request when resources are already spread thin. It wouldnt necessarily solve anything, since its very easy for a fix of one bug to cause another, and would certainly eat up lots of additional engineer time.
Like I said, Im not sure what the solution is. If I were, Id have brought it up long ago. But Im pretty confident an LTS branch isnt the solution. That branch would likely only see absolutely critical fixes, and be stagnant for most of the year because no engineer would want to submit a fix to it. But the biggest time sink would be the meetings required to determine which fixes belong on the LTS vs active branch.
Which is precisely why big fix only releases will not work. That doesnt sell licenses to new customers.
Web Edition is a real-world example of this. Before its launch, the company was operating pretty much at-cost. This was during the recession. We couldnt afford hardware upgrades, for example, let alone entire engineers or raises. So Geoff threw me on Web Edition. It took about a year, but it paid off. Once WE launched, we were able to bring on Greg, upgrade some hardware, etc.
The company cannot survive by just fixing bugs. Im not aware of current financials, but if I had to bet, bringing on an additional engineer isnt an option right now. They need a sustainable increase in sales to make that happen.
Assuming Im correct, whats the solution? You cant fix the bugs without an engineer, cant get the engineer without the sales, cant make the sales without the features, and the features cause bugs. How do you break that cycle? This also assumes that an additional engineer would solve the problem, which is debateable itself.
Im sorry for being so negative, but this isnt the first time Ive thought about it. During my time with Xojo, we were always looking for ways to improve quality control. This stuff bothers the engineers as much as it bothers you, Im certain of that. And if Im wrong about an LTS model being the solution, that would be fantastic. Id be happy to be wrong. But a lot of thought has been put into this problem, and if an extra engineer or an LTS model were the solution, Xojo would have found a way to make it happen.
The truth of the matter is this isnt a simple problem.
[quote=390217:@Thom McGrath]
Which is precisely why big fix only releases will not work. That doesnt sell licenses to new customers.[/quote]
What I see is that it takes TWO things to become (remain) successful…
new customer acquistion
old customer retention
It takes something to “impress” the new customer, and this is where a full list of “features” is an added benefit
however, once you have gotten them in the door, you need to keep them there… and if the chrome starts to peel … well
But I imagine it would sell a whole lot more subscription renewals. I know they’ve lost out on a few thousand from me over the past few years. I would gladly renew for a stable release that just worked. I know I’m not alone. Given their business model, a satisfied user base renewing annually is worth more than new sales that fail to renew.
Which is possibly why renewals are as expensive as new licenses these days. When I was with Xojo, if I recall correctly, most revenue came from new sales. Sucks, but that was the reality. Maybe things have changed since then, I don’t know.
But renewals have always been a tricky subject. People don’t like updating software, usually for fear that something will change. It’s not just Xojo, it’s pretty much all software. Especially with development projects, people tend to stay with the version they know. It’s easier to deal with the bugs you know than to discover the ones you don’t. So even renewals tend to be driven by new features. Bug fixes don’t sell new licenses and they don’t sell renewals either, because why should you pay for a fix to something that should have worked in the first place?
Fact is, software development is becoming more and more about the small frequent steps instead of the major ones. Windows has taken this approach. So has Chrome, Firefox, Slack, Discord and plenty others. If anything, Xojo’s release schedule is too slow. Look how long it took to support the iPhone X screen, for example.
The question should be, Why should you HAVE to pay for a fix to something that should have worked in the first place?, because in fact, we do. Xojo has a history of releaseing buggy software into production and those bugs persist across major releases. If I have an active subscription and I download a new version with features that I need and then discover a crippling bug after my subscription runs out, Im screwed because Xojo doesnt fix bugs retroactively. Forced upgrades should not be. Theres nothing wrong with Xojo maintaining two releases, a LTS bug fix release and a feature release. Cisco did this with their IOS software and t worked extremely well. Im not saying they need to maintain bug fixes for every release since their inception but at least for the last two or three major releases, especially considering their track record for using their customers as their QA department.
I promise you, Xojo does not have the resources for such a thing.
I dont disagree though that a release should be able to be polished until the kinks worked out, and the rapid release model doesnt allow that to happen. We get one or two dot releases to fix the most critical bugs, but thats about it.
