They need to move faster - they are extremely slow to respond to the changes going on around them.
I'm investing most of my time learning web technologies and frameworks so I can be more flexible with my customers. I would not put all my eggs in the Claris basket at this point - who knows this may be groundbreaking but my suspicions are that it will be half baked or with ridiculous licensing requirements and prices.
With the changes coming to the release cycle, that is exactly what they are going to be doing. Remember, Brad hasn't been CEO very long. It will take him some time to get everything in place and moving along.
Quarterly releases...
True, the new team did not have an easy start with that new after-sales site.
If you have the time, please sell me on any benefits here.
Thanks in advance.
I would measure improvement on the decrease in the number of bugs breaking existing functionality (regression) and new bugs.
One benefit: less pressure to finish last minute features. If somethingās not ready, you just push it out 3 months later. Yearly release creates more ācrunch timeā as devs and managers are desperate to finish a feature so they can avoid having to wait another year.
Modern apps usually use ~this system (think chrome, or OS security updates). Itās less flashy and exciting (like Appleās yearly product releases) but itās ultimately way smoother, which is great for businesses.
The entire development flow changes. Right now when they want to include a feature in the product, it has to be ready and tested by, let's say, December or January to make it into the product. That seems to be when they start pulling features out of ETS that are not going to make it into the next release cycle.
So the decision-making process goes like this on a yearly cycle ( hypothetical ):
In a quarterly ( or even possibly more frequent release ):
Code quality goes up for stable releases.
Features are released when they are ready. Patches and fixes are built into the process because the release cycle is not as dependent on a list of features.
Since so much changes in a year, they can more easily shift directions.
Add to this all, the changes in core technologies being used under-the-hood, also allows for more seamless integrations.
Faster feedback from the developer community. If something misses the mark, we don't have to wait a year to get a fix.
Decisions are affected by different factors. I know this from our own shift in our development cycle at our company. The factors that affect decisions are very different when the commitment is shorter.
Do you see these features coming often as practical for deployment in solutions where the customer is served on premises?
That's our choice. We can test as our schedule allows, and release tested version on our timeline.
FileMaker is one of the few products I use where there is a version number attached to it. The only piece that "concerns" me, is having multiple versions installed for testing and dev.
We have been verbal in our opposition to annual āversion releasesā for all the reasonās Josh has mentioned and then some.
Weāve previously cited Microsoft Office as a main player that gave up this ridiculous marketing led approach some time ago.
Claris are to be congratulated on their new approach.
Andy
Absolutely!
Even with quarterly releases, the features for e.g. a May release must be ready probably 6 months before, so they can go in beta test.
So we may always have two ETS versions to try plus the current release.
"Version" is definitely a key word I'm having trouble with as far as principles. If a new feature(s) were to be delivered every quarter, how many features would amount to a "version" and then, when would an actual version be released? Further, what would the benefit of a quarterly feature have been to an end user?
What if 19 would have come by quarterly release?
You could basically split the v19 features into 4 quarters and get 1/4 of the feature in August, November, February and May. So one may concentrate on card windows and others on JavaScript. Developers and end users could directly test and use them without waiting till May 2020.
You've omitted the word "version," the exact word I'm having trouble with. 
It's a change in thought. You are buying the FileMaker platform, not FileMaker 19. The version will only be for reference for those installing and reporting back to Claris when you need support.
Remember, subscription. The idea is that they continue to build and add features, you just use FileMaker. Features and versions are no longer tied together. Versions and releases are now the same thing. Features are added as they are ready. There is no trickery or figuring out when to buy. You buy, you use, and as features are added, you update and use them.
These words are the hard sell to those learned.
"Subscription" is for those who want to participate. Drawing upon other connections and participating in those lead to dependancies and finger-pointing when something goes awry. There are already many connections to anybody's stack.
If the software is marketed as a service (SaaS), the learned believe that's not true either because services are consumable where software is not.
Some believe actual data will be charged and that's where America OnLine was. Ironic.
Do your clients have maintenance?
In the long run, Perpetual with maintenance is the lowest cost per user. That is a subscription. If they are not on maintenance? Why not?
Having run numbers for several clients, who were sitting at version 12, to upgrade to version 17 ( at the time ), it would have been cheaper for them to have purchased FM, which they had already done, and kept up on the maintenance, rather than buy 12, then later buy 17...and with maintenance could have kept up with current versions and features.
In a mature market, new customers are rare, the existing customer base is large. Software transitioned from new to mature market in the last decade. That means that vendors could not sustain themselves through the sale of new licenses. The move to subscription therefore makes sense and was necessary. Keeping the new-and-shiny release cycle up at the same time is contradictory to what has been stated above and can only be explained by overly aggressive sales objectives (we get the subscriptions AND the new customers like we got them in the old time!)
We have seen the impact this approach has on software quality, which primarily hurts existing customers. I hope that improvement will not come hand in hand with price hikes.
The issue of how customers will not be locked out of their own data when a subscription ends has largely been left unanswered. Vendors donāt provide easy solutions for this use case. Accessibility of long-term stored data is part of the problem (I.e. legally required storage). With software lifespans of 2 years or even less, this question begs answers urgently.
Selecting a platform for custom software means putting trust in the platform vendor on a long term.
There is much enthusiasm at the beginning with all the new opportunities technology offers. Then comes the phase of realism with technical issues experienced, limitations discovered, lack of support, price hikes. As custom solutions cannot be moved away from a platform as quickly as some vendors make their pricing and licensing moves, customers only can hope that they did not check into Hotel California.
This is my personal view, of course.
Or a "Roach Motel"...
JetBrains has a good solution. Their products do use subscriptions, but if you stop paying, your product will continue working but go back to the version of the beginning of the latest subscription update.
I don't use products, in general, with subscriptions. I view subscriptions as lazy methods by many companies to just boost cash flow.
My view: give me decent features and I'll upgrade to the next perpetual version.
IMHO -- FMP hasn't given any decent new features in many years so it should probably already be a "subscription". LOL