@jb1 Since ROLI acquisition this is not the first time we see JUCE users “underestimated” (in the price/license aspect but especially in the code/features aspect). It’s also clear from your answers that you don’t fully know us small/medium developers, maybe we are not the majority of your paying customers?
Now suddenly AAX is more work to support? What about the MultiBus? It would have been a better excuse (and definitely a great incentive for many of us) to offer the MultiBus as a real Pro feature. Btw, does it work now?
Roli, thanks for including the mobile platforms! Also I think using the yearly revenue as a basis for the price is a great plan. However in my book not including AAX in the lower tier is a big mistake and you just made it worse by obviously not knowing about the terms of AAX development.
The hard part is not cost, but getting into the developer program for AAX. It is free once you get accepted. Telling people AAX is much more work to support… you must be joking, it’s certainly not harder than supporting VST3.
Supporting platforms and format should be what it’s all about, the more the better for your library. Limiting these in any way just limits the usefulness of the library.
I believe adding more stuff to the lower tiers generally benefits everyone once prices are revenue based. Help your users reach those 200k annual income by including all the platforms and formats and in the end everyone benefits.
By not including AAX you make it harder for developers to become Pro in the first place.
Plug-in developer license: can deploy for all plug-in formats, but no mobile platforms.
Mobile developer license: can deploy to all mobile platforms, but cannot use the plug-in wrappers
If one already owns one but also needs the other, strong discount on it, or consider it as a third separate option:
“Cross-platform is my middle name” license: can target all plug-in formats AND all mobile platforms.
This, combined with the (appreciated) pricing based on revenue that also @pflugshaupt has mentioned above, better fits the profiles of users willing to pay for a JUCE license in my opinion. And it has the advantage of giving the impression of paying for what one uses in its business, not more and not less.
I completely agree with the overwhelming thoughts of developers here that the AAX trigger point is wrong. Revenue levels makes perfect sense, but taking that one feature away feels incredibly petty and cheap. This is not the wright thing to do.
I think they should just do a flat fee. If you don’t want to open-source your ios/android/OSX/Windows/Linux app/plugin, it’s $1000. nice and simple. if you already own a JUCE4 perpetual license, it’s $600.
The main driver of the price increase for the Pro license is that it now includes deployment on iOS and Android platforms (plus other platforms we may support in the future).
That’s makes perfect sense…and @yfede’s suggestion above supports that.
Does the AAX restriction mean that one isn’t allowed to release plugins in AAX format at all or only the use of JUCE’s AAX wrapper (in which case one could write one’s own AAX wrapper)?
One thing that certainly would be an added value and were I could understand paying extra one way or another would be if JUCE added support for AAX DSP. Of course, in this case the DSP code still needs to be done separately but then again maybe a very clever JUCE dsp module (yet to come ;)) might help to reduce the overhead.
Although in this case a better approach would be to make AAX DSP the pro feature.
Personally I thought the perpetual upgrade should be in the $600 range considering the difference between the Dev and Master branch. My plugin is still based on JUCE 4.2 (before the MultiBus changes).
The only code from the Dev branch in my plugin are from code changes I suggested on the forum
Thanks for the inclusion. What I forgot above is that by limiting AAX you’d also have reduced the already-smaller-than-au-and-vst number of developers using the AAX wrapper which would have meant even less bug testing by 3rd parties for AAX.
