HARMAN pricing. Is it realistic?

People do misrepresent just to make a point, this is what zwetan is doing here. You and I correctly call AIR 32 EOL, not AIR, not AIR 31, not AIR 33, and he comes back with "AIR as a product is simply not EOL" as if that was our argument. Of course it wasn't our argument and zwetan is discrediting himself once again, sad.

https://forums.adobe.com/people/Leo+Kanel  wrote You should have more faith. See this guy for example: In March 2, he told us not to freak out, and 64bit is coming soon. AIR 33 on March, AIR 34 on June, so probably AIR 35 by September. Joking aside, if a company is able to drop AIR right now and use an alternative solution, there is no point on staying in AIR. AIR for mobile is as old as it gets, and although it is ok to use for desktop, it won't be forever.

here the joke, there are some so called "professional" that still don't know what is an EOL

EOL as "End of Life" means a product is not updated anymore
see End-of-life (product) - Wikipedia

because in June HARMAN released an AIR SDK 33 beta

and before that announced they were taking over AIR (runtime and SDK) development

AIR as a product is simply not EOL

there is an AIR SDK 33, it does support Android 64-bit, that's a fact

you can repeat as much as you want like a mad man that you are dropping AIR, that's your choice

same for ASWC, but please just stop to try to convince everyone around that you are "right"

and that everyone should do like you

you are criticizing Adobe, HARMAN, etc.

and you really don't know what you are talking about

sorry not sorry, but I will not take advice from subpar developers who don't even know how to maintain their own projects
and find it fun to spend countless hours on forums destroying the reputation of a good tech

so yeah I gonna repeat it, there is nothing to worry and no need to freak out

come back in few months or even few years and AIR will still be around
whether you like it or not

if you really want to help people as a professional software developer (assuming you could fit in that category)
instead of spreading rumours and fears about a particular tech like AIR

you should instead tell us how easy and painless, how long it takes and how much it cost to move/port a project from AIR to something else: C++, Qt, Xamarin, React native, Flutter, Cobalt etc.

see something like Cobalt is quite interesting
https://cobalt.dev/

it's from Google/Youtube, it got a great cross-platform OS abstraction, and many things

in fact you can even port it to any platform you want (provided you do the work of actually porting it)

https://cobalt.dev/starboard/porting.html

you could certainly port an AIR app to Cobalt, but it would definitively not happen overnight

Email from HARMAN about pricing:

Hi

Thanks to those who have recently registered to receive our updates. We are working still on a website, there are a number of internal formal steps we need to go through hence some delays I’m afraid, so for now we’ll keep communicating via emails (and thank you to those people who then share the information onto various forum posts!). As before, if you no longer want to be on the list of recipients, please reply by email and let us know.

As mentioned below, there were some issues with the AIR SDK beta that we released, and we have been working on this, particularly with the Animate team to ensure that we’ve got something that can be used with their existing releases. We’re trying to get a few more fairly key things into this so our original target of sending it out tomorrow may slip slightly. We’re still trying to have a very light touch in terms of quality control, just so that it’s in your hands as early as possible, so please bear with us while we focus on maturing the ARMv8 Android binaries in particular plus the SDK and build tools in general. The same will apply in terms of no distribution of this software until we’re satisfied with the quality levels so we will push the binaries out to those who are happy with the attached SDK license agreement. If you’ve not yet read and agreed to this, please reply with your confirmation and we can add you to the distribution list. (This is a slightly convoluted way of a website checkbox to say you’ve read and agree to the terms prior to download..)

We’re also been reviewing the feedback on the pricing plans that we published at the end of last week; thank you to those who have responded either via the forum posts or by email. We are looking to tweak the pricing structures a little in response to some of the feedback, but just to address a couple of points here:

1) we had planned to have pricing levels based on the revenue that you receive from the distribution of your AIR-based applications. This caused consternation both because of the potential issues for accounting, and for those whose business models are different from just creating and distributing their own applications. So we are likely to move to pricing based on overall revenue, with an associated adjustment of the various levels.

2) folk expressed concern at the idea of us having audit rights: this is perfectly standard, as those who have Unity subscriptions can testify to – but this doesn’t mean we will be auditing everybody! As a general rule this would only be invoked if we had major suspicions of a problem, for example if you were shipping the next Angry Birds or Slither.io but claiming to have tiny amounts of revenue, we might notice..

3) comparisons were drawn with Unity and the different levels there; I think because of the final ‘enterprise’ tier it caused a different comparison to what we had been looking at ($20/month for AIR vs $35/month for Unity for individuals; $99/month for AIR vs $125/month for Unity for professionals) but perhaps everyone is already earning above the extra revenue cap that we’d put in there for the professional level.. As mentioned above, we are looking at the pricing and tier levels again and perhaps will adjust how the subscription/tools usage is tied together to try to satisfy those who aren’t happy with this pricing.

4) we’re aware of the problems caused by the timescales, with the Android 64-bit Play Store requirements coming in so soon. We can only offer ours, and Adobe’s, apologies for this whole thing happening so late, it was a long process and we all wish that we were 6+ months earlier with everything. What we’re trying to do is to put AIR onto a commercially sustainable footing, which means ensuring that we can start to add features and improvements that are community-led. We will be putting together a roadmap shortly, when we get our website approved, which covers the short term and outlines some of our wish-list for the longer term.

There were some great suggestions sent in such as to have a ‘lite’ version of AIR with features stripped back, for a low price: things like this are definitely under consideration but would be a future step, as it’s quite a lot of effort to pull an individual feature out from the AIR codebase!

many thanks

     Andrew et al

That's also makes sense for me.

They said that they focus now on Android only, then iOS and next year, Desktop.

So, pay now "only" for solving mandatory Android issues is not fair comparing to AIR 32 (free) in the same way as me as a developer in an year start paying the same to get much more.

But, the price is set and none of us have been consulted.

It is what it is.

Even so, I believe that a few will complain but many will pay. Not all will pay but many will.

In a short term business it will be sucessfull.

In a long therm I'm not so sure but the things can always change.

"Betrayed"

No way, I prepare my self.

Contribute, yes (depend on roadmap).

"ex lover"

No, I never, ever liked Adobe.

I like or liked AIR.

Yes... we will pay,

but I'm personally feeling betrayed by Adobe and I really consider if I want to keep my CC subscription.

As in our company new games are being developed in Unity, the only thing we need is to be able maintain existing projects running on AIR, which was OK until this 64bit Android requirement. I don't think that Adobe was not knowing it and 64 bit support cannot be so difficult for a company with resources like Adobe has. Native packaging for 64bit is just placing different files into different folder in a zip (ane) and tweaking with compilers settings to have a 64 bit runtime. A proof that it is not so difficult is, that someone without previous access to sources was able to implement it in relatively short time.

I have personal problems with other Adobe's products. When I open our 5 year old FLA file in current Animate, it is more laggy than it was before and I'm now having more powerful PC. There are still the same bugs I was reporting years ago when I was in the pre-release group. Working with current Photoshop is also quite not nice experience for me and I understand my colleagues who make graphics, that they are still using Photoshop CS5. When I wanted to use Typekit Roboto font (nothing fancy) for a web page with czech text, it had problems to display some chars correctly, so I switched to Google fonts and I should continue...

I really think that Adobe is in a really bad condition.

I think we need clarity over what the "revenue" numbers represent. Firstly I'm assuming they are USD? Are they solely revenue generated from the app? 

We develop AIR apps for clients which then take over the application, and profit from the revenue of the app. We may develop an app but never see any further profit from the app. This pricing seems to imply that we now need to cover the cost of the AIR license for our clients applications indefinitely?

How are AIR contractors considered here, eg we contract to clients who have an existing AIR app. Is our contracting income considered part of the "AIR-related personal income"?

I think it's marketing that will bring new devs. It might be also up to us. I will surely re-open my blog.

mattr8755445  a écrit What I really don't like is the rules about auditting, and needing to keep the subscription for as long as your apps are on the market. As a Desktop game developer, I can publish a game on Steam, and possibly never need to update it. Under these new rules I'd have to keep paying the AIR fee every year, for who knows how long! But I don't publish games very often - once a year at most - so I can see how developers could exploit the old pricing and only buy a subscription for a month when they publish. I'm not sure what the best compromise is here - maybe give devs a good deal if they buy a long-term subscription, and charge more for a single month? Either way, I'm keen to try porting my Desktop games to mobile, and if AIR makes that easy, I'll be happy, even if I have to pay a lot for it. (But I'll keep using old versions of AIR for my Desktop stuff, if this pricing stays!)

As I said elsewhere in this thread, I'm with you about the two rules. Maybe a compromise would be to limit the license requirement to one year after the last app update? For example, you publish an app or a game with the paid tier, and then you'll have to pay that tier for at least one year of exploitation. After this year, you can leave the app as is, even if you cancel your AIR subscription. What I don't want to have to do, is to republish all my apps with a splash screen, if they don't sell anymore several years after their last update: it might represent a lot of useless work for me, and bring only annoyance to my customers.