[solved, has been re-included] - Reasoning behind AAX only being included in Pro-license?


#31

You mean that there is no possibility that the licensing terms that exclude AAX are being reconsidered publicly?
I was under the impression that this sneak peek into the new licensing terms was exactly meant for us developers to express our opinions about it, so that it could be adjusted before final release.


#32

It’s been a while now that code signing AAX has no cost for the developer but, even if there was, I don’t understand why a cost we should already been paying has to be applied here. I understand that maintaining AAX is a PITA, but the SDK by itself is free. Unless I’m missing something, I don’t see why we should pay more for that. Supporting AAX is absolutely not related to the overall turnover of a company… it’s just a format.

My 2 cents


#33

On the other hand… if you want to make the AAX format available only for a sort of “high profile developers”, I’m totally ok with that. But, then, there should be another level of support for high profile devs.


#34

Supporting AAX is significantly more work for us to support, and on that basis we feel it’s justified to reserve it for the Pro licensees.

It seems overall more like an opposition of principle. The reality is that most of existing customers will have to pay $15 more per month to release on AAX. Hopefully this would be paid for several times by sales on AAX, so from a business perspective I don’t really understand why it is so controversial?


#35

It’s the principle, JB. I’m sorry… but with this move ROLI decided to remodel the licensing by removing features to existing paying customers. As said, I’ll be more than happy to pay the full JUCE 5 license (it’s not an impacting cost), but as many other of my fellow colleagues here, I feel that’s not the right way to separate Personal/Indie from Professional. You may add more services, different levels of B2B support and many other features instead. I’ll be happy to pay even more that 1k/year… but having to do that to get what I’m already using just doesn’t feels right.

My 2 cents


#36

While I understand your need to find a proper business model to monetise your investment, I am a bit worried on the trend. I had a bad experience in the past with a security software tool initially marketed by a developer for a very reasonable price, then acquired by a large company, with the result of prices jumping over 500%.

I understand it’s not easy to keep a fees structure that doesn’t penalise existing users while at the same time ensuring any important developments are paid an extra fee. But I feel that if you call your licenses “perpetual”, there should be a minimum update version across releases, where clients don’t need to pay anything extra for keeping the same level of functionality.

This would mean only charging serious enhancements/modules. Just my 2 cents.


#37

Just out of curiosity, I checked how many commits have changed the code in the AAX wrapper since a year ago.
Turns out AAX is the format with the less of them :sweat_smile:

(you can test that yourself by issuing the following commands inside the juce_audio_plugin_client directory)

git log --since=2016-04-20 --oneline AAX | wc -l
      19

git log --since=2016-04-20 --oneline AU | wc -l
      31

git log --since=2016-04-20 --oneline VST3 | wc -l
      38

git log --since=2016-04-20 --oneline VST | wc -l
      38

#38

I don’t think that the number of commits is an accurate representation of the work required…


#39

Yes, it is, because more than the money, this cool idea is impacting our trust in the fairness of future licensing terms.

The idea of having to pay more for the live coding engine was nice: you had to pay for a new cool tool which you couldn’t otherwise have used. But this time it looks like an attempt to target a more fundamental part of JUCE because the live coding engine turned out not to earn enough money.

And again, I am saying this while stressing how good JUCE is from a technical standpoint


#40

I think you’re seeing the forest for the trees.

JUCE 5 brings a new free license until $50k revenue, the Indie monthly price decreases by 40%, and the Pro license now includes iOS and Android.


#41

100% agree with @yfede.

@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?


#42

Ok, so why not leave AAX in, and have a lower threshold on income for free Personal license and reduce the price for Indie a little less?


#43

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.


#44

Just an alternative idea:

  • 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.


#45

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.

Separating out mobile would make much more sense.

This is terribly disappointing.


#46

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.


#47

@jb1 From the other thread:

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.

Including AAX in that does not.


#48

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.


#49

Hey everyone

Thank you for the feedback on AAX support. After discussing with the JUCE team, we’ve decided to re-include AAX to the Indie license.

Now we can all get back to work :slight_smile:


#50

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 :slight_smile:

Rail