[Adobe’s decision to stop developing Flash for mobile browsers is the talk of the day – but the reasons behind Flash’s ultimate failure are not that obvious. Guest author Francisco Kattan discusses the chain of events that led to the death of Flash – a time bomb inadvertently planted by Adobe many years ago].
Ever since Adobe announced that it will stop developing Flash for mobile browsers, the blogosphere has been buzzing with a broad range of sentiments including “I told you so” by critics, disbelief by Flash developers, Monday morning quarterbacking by analysts, and even a petition for Adobe’s CEO to resign. Check out also the Occupy Flash and Occupy HTML manifestos from the opposing camps. Flash is one of those topics that attract very emotional responses from both its passionate developer community and its very vocal detractors. Although I am generally an Adobe supporter, I will put emotion aside and summarize, in hindsight, what went wrong. For full disclosure, I am a former Adobe employee, but this post is based only on publicly available information.
HTML5 did not kill Flash. Steve Jobs did not kill Flash. The death of Flash was caused by a time bomb planted inadvertently by Adobe many years ago.
Although Flash for mobile ultimately died because Adobe did not adapt fast enough to post iPhone changes in the ecosystem, the seeds for Adobe’s failure were planted earlier on. To understand what went wrong, let’s first review what happened before the iPhone and how those events set the stage for what happened later.
Before the iPhone – the Flash Lite era
Back in the early to mid 2000’s, there was great demand from handset makers (OEMs) who were willing to pay for Flash Lite (the mobile version of Flash at that time) and Adobe decided to collect a per-device license fee for the software. This decision set in motion the incentives and behavior that would ultimately lead to the demise of Flash in mobile, and as I explain later in this post, will also kill Flash on the desktop. Adobe’s ambition to create a platform for delivering rich internet experiences is now doomed.
A big question in many people’s minds is why Adobe didn’t just replicate the model that had been successful with PDF and the desktop Flash Player: make the runtime freely available and monetize it with increased tools revenue. Presumably this would have motivated Adobe to prioritize platform consistency over broad (but fragmented) reach. But it was not that simple.
Although there was a thriving Flash Lite ecosystem in Japan (developers creating content and distributing it via the operators), Flash Lite was initially NOT used as an apps platform in other countries. Flash Lite was used in many cases by OEMs who were looking to differentiate their devices by building expressive user interfaces for the core applications (home screen, dialer, address book, messaging, call log, and others). The LG Prada is a great example of the kind of user interface handset makers could build using Flash Lite. This device featured an iPhone-like touch interface back in 2006 (demo). The Samsung D900 and the LG Chocolate are good examples also. Although these devices included Flash Lite, they did not offer an opportunity for developers to distribute Flash-based content. The implementation of Flash Lite was closed to third party developers as there was no Flash in the browser nor the ability to execute Flash-based apps. As there was no clear opportunity for developers and therefore no tools revenue to be made, it made sense for Adobe to collect a per-device fee from handset makers rather than monetize the player via the tools.
Conflicting objectives: handset makers versus developers
As it happens, when the opportunity to deploy Flash Lite as an applications platform presented itself later on (especially on Nokia and Sony Ericsson devices), Adobe did not adapt its business model right away. In hindsight, this turned out to be a costly mistake. At that point, there was an inherent conflict between the needs of handset makers looking to differentiate their devices and the needs of developers who needed a consistent platform across devices. As OEMs were paying the bills and the mobile team was measured on revenue, it was natural for Adobe to prioritize OEM requirements over developer requirements and to let OEMs implement Flash to meet their own needs. OEMs licensed the source code from Adobe and created their own binary implementations that were not consistent across devices. Flash Lite was used sometimes for building device user interfaces, other times for browsing Flash content, and other times for running standalone apps. In addition, OEMs did not always implement the same set of APIs creating additional fragmentation for developers. Worse yet, as the runtime was not updateable over the air, device fragmentation would only get worse with time.
Lack of Distribution and Monetization Opportunities for Developers
Even when Flash Lite was deployed as a platform to run standalone apps (not in the browser), there was no easy way for developers to distribute their apps. There were no iPhone style app stores at the time. Developers had to distribute their content via middlemen (aggregators) who collected a tax and who had distribution deals with handset OEMs and network operators. Worse, the OEMs and Operators did not have good merchandising channels and discovery of apps by consumers was very poor to say the least. There was no streamlined way for Flash developers to reach consumers. This was a major issue for developers as it was for Adobe. At the same time, revenue from OEMs continued to grow –shipments of Flash enabled devices were more than doubling every year– masking the severity of the problem and allowing the time bomb to continue to tick.
A glimpse of hope: partnering with operators to reach consumers
In an effort to create a thriving ecosystem for developers, Adobe turned its attention to mobile operators who at the time controlled content distribution via their infamous walled gardens. Working with operators was not a popular move especially with Adobe’s Web developers who were new to mobile and did not appreciate the level of control that operators had at the time. Adobe worked with several operators but most prominently with Verizon Wireless (see the April 2006 news release) which on paper was an ideal partner. As one of the world’s largest CDMA operators, Verizon Wireless had great influence over its OEMs and was able to specify the Flash runtime on its devices. Verizon Wireless also had the most successful app store in the US at the time (the BREW-based Get it Now download market).
Adobe and Verizon launched two services: A Flash app download service as part of the BREW Get it Now ecosystem (see the October 2006 news) and Verizon “Dashboard” (announced in March 2007), a much more ambitious service based on Adobe’s on-device portal called Flash Cast. Both services, had issues. The BREW Get it Now offering failed because it was too difficult for developers to onboard new apps, developer revenue shares were too thin, app discovery was difficult for consumers, and Verizon moved too slowly to certify new handsets with Flash (for more on this see: Is Brew Dead? Lessons Learned).
The Dashboard service failed because it took far too long to launch, missing its market window. Verizon announced Dashboard in March 2007 promising availability in the second half of the year, but the service did not see the light of day until September 2008. Even then the service was available on only one handset out of a broad device lineup available on Verizon stores. With the iPhone and Android devices attracting all developer attention by then, Flash Cast and Dashboard were too little too late.
It is worth mentioning that the innovation around Flash Cast and Verizon Dashboard was quite promising. In hindsight, the service resembled many of the key attributes of the iPhone: like the iPhone, it had an App Store concept where consumers could discover and purchase widgets with a revenue share back to developers. Like the iPhone, it was designed as a walled garden with a gate keeper (the operator in this case). Like the iPhone it featured an expressive user experience as the widgets and the user interface were based on Adobe Flash. However, unlike Apple, Adobe did not have end to end control of the ecosystem and the service was late to market as a result. The service was designed for 2006, not 2008, a big difference considering the iPhone showed up in 2007 changing all the rules. Although Adobe was innovating fast, its innovation did not reach consumers in time because it relied on slow moving partners.
Enter Steve Jobs and the iPhone — CONTROL-ALT-DELETE on the ecosystem
The launch of the iPhone changed the mobile ecosystem so dramatically that it disrupted all incumbents in ways that were not readily apparent right away. The disruption was so great, that it favored new entrants that were starting from scratch under the new rules (Apple and Google) over incumbents who had existing market positions and established business models (Nokia, RIM, Motorola, Palm, Microsoft, Qualcomm/BREW, Symbian, Sony Ericsson, and of course, Adobe). Like many other players, Adobe did not adapt fast enough and paid the price as a result. Consider three major changes in the ecosystem and how they negatively impacted Adobe Flash:
Apple caused the existing operator walled gardens to crumble while Adobe was focused on building ecosystems with operators.
Consumers started dumping feature phones in favor of buying smart phones, but Adobe had focused on feature phones which represented a much larger share of device shipments (and revenue to the mobile business unit).
Mobile browsing finally took off as a mainstream service, but Adobe’s mobile player did not support 100% of the desktop Flash content as demanded by Steve Jobs.
As you may recall, the first generation iPhone did not have an App Store or SDK. It was all about browsing the internet (see the “internet in your pocket” ad campaign). The iPhone was the first handset with a decent browsing experience and quickly took the bulk share of mobile browsing (even though it represented only a very small share of device shipments). The lack of Flash was a glaring gap at the time.
If there was ever a time that Steve Jobs needed Flash, it was in 2007 with the first generation iPhone
Unfortunately Flash was not ready at the time. Because Adobe generated revenue from device shipments, it had been focused on the feature phone category which represented a much larger share of the market in terms of shipments (but nearly zero percent in terms of web browsing page views!). Neither version of the Flash Player met Steve Job’s requirements. Flash Lite did not support all the Flash content on the Internet because it had been optimized for more constrained devices and the full Flash Player did not run well on smart phones because it required the power of a desktop computer. Steve Jobs famously once said, “there is this missing product in the middle,” referring to this issue.
Incredibly, Adobe did not ship the mobile version of the full Flash Player until June of 2010 (version 10.1), three long years after the launch of the iPhone! By then, the iPhone was the most popular device on the planet and Apple had shifted focus from browsing the internet to apps where Flash did not matter (recall the “there is an app for that” ad campaign). Adobe had missed the window of opportunity to be part of the iPhone.
Sure, Apple could have still adopted the Flash Platform in 2010, but it was not in the company’s best interest at that time. In the end, Apple decided not to adopt the Flash Platform because Flash would limit its ability to differentiate its devices. Apple marketing was focused on the broad availability of apps that worked best on iOS. To support such positioning, Apple needed developers to target the latest set of proprietary APIs (accelerometer, compass, gyroscope, etc.) rather than write to a higher level cross-device platform that would deliver undifferentiated experiences across Apple and non-Apple devices. This is why Apple decided to block Flash from iOS (for more on this see: Why Steve Jobs will never put Adobe Flash on iOS devices).
Adobe did react to the disruption the iPhone had created and adjusted its business model, but it was too late by then. In March of 2008, Adobe announced the Open Screen Project essentially making the player free for OEMs as long as they implemented it in a consistent way for developers. To ensure consistency for developers, Adobe also began to create its own binary implementation of the player for the leading mobile platforms in the same way it had always done for Windows and Mac OS on the desktop. However, with “Flashless” iOS devices leading the charts and HTML5 adoption increasing on mobile devices and web properties, the writing was already on the wall and there was no turning back. Adobe had been unable to disarm the time bomb in time and it eventually exploded.
Flash for mobile is dead, but Flash for the desktop lives on, right? Wrong!
It’s pretty simple: Flash for the desktop cannot survive without mobile support. With PCs becoming a smaller and smaller share of Internet connected devices (see chart below), it’s only a matter of time before most web sites will be updated to not require Flash. It is hard to imagine many examples of web properties that would want to exclude the majority of the eyeballs on the internet by requiring Flash.
Of course, web sites don’t have to remove Flash content outright. They can add logic to serve Flash content for desktops and HTML5 content for other devices. This will in fact be the case during a multi-year transition to a “Flashless” internet. As new content is created that excludes Flash, as HTML5 adoption and capabilities catch up to Flash, and as the share of PCs continues to decline, the percent of web sites that serve Flash content on the internet will approach zero, causing Flash on the desktop to die a slow death.
Note that this transition began several years ago as web properties adapted to support iOS devices — which account for a whopping 62% of mobile browsing page views! YouTube, one of Adobe’s flagship references already added support for HTML5, dealing Flash a major blow. jQuery, a popular JavaScript library that competes with Flash for building interactive sites has already overtaken Flash. The tide on HTML5 is turning and it’s only a matter of time before Flash on the desktop suffers the same fate as its mobile sibling.
To recap, the seeds for Adobe’s failure with Flash were planted many years ago with a revenue model that made sense at that time, but remained as a ticking time bomb for far too long. The model caused Adobe to move in a direction that was opposite to where the market ultimately moved to, especially after the launch of the iPhone (feature phones versus smartphones, OEM requirements versus developer requirements, operators as channel versus Apple and Google as channel). In addition, when the iPhone was launched, Adobe moved too slowly to adapt to the new market reality (3 years to launch Flash Player 10.1), ultimately killing Flash.
What do you think? What do you believe went wrong with Flash in mobile? Do you think Flash will survive on the desktop?
– Francisco
[Francisco Kattan has worked in the mobile ecosystem for over 10 years, including as Director of Product Marketing and Developer Relations for Adobe’s Mobile Business Unit. He also held leadership roles at Edify, Openwave, and currently Alcatel Lucent where he is Senior Director of Product Management. Follow Francisco on Twitter @FranciscoKattan]