Mike Chambers, Flash and Adobe PR

The other day, I linked to a blog post by Adobe’s Mike Chambers, in which he let loose concerning the company’s recent announcement about killing off mobile Flash.

I’ve been thinking about Chambers’ blog post all weekend for several reasons.

After listing off his history with Flash, Chambers re-caps the company’s announcements. After that, he writes:

It is this last point which received the most attention, caused the most confusion, and essentially overshadowed all of the other information. Given the very public recent history of the Flash Player on devices this was understandable. However, it is clear that we did not do a good job of communicating why we are are making this shift in strategy. I know how frustrating this has been for the Flash community, and for that I want to apologize. Our goal was to be very clear about WHAT we were doing, but in doing so, we didn’t pay enough attention to explaining WHY we were doing it.

Chambers is outlining the rest of his post. That’s never a bad thing, but it reads as if Chambers is speaking for Adobe in an official capacity.

Now, I’m not sure if Chambers has that privilege at Adobe. Nothing on his “About” page says if the site should be read as representing his employer.

If Chambers doesn’t have permission to speak on Adobe’s behalf, I can’t shake the feeling that he is stepping out of line by clarifying the company’s press release on his own accord. While Chambers obviously is very invested in the Flash platform, having people close to the issue writing things like this can always backfire — especially if their copy isn’t vetted before being posted.

On the other hand, if Chambers did write his post with Adobe’s blessing, I wonder why Adobe’s press release was so jam-packed with ridiculous business-speak, while this post is rather straight-forward, easy to read and coherent.

Baffling.

In addition to the bit about iOS I linked to the other day, Chambers makes several other good points in his post. This bit on HTML5 is especially good:

Related to the point above, HTML5 has very strong support on modern mobile devices and tablets. Indeed, on mobile devices, it has a level of ubiquity similar to what the Flash Player has on the desktop. While performance and implementations haven’t always been great or consistent across devices, they have continued to improve at a pretty dramatic rate (just look at the insane Canvas performance increases between iOS 4 and 5).

This new generation of smart phones and tablets (ushered in by the original Apple iPhone) are only a couple of years old. Because of this, the rendering engines deployed on these devices (most WebKit based) were all also relatively new and modern. The end result is that when developing for mobile devices and tablets today, you don’t have to deal with legacy browsers as you do on the desktop.

His point about iOS and Android users looking toward apps for media and gaming — as opposed to the mobile browser — is also quite accurate. Most iOS nerds look down on web apps, since they can’t offer the same level of performance and system integration as native apps can and do.

While web apps may be the best way to reach all mobile users, native apps are the best way to reach a certain set in the best way possible.

That isn’t a small difference, and I think Adobe (or at least Chambers) recognizes.

Chambers also writes about how fragmentation in the Android universe makes developing a browser plug-in to work across devices very difficult:

While we have good relationships on all levels of this ecosystem, having to do specific work for different combinations of OS, Hardware and event components has taken a significant amount of resources. For each new device, browser and operating system released, the resources required to develop, test and maintain the Flash Player also increases. This is something that we realized is simply not scalable or sustainable.

Right after that, he defends Adobe Air for mobile — which isn’t going anywhere at this point — against these issues:

There are a couple of differences which make AIR development significantly less resource intensive, including a more well defined API that we can target, as well as not needing to worry about differences in browsers or new browser versions. Ultimately though, developers are building successful applications with Adobe AIR, and thus it makes sense for us to continue to invest in it.

It’s subtle, but Chambers himself is confirming what so many of us already know — Flash is resource intensive and messy.

Looking to the future, he writes:

We feel that Flash continues to play a vital role of enabling features and functionality on the web that are not otherwise possible. As such, we have a long term commitment to the Flash Player on desktops, and are actively working on the next Flash Player version.

Of course, with the growth and continued improved browser support of HTML5, the role of Flash will change. We feel that for the foreseeable future, Flash is particularly strong in delivering advanced video, as well as providing a robust, and graphically rich gaming platform. We are focusing our Flash Player efforts around these areas.

It is hard to argue that Flash is widely-used for video and gaming on the web. However, at some point down the road, I believe that Flash on the desktop will run into the some of the same issues that mobile Flash did. While fragmentation doesn’t seem to be a huge issues for Flash on the desktop, I know on the Mac at least, performance is a problem.[1. Apple ships the Mac without the Flash plugin installed. While iOS is big enough for Adobe to feel it, OS X isn’t. I don’t think Adobe would can Flash for the desktop just because Macs ship without it by default. Besides, it’s just a few clicks to install it.]

Whatever happens with Flash in the long run, it’s nice to have the mobile discussion behind us, even though Adobe will continue to support devices that have Flash installed at this point. Over time, of course, the number of devices in that category will shrink.

I still wonder if Chambers’ blog post was blessed by Adobe, though. I think it should have been, from a company-wide PR perspective. Whatever the answer is to that, I’m glad he posted it. Adobe’s PR people should take some lessons from it.