Xojo and the Rapid Release Model

If I could change one thing about Xojo what would it be?  My answer is, without a doubt, the Rapid Release Model.  Here’s why.

The idea of the Rapid Release Model isn’t a bad one.  In the not too distant past many applications had major yearly updates.  Many still do.  In fact, Xojo (when it was called Real Studio) did this with varying degrees of quality.

Some of the complaints about the yearly, monolithic, release of Xojo (back when it was Real Studio) was that it wasn’t a very stable release and it took several dot releases to get it right.  This was the impetus that led me into the Beta Program so I could test out new features before it was released.  I was tired of new features not being usable due to an obvious lack of real world testing.

In theory, the Rapid Release Model introduces smaller changes and a few new features each release.  Releases are roughly every quarter but in recent years this timeframe has not been as consistent.  I believe this change happened, in large part, to address some of the complaints of the Rapid Release Model.  One of the complaints being that the constant drive to get new features in every release gives the software a perpetual beta feeling.  I would argue that the recent changes to the Windows drawing system certainly justifies that feeling to many current Xojo developers.  

From a developer standpoint, I can only imagine the pressure on Xojo’s small development team to constantly add new features every 90 days.  It means that developers are always pushed to get things done rather then get them right the first time.  Again, I would point to the plethora of changes to the Windows drawing system that have spanned many releases as proof.

I believe that marketing is entirely behind this new-features-every-release mantra so they can get buzz about something in every release.  I get it:  for a small company they need to create as much buzz as possible.  Buzz creates some sales and renewals.  But I think the Rapid Release Model is actually hurting them with many developers who value stability over new features.

More evidence that the Rapid Release Model is hurting Xojo is their recent change of telling customers their development plans.  No longer will they tell us the target date of when a feature is released and instead they’re simply saying if it’s a ‘priority’ or ‘important’.  Prior to this, Xojo CEO Geoff Perlman said that Interops and Android would ship by the end of 2017 and not only did they not deliver, but it seems highly unlikely they’ll get it out by the end of 2018 in anything other than an alpha release (purely a guess on my part and I’d love to be wrong).  

Being poor at estimating isn’t just a Xojo problem.  Chrono-Optimism is a human condition and I believe the old adage that 80% of the work takes 20% of the time and the final 20% takes 80% of the time.  Estimating is an arcane art form and at times software development is pure magic that takes time.  Forcing releases into this 90 day window makes the problem worse by having incomplete solutions and incomplete testing.

When all is said and done, I believe Xojo would be better off ditching the Rapid Release Model and going back to monolithic releases with regular dot releases that does nothing but fix bugs.  Perhaps this means that there are only two major releases a year.  Sometimes only one.

The Rapid Release Model is not without some merit.  We currently know that every release will fix a large number of bugs and we know roughly when that release is going to come out.  Not all bugs are created equal but for many developers we can’t wait six months to a year to get a release that fixes some bugs.  So any replacement to the Rapid Release Model must take into account that Xojo developers need a regular, perhaps monthly, bug fix releases for critical and important bugs.

I think changing to a hybrid model between the monolithic release and Rapid Release Model fits the small Xojo team better.  First, it lets the new features gestate in internal testing longer before we ever see them without being rushed out the door.  Second, the regular release of bug fix builds is simply that – bug fixes – and lets the developers continue to work on the next big thing without the pressure of having to add new things in each release.

To say that the Rapid Release Model is a failure is hyperbole.  To say that the model makes the product beta quality is also a stretch.  The truth is somewhere in the middle and I think this is an important discussion for the future of Xojo and their customer base.  What do you think?

11 thoughts on “Xojo and the Rapid Release Model

  1. Well, how about a schedule which uses the year better.

    The conference is in May, so why not present in May what is coming and start beta testing right at the conference?
    Than release later in summer with bug fixing releases in fall?

    FileMaker now runs on a yearly circle:
    * In May a new release comes.
    * In July / August at the big conference they present to attendees only a preview of next version and give technical presentation for new stuff in last release from May.
    * Than in October, developers are briefed about what’s coming for next version, which may be same as conference, but some new features or some skipped.
    * In Februar, March, April they give beta versions, first to small group (FBA Platinum), than to bigger group (FBA) and than to all their signed up developers (FDS).
    * May is public release.
    * Than in May and June there are webinars and local events to present what’s new.

    Xojo could do similar. Wether it’s one or two release per year isn’t that important.
    Microsoft runs on two per year.

  2. I think the main driver for the Rapid Release Model in addition to creating marketing opportunities was to create a steady income stream over the year. Otherwise spot on.

    • Ah. Didn’t even think of that but I can see why that’s part of the equation too.

      So if Xojo goes back to the monolithic or hybrid release program do you think that changes their subscription model? I don’t think it does but I’d love to get your take on it.

      • I think a monolithic release will make it more difficult to attract users over the year. On the other hand the Rapid Release Model has led to a decrease in the quality of Xojo, and the constant complaints are more damaging in the long run. After all, reputations are hard to build and easy to loose.

        I think a compromise could be a monolithic release with bug fixes only each month (Xojo 2018.1 to 2018.12, resulting in a good final product), and a beta program release (2019b1 to 2019b4 or b12) that includes bug fixes and new features and will become the new release Xojo 2019.1 the next year.

        That way those who require stability have a final product to work with. And those who want to risk using new features can decide for themselves if the feature is stable or desirable enough for them.

  3. I would also opt for the Filemaker model, as Christian says.
    Additional I would say that is important to have enough people doing serious and constructive testing. Think Xojo Inc could guide and focus alpha- and beta-testers better.

  4. Another point to consider is the time available to the beta testers to test each release. I would have more time to beta test two releases a year than to beta test four releases each year. With increased time for running smaller beta-testing programs then I would increase my beta-testing quality feedback. Currently I run a few smaller test programs and start using the beta program for development. This works well if there are only minor bugs.

    • Those are good points which is the making of another blog post I’ve been thinking about. There really is no incentive for us to beta test a release other than trying to find bugs before they get to us. I mean, sure, that’s a laudable goal, but it’s not really an incentive.

      I’ve always thought that some incentive is better than what we have now. Would love to get a 5% discount off renewals for being a good beta tester. Heck, even a “Beta Tester of the Month” award is better than what we currently have. Not sure how any of that would be administered but it would be nice to get something beside the satisfaction that we tried.

  5. The Rapid Release Model is the only thing that actually justifies their subscription-based business model. Why would I pay for a subscription if there will only be a release once per year?

    And that is one of the biggest issues with Xojo in general: The subscription. And the fact that I have to buy several third party tools just to get something more than just basic functionality.

    Using Xojo is EXPENSIVE, and the third party ecosystem is also costly and not nearly as vast as the ecosystem around other tools.

    What Xojo has going for itself is the fact that the IDE runs on all three major platforms — and that it has a visual designer. That’s quite unique and a big selling point when you want to use a BASIC-style language. The only other thing that works nearly as well with a Visual Designer on all three platforms that I know of would be Lazarus/Free Pascal. B4J, which would be a great alternative, unfortunately needs Windows as a development platform, which is kind of a show stopper for me — I want to primarily work on Linux and only use the other two platforms in VMs for testing purposes (if at all).

    Back to the point. I do not like or usually endorse subscription-based business models. I hate to be forced to constantly pay for using the same software. And again, in order to make a subscription acceptable, you have to release fast and frequently, because otherwise you’re basically just renting the software to your customers.

    And the big elephant in the room also is: Why pay for a software development tool in the first place when things like Xcode, Android Studio, eclipse, Netbeans, Spyder, Lazarus, Gambas, Visual Studio Community Edition, Visual Studio for Mac and Visual Studio Code & Python, C++, C and Java are free?

    These days, you really have to deliver a LOT of value when you’re asking for money for software development tools — the Open Source movement mostly killed that business. (I’m not saying that this is a good thing, but it’s what factually happened and it is a reality we all need to deal with one way or another.)

    • So how to do those companies make their money? Well, Apple has their hardware, Microsoft has Windows, Office, Azure and huge marketshare. The rest have services to help pay for their tools. They have 3rd party licensing deals and revenue streams to help make up the difference. Xojo has none of this advantage and it’s one of the reasons why I think they should have offer consulting services. Sure, it competes with me and other Xojo consultants but it’s a revenue stream and lends an air of legitimacy.

      The Xojo subscription model isn’t a true subscription model. It’s more like you buy a license and get free updates for a year. Once your year runs out you can still keep using the last version you were entitled to. So in that sense it’s not much different than the monolithic software licenses.

  6. I saw this on MacDailyNews.com about Apple employees ranking Tim Cook much lower. Their comment included this:

    “…Driving too hard, too fast, and for too long leads to accidents.

    We speak from experience, albeit at a far, far smaller level than yours. We’ve tried and been exposed to several methods as both managers and employees in the television, financial, and online media industries. Regardless of the size of your department or company, people are people. You can push people to a point that’s very productive, but when you exceed that point, it’s all downhill for everyone involved. It’s not a badge of honor. It’s not an “I love this company!” statement. It’s simply mismanagement. It’s verifiably unhealthy and it leads directly to diminished quality, increased turnover, and productivity declines. And customer satisfaction ultimately suffers. …”

    The one thing that Xojo has going for it is that there has been very little turnover. Their compiler engineer is no longer a full-time employee but other than that it’s mostly people that have been there a long time.

  7. I would love to see a release schedule that is based on stablilty of the software, not the fact that 90 days has past. So release it when it is ready… but by the same token make the releases make sense. Dot releases fix bugs. Full releases include “value added features” (and by this I don’t mean a new way to do “X”, because the previous way didn’t work, that would be a bug fix). But then the “subscription” model and the “release” model need to coincide. The customer gets ALL the DOT releases for any MAJOR release during his/her subscription. Meaning if Xojo99.0 is released during the last month of my subscription, I am still able to get Xojo99.1 thru Xojo99.9 regardless of when they are released..

Comments are closed.