Adobe Archives - SlashData Blog

Return on Developer Investment

My most fun job ever was as a C++ developer. Ok, I don’t have much grey hair yet, but I fondly remember the late 90s and the challenges of writing a background synchronisation application on a Compaq iPaq. And reverse engineering Mozilla’s Navigator into an XSLT parser.

My second most fun job ever has been building a company that helps the world understand developers, with research. We’ve come a long way – and a few pivots – from surveying the pulse of 400 developers in 2009 to 30,000 developers annually in 2016. That’s a lot of data – in fact more than our analyst team can chew.

It’s a privilege to be working with some of the biggest names in tech – I ‘ve learned a lot the past 2 years. Earlier this month, Amazon, Microsoft, Facebook, Adobe, Intel, Oracle and many more joined our first Future Developer Summit, and shared some of their best practices in how they work with developers. I ‘d like to share some the learnings here.

Return on Developer Investment.

You would think that with billions of dollars spent every year on building tools for developers, running hackathons, loyalty programs, tutorials and how-tos, evangelist and MVP programs – the platform leaders would have figured it all out. Yet, with so much money being spent on developer tools and marketing there is no standard for measuring the Return on Developer Investment.

Most companies represented at the Future Developer Summit shared how they measure success. At their inception, developer-facing orgs measure success by number of developers touched – but that’s a meaningless metric, a dinosaur from the age of print marketing. Some platforms are using NPS (net promoter score), polling their active developers once a year for how likely they are to recommend the platform. Many are informing product decisions based on developer comments (“will you ever fix that”?) – you’ll be surprised how many decisions are taken based on “the devs that I spoke to said..”.

Other developer relations teams are measuring success through the number of apps in the store, and the number of apps using signature APIs. In the case of open source projects, a popular metric is GitHub stars, forks and commits over time. The more sophisticated platforms track the Return on Developer Investment funnel from SDK downloads to app download and use. But there isn’t a consistent way to measure how the investments in hackathons, tutorials, how-tos, loaner devices, evangelism programs and some many more developer-facing activities are paying off for the likes of Google, Amazon and Facebook.

Quality of apps, not quantity.

Another theme of the Future Developer Summit was the need for quality, not quantity of applications at the start of an ecosystem. B2B ecosystems like Slack and Intuit prioritise quality; Poorly written messaging apps can damage not just the perception of Slack, but also the perception of chatbots in general. Similarly, a poorly written app for the QuickBooks platform can wreak havoc to sensitive financial data for thousands of small businesses. As a result both Slack and Intuit have very stringent app review processes, including weeks of testing, usability and security reviews. To improve quality for bots, Slack has pioneered a “Botness” program, bringing together bot platforms and leading bot developers; the aim is to “make bots suck less” i.e. improve the bot user experience and avert a long-term damage to the reputation of chat bots. There are already 250 members signed up and the next event is on November 4 in NYC .

The next Future Developer Summit will focus on best practices for developer relations. If you ‘d like to be part of the invite-only audience of platform leaders, register your interest at www.futuredeveloper.io

Cross-Platform Developer Tools 2012

We are proud to announce the launch of Cross-Platform Tools 2012 – the free, industry-first report on cross-platform developer tools. You can download a free copy here. Cross-platform tools (CPTs) allow developers to create applications for multiple platforms with a small incremental cost. Their impact is both tactical in allowing developers to target more platforms, but also strategic in having the potential to disrupt the Apple/Google duopoly in mobile ecosystems.

Our report is based on a 6-month project, comprising a large-scale online developer survey (nearly 2,500 respondents) combined with meticulous research, vendor interviews and analysis of this complex market of over 100 tools vendors. This report would not have been possible without the support of Marmalade, RunRev, Verizon Developer Communities, Xamarin and the many other companies behind this multi-sponsored project.

Cross-platform tools (CPTs) solve real challenges today; they allow developers to create applications for multiple platforms – usually mobile, but increasingly tablets or TV screens – from almost the same codebase or from within the same design tool. CPTs reduce the cost of platform fragmentation and allow developers to target new platforms at a small incremental cost. More importantly, cross-platform tools allow software companies targeting multiple platforms to reuse developer skills, share codebases, synchronise releases and reduce support costs.

Early leaders in the cross-platform tools space

Our survey revealed that PhoneGap and Sencha lead in terms of mindshare, as they are currently used by 32% and 30% of cross-platform developers, irrespective of their primary tools. Completing the top-5 ranking of our Mindshare Index are Xamarin’s MonoTouch / Mono for Android, Appcelerator and Adobe (Flex). The second half of the top-10 CPTs in terms of current use are Unity, Corona, AppMobi, RunRev and MoSync.

PhoneGap (23%), Xamarin Mono (22%) and Unity (22%) are the tools most developers plan to adopt, irrespective of their primary tool. This market is in constant flux, with developers experimenting and trying out new tools – for example PhoneGap is a stepping stone to cross-platform development as it leads Mindshare, IntentShare, but also comes third in the tools being abandoned. The most widely used CPT accounts for just half of the Mindshare seen in the iOS and Android platforms in our Developer Economics 2011 report.

Cross-platform tools challenge the Apple/Google duopoly

The real impact of cross-platform tools is strategic. Just as the Apple/Google duopoly began to look impenetrable in 2011, a major disruption is flattening the playing field for competitors like Microsoft’s WP7, RIM’s BlackBerry OS and Samsung’s Bada: cross-platform tools are letting developers target multiple platforms with low incremental costs and high levels of code reuse.

2012 marks an inflexion point in the war of mobile ecosystems where the network effects built by Apple and Google are being challenged by an unsuspected new entrant. Cross-platform tools (CPTs) make it easier for example for an iPhone developer to reach Android and Windows Phone 7 users. CPTs dilute network effects by allowing other ecosystems to compete not just in terms of the number of apps listed, but also the availability of top apps, the time-to- market (an app rarely appears at the same time across all platform app stores) and the overall app quality.

Moreover, cross-platform tools reduce barriers to entry and democratise app development, by allowing developers from any language (HTML, Java, C++), any background (hobbyist, pros, agencies, corporates) and any skill level (visual designer to hard-core developer) to build mobile apps. The dozens of CPTs available cater to every developer segment, from creative designers to C++ gurus to hobbyist website enthusiasts to Fortune-500 CIOs. The result could be termed a “democratisation” of software development (in the words of Unity’s Dan Adams), in that mobile platforms may be opened up to all types of developers.

Mergers, financings and the survival of the strongest

We have identified over 100 cross-platform developer tools, in a market that’s booming with new players in 2011. Cross-platform tools have passed the “early adopter” phase, and are now moving into mainstream. For example vendor Sencha counts 1.6 million SDK downloads, Corona apps have reportedly been downloaded 35 million times in 2011, Unity reports 200,000 developers active each month, while Appcelerator boasts 35,000 apps published using the tool and deployed on 40 million devices.

Since 2011, cross-platform tool vendors have raised major VC funding, have been acquired, or achieved major releases. In the CPT space we have tracked 10 acquisitions, and over US$ 200 million in funding rounds. This is a market that takes cash to survive: CPT vendors are subsidizing their entry to market with free products, based on ample VC funding. For example OpenPlug ceased operations as it failed to find a monetisation model, with its key challenge being the conversion of freemium users into paying customers for its support and professional services. CPT vendors without a compelling free product will be washed out by the competition.

Cross-platform tools are taking HTML further than browsers can

The purpose of HTML5 has been to extend the capabilities of web apps (those developed using HTML and JavaScript) to more closely match the capabilities of native apps. Despite performance disadvantages and fragmentation across different browser versions, HTML5 has emerged as the most widely supported authoring technology for cross-platform apps. Cross-platform tools are taking HTML further than web browsers can, by allowing web developers to create native smartphone apps. In other words, CPTs are taking HTML5 much further by unifying the authoring side- rather than the runtime side – of the app across platforms.

Moreover, CPTs are paving the way for HTML5 to become not a platform, but the mainstream development technology for smartphone apps. Cross-platform tools are already triggering an influx of web developers; We found that 60% of CPT users, irrespective of their primary tool, have more than five years experience in web development. Indeed, cross-platform tools have triggered an influx of web developers into mobile.

Android and Windows Phone have been constantly evolving, adding hundreds of new APIs from each major version to the next. Due to the rapid advancement of platforms, tools vendors will always be one or two steps behind in terms of features and access to the complete set of device capabilities. Developers that create demanding applications like 3D games or apps requiring intense user interaction, exceptionally deep user experience, or apps relying on specific features not available on all platforms will need to be developed using the native SDK. Cross-platform tools will therefore be complementary to native SDKs.

Cross platform tools will become “business as usual”

As the platform landscape remains fragmented for the foreseeable future, cross-platform tools will become “business as usual” The future of mobile development is multi-platform – fewer and fewer developers will be able to afford to be confined to a single platform with the limited user reach and monetisation opportunities that implies. The adoption of cross-platform tools is driven by the ability to reach masses of users, which is the primary consideration for most developer segments. Cross-platform tools are indeed the only cost-effective vehicle for these developers to reach a wide mass of users, and we expect CPT usage to become commonplace a result.

Multi-screen and the evolving points of competition

At the onset of 2012, CPT developer selection criteria are heavily skewed towards the breadth of platforms supported by each tool. This picture will change considerably as cross-platform tools vendors advance their products to cover all the major mobile platforms. We expect that by mid-2013, the platforms covered by a CPT will move from a point of differentiation to a point of parity. In that timeframe, we expect the points of competition to move to later stages of the app lifecycle, with vendors offering component marketplaces, end-to-end workflow tools, device adaptation tools, app publishing services and post-download services.

In the sea of 100+ cross-platform tools, vendors are beginning to differentiate by targeting three distinct developer segments: those working on games, enterprise or media apps. Developers in these three segments face distinctly different challenges, work in distinctly different environments and as such need very different CPT solutions. As tool vendors try to survive in the “red ocean” of dozens of cross-platform tools, we expect CPTs to emerge for the financial sector, media publishers and the healthcare/medical sector.

Multi-screen is the next frontier. The battle of the software ecosystems is raging across many screens – mobile, tablet, PC and soon smart TV devices – and multi-screen will be the next frontier for cross-platform tools. Already in our survey, 27% of respondents noted that they also target Windows PC and 24% target Mac desktops with their main cross-platform tool. However, the complexities of cross-platform development in a multi-screen environment are growing exponentially and beyond the simple sharing of the code between multiple platforms. Different screen types have different interaction models, input methods, screen sizes, go-to-market channels and pricing models, while developers working on different screens have use varying tool-chains, development cycles and collaboration processes. With the proliferation of users who own more than one connect screen, the next frontier for cross-platform tools will be multi-screen.

Lessons to be learned

Cross platform tools have previously faced criticism, most notably from Steve Jobs in his infamous open letter “Thoughts on Flash”. The next generation of tools are however rapidly coming to market or maturing with abundant backing from the financial and developer community. The cross-platform tools market is in a state of abundant volatility and we see continual flux, as developers try a tool, and then churn to a different one. This is a market with no clear winners or losers. It’s a market where there is little developer loyalty, and perceptions are still being formed. Now is the time for well-funded vendors with great tools to prove themselves and establish a firm beachhead.

– Seth
Follow us on Twitter – @visionmobile

Download a copy of the report here.
Interested in raw data from the report? Drop us a note

The death of Flash – 8 years in the making

[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]

The Flash vs. HTML5 Endgame

[In the debate of Flash vs HTML5, has the death of Flash been over exaggerated? Guest author Guilhem Ensuque peeks through thick layers of hype and facts to predict what the future holds for the mobile web].

The last year has seen a flurry of announcements and debate around the rise of HTML5 and the fall of Flash. Some have even gone as far as declaring a “war” between the two, and predicting the “death” of Flash as the outcome. However, as Mark Twain once famously said: “The rumor of my death is an exaggeration”. As we’ll see, the jury is still out as far as the fate of Flash and Adobe are concerned.

A brief (abridged) history of the web
“HTML5” is the new high-tech industry darling, and not just in the mobile space. It has become a catch-all phrase with little meaning when taken out of context. Before we dig into the debate, it’s worth looking at what is HTML5 and where has it come from.

“HTML5” when used as a shorthand, covers of family of web technologies currently being standardised by the W3C and at various implementation stages by browser vendors. The “5” comes from the version increment in the W3C spec number: currently most of the content you read on the web conforms to the HTML specification version 4.01.

To understand what has driven the creation of this new version of web standards, we need to look at the evolution of the web in past years.

In the 1990s the World-Wide-Web emerged from academia to become the ubiquitous medium to share digital documents over Internet Protocol networks. The HTML4 spec was matured in that era, and has been very much geared towards read-only, document-oriented description and hyper-linking. HTML4 mixes typographical tags with document structure description, within the bounds of static pages and has limited support for script-driven page logic and forms (does anyone remember CGI?). In that era of the web, support for multimedia content was notably absent from the web specification; leading to heterogeneous plug-ins striving to provide video delivery in web pages (remember Real Networks? or having to choose the speed of your modem?).

In the 2000s, the web evolved towards more interactivity with the advent of the “Web 2.0” (yet another buzzword) and user-generated content, especially videos uploaded and then streamed over faster ADSL connections. However, the HTML spec did not fundamentally change (apart from an attempt by the W3C to migrate to the stricter XHTML syntax which has seen mixed results in terms of adoption). To cope with HTML4â€˜s inefficiencies in allowing designers and developers to create interactive “experiences” (i.e. not just documents, but bi-directional “applications” living in your web browser) a number of innovations were introduced :

JavaScript, Dynamic HTML and XML HTTP requests (a.k.a. AJAX) as a way to have thick-client app functionality in the browser, enabling users to interact with the web in a read-write fashion (not just read-only)
clear separation of page structure in HTML (through heavy use of <div> tags) as well as typoraphy and style in CSS (through an arcane and verbose syntax), leading to more pleasant user experience and richer page contents
PHP-scripted and database-powered back-end logic bolted on top web server systems. This e.g. allowed template-driven content management systems like WordPress and Joomla to rise to prominence, fueling the blog revolution.

These innovations brought the ability to present vast amounts of data in pretty-looking dynamic web pages which mash-in RSS feeds, emails, blogs, Facebook updates, and tweets, and bringing web pages a step closer to applications.

In that era, Flash (or rather the Flash Player) rose to become a ubiquitous browser plug-in for animated graphics and video. At the same time, Flash evolved to provide an out-of-browser Rich Internet Application platform with the AIR runtime and the Flex framework, albeit at a much lower penetration level than the in-browser Flash Player.

We are now at the dawn of the 2010s, and the overhaul of the HTML4 spec is long overdue. HTML5 aims to bring back into the core spec of the web the “side” developments of the previous era and improve on them with a heavy focus on web applications. It also aims to lay the foundations enabling the delivery of web content through a new medium: mobile devices, and ultimately the “Internet of Things”. That history is yet to be written, but we can now ponder about its beginnings and the future.

So, What is HTML5 Really ?
In the context of this new era, the “HTML5” shorthand refers to a family of web standards and browser technologies that span a range of topics:

A modernized web markup language: the true-and-only HTMLv5 specification and matching evolution in web browser capabilities. The new syntax includes the <canvas> tag allowing bitmap manipulation through JavaScript drawing APIs, better support for vector graphics authored in SVG, the <video> tag allowing streamed media playback as simply as embedding images and the streamlining of tag usage.
A richer styling language: the Cascaded Style Sheets v3 specifications. CSS3 is now famous for its ability to create rounded corners, but more importantly includes so-called “transforms” allowing graphical effects like moves, rotations, gradients, etc. as well as 3D graphical objects manipulations. Much effort as been put by browser vendor to support hardware acceleration for CSS3 rendering. However, the standard is not yet mature and today requires using prefixes specific to each browser.
Application-oriented advancements in the browser, as well as matching JavaScript APIs: the Web Workers offering background and concurrent execution capabilities; a Web Storage allowing simple local data storage and manipulation in XML; and a Web SQL Database providing the capability to perform SQL queries on large amounts of data stored locally and replicated from a server.
Mobile-oriented advancements (not yet finalised in the specs) including JavaScript APIs for Geolocation, Device and File APIs
Miscellaneous additions catering for the Semantic Web (microdata), security (cross-domain HTTP requests), and more.

To the above set of technologies standardised by the W3C we should add a domain that has sprung out of both proprietary or open-source efforts: high-performance JavaScript runtimes within browsers and JavaScript Application Frameworks. The latter extend the capabilities of the web, turning it into a full-blown client-side application platform much in the same way that UI and application frameworks like Qt or Gtk extend the “bare” Linux OS framebuffer. Such application frameworks include complementary JavaScript APIs, and rely on CSS3 to provide extensive sets of UI controls. Some mobile-specific frameworks (like Phonegap or BONDI, an offspring of the mobile operator community) go as far as providing additional device APIs for smartphone features like messaging or camera, while others provide a rich set of UI controls mimicking the native platform look & feel (more on this later).

Why the clash with Flash ?
There’s no denying that the capabilities brought forward by the emergence of the HTML5 “family” bring browser runtimes on a par with core capabilities of the Flash Player, which if adopted widely could make Flash redundant.

In the eyes of most mobile industry observers, the delays in bringing out a fully-featured Flash Player with acceptable performance on smartphones have played in favour of HTML5. Remember that, as of today, Flash Player v10.1 is only available for high-end smartphones that run the Android version 2.2 operating system. I would estimate that these represent only 1% of the overall smartphone shipments in Q2. This is a far shot from Adobe’s self proclaimed goal of having Flash shipping on 50% of smartphones by 2012 (see my previous article on this topic).

Figure: Smartphone Operating Systems – Q2 2010 Shipments share (source: Gartner, Google)

Company	Browser / OS	HTML5 compliance
Nokia	Symbian S60 5th Ed.	7%
RIM	Blackberry v5	0%
RIM	Blackberry v6 (Torch)*	69%
Google	Android v2.1*	50%
Google	Android v2.2*	59%
Apple	Safari for iPhone (iOS 4.0)*	62%
Microsoft	IE Mobile (Winmob 6.5)	0%
Opera	Opera Mini (on iPhone)	9%

Figure: HTML5 compliance of mobile browsers
[some notes on the methodology: HTML5 compliance was carried out using html5test.com. (*) denotes a WebKit-based browser. The Nokia Symbian S60 browser, albeit based on an old version of WebKit, scores poorly in HTML5 compliance tests. I could not test Mozilla Fennec, Palm’s WebOS browser, nor Opera Mobile.Opera Mini is a special case due to server-side rendering.]

Making things worse, Apple has stayed firm on its policy to not allow the Flash Player browser plugin on its iOS devices (iPhone, iPad and iPod Touch), preferring to rely on its in-house video streaming capabilities developed within its HTML5-capable WebKit browser core and QuickTime player. And to make things even more complicated, Steve Jobs’ “Thoughts on Flash” have played a key role in fanning the flames of the “Flash is dead, long live HTML5” fire.

Moreover, Google’s Android, Palm’s WebOS and, more recently, RIM’s Blackberry also embed web browsers based on WebKit that score very high in terms of HTML5 compliance, as can be seen in the table above.

Thanks to WebKit, half of the smartphones being shipped are poised to have the Flash-like capabilities brought by “HTML5” built into their browsers. However, let’s not rush in declaring Flash “dead” and Adobe a company in decline as a result.

Does HTML5 matter to Adobe ?
HTML5 is actually good for Adobe’s business. Indeed most of Adobe’s revenues do not come from Flash as can be seen by breaking down the Flash product portfolio::

The Flash Professional tool, is the authoring software for creating Flash content. It ships standalone or within the Creative Suite bundle. This is where Adobe makes its money as can be seen from the “Creative Solutions” BU share of the chart on the side (courtesy of Business Insider’s “Chart of the Day” series). Creative Suite also includes the massively popular Dreamweaver web design tool, and Illustrator, a vector graphics design tool, both of which which are now starting to incorporate HTML5/CSS3 design capabilities. Adobe has also hinted that Dreamweaver will be able to convert Flash timeline animations to Javascript/CSS3 code to render those animations in “HTML5” compliant browsers. This means that “HTML5” will not be a threat to Adobe’s main source of revenue. On the contrary, since there are few good commercial web design tools, the rise of “HTML5” will spur demand for Adobe products.
The Flash Player: the plug-in is free and is therefore represents an R&D cost for Adobe. No impact there. One might argue that, if HTML5 were to totally eliminate the need for the Flash Player, it would the positively impact Adobe’s bottom line in the unlikely event the company were to lay off the entire Flash Player team 🙂
The Flash “Platform”: “auxiliary” products that rely on the Flash Player include the Flash Media Server and Flash Access product ranges, licensed to organisations that use Flash to deliver streamed video content (e.g. Hulu, Influxis, Brightcove). The “Platform” also includes the commercial Flash Builder IDE allowing the development of Rich Internet Applications (and the associated free and open-source Flex framework). As can be seen in the chart, these represent a minute proportion of Adobe’s revenue. As we will see further down, these products are not going to disappear overnight due to the emergence of HTML5.

However, HTML5 does put competitive pressure on the product management and engineering teams responsible for the Flash Player to out-innovate the evolutions in browser technology. Adobe points out that this is “business as usual for them” as –they say- it was never their intention to fully replace the browser altogether, but rather complement its capabilities with innovative features, and harmonise areas in which standards have been implemented in an inconsistent fashion across browser runtimes.

As an engineering-driven company, Adobe aims for Flash to stay one step ahead of HTML5 technology implementations, as it already is today in numerous areas. Indeed, an agile R&D division within a single corporate entity will always be faster than a “snail driven by a committee” as the W3C HTML5 spec bodies have been dubbed by some.

Some areas where Adobe is pushing the envelope for the Flash Player include 3D rendering with hardware acceleration, concurrency support, IP TVs and peer-to-peer media delivery. The latter is an interesting transposition of the file-sharing P2P concept; imagine tens of millions of users watching the same live video coverage of the opening ceremony of the 2012 Olympics in London. No server farm or CDN today is capable of sustaining such a peak demand. By allowing instances of the Flash Player across millions of peers to share chunks of the video stream at the edge of the network could be the answer to the problem.

Beyond innovation, another aspect to factor in is that HTML5 is still in its early stages of implementation across browsers, with Microsoft’s uber-popular Internet Explorer browser today lacking any form of HTML5 support whilst representing close to 60% of the web user base (see chart below). Even with the IE9 beta improving HTML5 support and other browsers consistently gaining market share it will still take some years before HTML5-capable desktop browsers dominate the installed base. This will justify the existence of Flash in the desktop browser space for years to come and give some leeway to Adobe’s engineering teams in designing more innovative capabilities.

Company	Browser	HTML5 compliance
Microsoft	Internet Explorer 9 beta	32%
Microsoft	Internet Explorer 8	9%
Microsoft	Internet Explorer 7	4%
Microsoft	Internet Explorer 6	0%
Mozilla	Firefox 4 beta 5	68%
Mozilla	Firefox 3.6	46%
Mozilla	Firefox 3.5	42%
Google	Chrome v6	72%
Apple	Safari v5	69%
Opera	Opera browser v10	53%

Figure: Desktop web browsers users share and level of HTML5 compliance
(sources: wikipedia and test conducted with https://www.html5test.com)

Reality check: comparing Flash and HTML5 in key areas
So how is Flash vs HTML5 faring today? For review purposes we can single-out a few key areas of Flash and HTML5 competition, specifically display advertising, video delivery, games and application development.

Display Advertising: a slight advantage for Flash
One of the main use cases for Flash (and big source of annoyance to web users) is display advertising. “Display” adverts are animated banners that appear at the top, side or overlaid in front of the web content you. As annoying as they may be, display ads are a necessary evil for the online world since they represent 40% of the revenues that the digital content and e-commerce ecosystems live on. Even Google uses Flash in its DoubleClick Studio rich advert SDK for advertisers.

Some have said that because HTML5 will kill Flash, those annoying ads will disappear. I would rather think that they may be replaced by equivalents designed in HTML5/CSS3, with the caveat that they may look crappier in most of today’s browsers than their Flash counterparts, as can be seen from these examples.

Indeed a point often overlooked is that today’s HTML5 graphical rendering capabilities are at the level of what Flash capabilities were some years ago and CSS3 transforms allowing to design good “eye-candy” are inconsistently supported across browsers. Therefore I would argue that advertisers will hold back from using “HTML5” for display ad creation in the medium term. The lack of proper HTML5/CSS design tools will also delay this technology adoption by design agencies and creative professionals especially within industry circles where Flash is deeply entrenched.

On mobile devices, the situation will be no different. The blue legos now seen on iPad and iPhones may soon be replaced by HTML5 counterparts; or even by iAds. However, as of today, Apple is the only company creating iAds (in the process levying a hefty ad tax) and is reported to be struggling with the demands of advertisers with its in-house HTML5-based ad creation tools and technologies.

Video Delivery: advantage for Flash
Another area in which “HTML5” has been touted a “Flash killer” is online video delivery. Let’s have a look. As far as basic video playback is concerned, Flash and HTML5’s <video> tag provide the same capabilities, so why not ditch Flash and avoid to end users the (relatively minimal) hassle of installing a plugin?

The situation is not as simple as it sounds as the various browser vendors do not yet all support the same video codecs. On one side, Apple and Microsoft are proponents of H.264; Google is pushing its opensource WebM codec (formerly the proprietary VP8 codec that it inherited through the acquisition of On2/Sorenson); and Mozilla and Opera by default supporting the free and opensource Ogg Theora.

This poses a challenge to online video publishers like YouTube since they then have to re-encode their content multiple times to support each codec.

To end users, this means that videos may not be available in the format supported by their browser. Flash on the other hand, even though it requires videos to be packaged in the FLV container format (not to be confused with encodings like H.264), is available across all desktop browsers and is used as a reliable fallback by “HTML5” web developers i.e. for the 50% or so of IE end-users whose browser can’t render the <video> tag.

Furthermore, the Flash Player supports advanced capabilities required by online publishers such as DRM protection (crucial for pay-per-view business models) and picture-in-picture overlay of multiple video sources with alpha-blending (e.g. for e-learning or overlay of contextual adverts). These capabilities may not be offered for years with the <video> tag in HTML5 browsers.

Casual Games and Visualizations
Flash is the technology that powers some massively popular “casual games” (such as Zynga‘s Farmville or Mafia Wars) played by millions of Facebook users worldwide. It also powers numerous other Facebook applications. There was earlier this year a rumor that Zynga was converting its titles to HTML5 to be able to run on the iPhone and iPad. This turned out not to be true, as it announced at Apple’s WWDC that it had ported Farmville to the iPhone as a native app; which may be interpreted as a sign that “HTML5” was not up to the task.

Another area in which today Flash is massively popular is that of visualizations and generative art. There is a large and enthusiastic community that has turned Flash animation into a true art form. Artists like Erik Natzke or Yugo Nakamura (of the Tha agency) are prominent examples of this community. To date, I have not seen any such artistic usage of “HTML5” technologies.

Other “HTML5” demos that have received a lot of media attention are Google’s “bubbles” doodle earlier this month, its experiment with Arcade Fire or a port of Quake to JavaScript using GWT. However, I do not yet see casual games developers or visualization artists migrating “en masse” away from Flash. This may be explained by the fact that those experiments in “HTML5” remain CPU-intensive and RAM-hungry (more than Flash in most cases), while designer-grade tools are lacking, and the fragmentation between browsers makes Flash a lot more dependable.

Applications Development: a draw
Web app development is another technology domain where the HTML5 family of technologies has been contending with Flash.

We have seen earlier that “HTML5” provides most core capabilities needed to run local applications, including code execution, storage and access to the screen. These core capabilities are now complemented by a flurry of web application frameworks that rely on JavaScript / CSS: DoJo, JQuery, MooTools and Sproutcore, to name a few. Google’s Web Toolkit (GWT) represents a particular case since it is a framework + tools package that allows to code a web application in Java and convert it to JavaScript for execution in the browsers (note how Gmail, Buzzz and other Google apps are built with GWT).

More recently, these frameworks have been forked into mobile variants: JQuery Mobile, Sproutcore Touch and Sencha Touch. Sendra is actually a case in point: the developer company raised $14 million in venture capital, a testament to the significant size of the business opportunity, and has jokingly proclaimed “The End Of Native” (see photo).

This abundance of JavaScript frameworks may be encouraging, but also represents a dizzying array of choices for the developer. This diversity limits the degree of industry-wide code reusability and fragments the pool of Javascript app developers into vertical niches.

This diversity further plays in favour of Adobe’s own web applications platform AIR (a sibling to the Flash Player) and the associated Flex framework, which uses the Actionscript programming language and allows XML-driven UI design through its MXML language.

In my own experience, seasoned developers find ActionScript and MXML a much better programming paradigm than Javascript frameworks in most developer aspects; code reuse, team productivity, tools support, debugging and ease of UI design.

In conclusion, the momentum behind web applications thanks to “HTML5”’s core capabilities and associated frameworks may seem unstopable, especially as it is driven by technology behemoths like Google and a large enthusiastic community. However this optimism is mitigated by the lack of developer productivity and the rising popularity of Adobe’s application development technologies.

What of the Future ?
Based on the earlier analysis, Flash is far from dead today. There are many cases in which Flash will continue to offer a better alternative (worst case a very useful fallback) to “HTML5” technologies due to the fragmentation in new web standards browser support.

To the question : “will HTML5 kill Flash?” there is no single answer. It all depends on which use case is considered and in what timescale.

On the desktop front, it is the lack of HTML5 capabilities in IE8/9 and their immaturity in all other browsers, that will secure the future of Flash in the medium term. At the same time, Adobe is under pressure from Microsoft, Google and Apple who are betting huge R&D budgets in the development of HTML5-capable browsers and who should be able to out-innovate Adobe in the longer term.

On mobile, the Flash Player is still in its infancy, while WebKit-based browsers are sharply rising towards ubiquity (250 million and counting as of end 2009). This gives the “HTML5 camp” an edge today, especially in the area of basic video playback and mobile web applications for which numerous JavaScript/CSS3 mobile frameworks are available. Looking forward however, Flash may still better HTML5 on mobile for use cases like casual games and animated graphics given its greater dependability and its widespread usage today in those communities.

Where would you place *your* bet?

– Guilhem

[Guilhem Ensuque is Director of Product Marketing at OpenPlug. He has more than twelve years of experience in the areas of mobile software and mobile telecoms. Guilhem was a speaker at last year’s Adobe MAX conference. His favorite pastimes (beyond mobile software strategy!) include making his baby daughter smile and sailing his Hobie Cat with his girlfriend. You should follow Guilhem on twitter @gensuque_op]

Breaking the 500 million barrier of mobile software

[Which are the most ubiquitous mobile software products out there? Marketing Manager Matos Kapetanakis opens up our 5^th edition of the 100 Million Club, the watchlist of embedded software products and talks about the really big numbers of mobile software.]

Welcome to the H2 2009 edition of the 100 Million Club, the semi-annual watchlist of mobile software products that have been embedded in more than 100 million mobile devices since their release. Despite the apparent opportunity in the one-billion-a-year handset market, very few software companies have managed to overcome the commercial and technical challenges inherent in the mobile industry.

Key highlights in this H2 2009 edition:

– “The cumulative number of shipments of all the 100 Million Club software products up to the end of 2009 is 24.6 billion – an 11% increase since the previous half”

– “The estimated 250 million cumulative shipments for Apple’s WebKit show that it is fast becoming a de facto browser platform.”

– “BlackBerry is the next smartphone platform, after Symbian, that will break through the 100 million shipments barrier.”

What’s new in H2 2009?
So, what major changes have we seen since our previous update?

First off we’re happy to welcome three new entrants to the Club: ARM, Mimer and Numonyx have joined, adding three new middleware products to our watchlist. Mimer has just broken the 100 million barrier with its SQL database engine, while ARM brings us Mali-JSR184, a 3D graphics engine for wireless devices. The Flash Data Integrator by Numonyx is already ahead of the game, having been shipped in more than 900 million devices.

We have also had to remove three software products that have long been part of the Club. For different reasons, Mobile BAE by Beatnik and Picsel’s File Viewer are no longer part of the 100 Million Club, while Nokia’s Series 60 OS has been incorporated in the Symbian OS.

(click to download)

Growth in the 100 Million Club
The H2 2009 edition of the 100 Million Club is comprised of 30 software products by 26 companies. The total number of shipments of all 30 products, up to the end of 2009, comes to 24.6 billion – an 11% increase since the previous half.

In the previous edition, the Club featured 15 software products that exceeded 500 million shipments, 6 of which had also broken through the 1 billion barrier. The H2 2009 edition features 17 products with more than 500 million sales, 7 of which have surpassed 1 billion shipments. In other words, for the first time the majority of the products featured in the 100 Million Club have over 500 million shipments.

In the second half of 2009, CAPS by Scalado and OKL4 by Open Kernel Labs managed to break through the 500 million barrier, while Myriad Group’s messaging client and Nokia’s Series 40 OS now have more than 1 billion shipments each.

Category leaders: apps, browsers, middleware and operating systems
Quickoffice wins by default in the embedded applications category, since it’s the only embedded application featured in the 100 Million Club.

Adobe is still number one in the application environments category, with Flash/Flash Lite having been embedded in more than 1.3 billion devices up to the end of 2009. The growth of Flash Lite has decelerated significantly from 43% (1H09) to 15% (2H09) as share of devices sold with the software embedded; however the pace should be picking up pace again with Flash shipments later in 2010.

Myriad Group, whose browser has almost twice as many shipments as the other category products combined, dominates the browser market.

In the middleware category things are not that clear, due to the diversity of products. In absolute numbers, the messaging client by Myriad Group has the most shipments (1.2B) and vRapid Mobile by Red Bend shows the highest of growth over the second half of 2009. UI software is also highly penetrated within mobile devices, led by graphics engines by Ikivo, Scalado and The Astonishing Tribe which are at or around the 500 million mark.

The operating system market features 6 products that have been embedded in more than 1 billion devices. It’s worth noting that mass-appeal operating systems like OSE, Nucleus and recently Series 40 have cumulative shipments numbering in the billions, while BREW has just broken past the 500 million mark. In contrast, most major smartphone platforms – Android, OSX, Windows Mobile, BlackBerry – apart from Symbian have yet to reach 100 million shipments.

Finally, the input engines category features two products, both by Nuance inherited from the past acquisitions of Tegic and Zi Corp. As is evident in the chart, T9/XT9 is by far the most prominent, having been embedded in a staggering 4.8 billion mobile devices up to the end of the second half of 2009.

100 Million Club facts and trends

Two companies account for 38% of shipments: Only two companies have multiple software products included in the 100 Million Club, each company featuring three products. The cumulative number of shipments of these two companies is 9.5 billion, representing 38% of all 100 Million Club products’ shipments up to the end of H2 2009. The software products are Myriad Group’s Browser, messaging client and Jbed and Nuance’s T9/XT9, eZiText and VSuite.

WebKit on the rise: We estimate that up to the end of 2009 WebKit, the open source browser engine, has been embedded in more than 250 million devices. WebKit owes most of its market penetration to Nokia (Symbian shipments with the Series 40 contribution picking up), while its recent adoption by RIM can only accelerate its market penetration.

Top revenue models: In this edition, we asked the 100 Million Club members to provide us with the top two revenue models for their products. The responses revealed that the most common revenue models for embedded software are per-unit royalties,followed by NRE (non-recurring engineering fees) for product integration or customisation. Despite the tight profit margins, handset OEMs and network operators are still paying for software on a per-unit basis, with the â€˜paradigm shift’ to per-active user revenue models taking longer than most would have expected.

What’s in stock for the 100 Million Club
Our watchlist continues to grow, as more products make it past 100 million shipments. Blackberry should be entering the Club in the next edition (H1 2010), with OSX, Windows Mobile and the much younger Android lagging a further 6-18 months behind.

The bigger picture of mobile software is very different than the industry hype would have us think.

– Matos

Adobe defends its mobile strategy

[Is Adobe’s mobile strategy doomed? Mark Doherty guest author and Platform Evangelist for Mobile and Devices at Adobe responds to the recent criticism and argues that the best is yet to come]

The Big Picture
Adobe’s vision – to revolutionize how the world engages with ideas and information – is as old as Adobe itself, in fact 28 years ago the company was founded on technologies like PostScript and later PDF that enabled the birth of desktop publishing across platforms.

Today Flash is used for the 70% of online gaming and 75% of video; driving innovation on the web for over a decade. Flash Player’s decade long growth can be attributed to three factors:

Adobe customers such as BBC, Disney, EPIX, NBC, SAP and Morgan Stanley can create the most expressive web and desktop applications using industry leading tools.
The Flash Player enables unparalleled cross platform consistency, distribution and media delivery for consumers on the desktop (and increasingly on mobile)
A huge creative community of designers, developers, illustrators are involved in defining Flash, and hence driving the web forward.

Now, as consumers diversify their access to the web they are demanding the same experiences irrespective of the device. Content providers and OEMs across industries recognize this trend and are delivering Flash Player and AIR as complimentary web technologies to extend their vertical propositions. The process of actually delivering this is not trivial, and was made more complex by a failing global economy, but we are on schedule and the customer always wins.

Where we ‘ve been
The success of Flash on mobile phones has been second to only Java in terms of market penetration, but second to none in terms of consistency. According to Strategy Analytics, Flash has been shipped on over 1.2 Billion devices, making it the most consistent platform available on any device.

Adobe announced in 2008 a new strategy for reseeding the market with a standardised Flash single runtime, creating the Open Screen Project, an alliance of mobile industry partners to help push this new vision. So why the change of plan?

In the historically closed, or “wild west” that is the mobile ecosystem, web content providers and developers have found it too difficult to reach mobile devices. In practical terms, it was too difficult for the global Flash community to reach consumers, and to do that in a manner consistent with the consumer reach of desktop content. Japan has been the most successful region because of deep involvement from NTT DoCoMo and Softbank, and by enabling the use of consistent web distribution.

That said, agencies such as Smashing Ideas, ustwo and CELL (sorry to those I’m missing out) have established valuable businesses in this space by building strong partnerships with OEMs.

On the top end of this success scale, Forbes recently announced Yoshikazu Tanaka has become the first Flash Billionaire with the incredibly successful Flash Lite games portal Gree in Japan. (Gree is a “web service”, not desktop or mobile, and is indicative of what can be achieved using Flash as a purely horizontal technology across devices)

In all, our distribution and scaling plans worked very well for Adobe, but outside Japan the mobile “walled gardens”, and the web on devices today, didn’t work for our customers. The cost of doing business with multiple carriers in North America and Europe and the lack of web distribution to a common runtime left our customers with few choices. It was time for a new plan.

Open Screen Project
Delivering on the Open Screen Project vision at global scale with 70 partners is a huge task; it was always going to take about two years. We are very much on schedule with Flash Player 10.1 and AIR, although eager to see it rollout.

However, describing the goals of the Open Screen Project in terms of dates, forecast market share, Apple’s phone or their upcoming tablet, specific chipsets or Nokia hardware is to miss the whole point. The Open Screen Project is not a “mobile” solution; it’s about the global content ecosystem.

In summary – connecting millions of our developers and designers with consumers via a mix of marketplaces and the open web.

Google and Microsoft are great examples of companies that have competitive technologies and services, but both companies still use Flash today to reach consumers. Google use Flash for Maps, Finance and youtube, and Microsoft for MSN Video and advertising. So indeed we have a co-opetition between Silverlight and Flash, or Omniture and Google Analytics, but together our goal is to enable consumers to browse more of the web on Android, Windows Phone and other devices in the future.

Today, over 170 major content providers (including Google) are working with us right now to optimize their HTML and Flash applications for these mobile devices. In the coming months we’ll begin the long roll out process, updating firmware, enabling Flash Player downloads on OEM marketplaces. We’re projecting that by 2012, 53% of smartphones will have Flash Player installed.

It’s really exciting to see it coming together and so many big names involved, why not have a peek behind the curtain?

Flex Mobile Framework
To enable the creation of cross-platform applications even simpler Adobe is working on the Flex Mobile Framework. Essentially we have taken all the best elements of the open source Flex 4 framework and optimized it for mobile phones.

Using the framework and components you will be able to create applications that can automatically adapt to orientation and layout correctly on different screens. The most important addition is that the Flex Mobile Framework “understands” different UI paradigms across platforms. For example, the iPhone doesn’t have a hard back button and so the Navigation bar component will present a soft back button on that platform.

In terms of developer workflow we expect that all background logic of applications will run unchanged. User interfaces and high-bitrate video will need some adjustments for some hardware, though most changes will be basic changes like bigger buttons, higher compression videos and to adapt HTML for mobile browsers.

Over time with the Flex Mobile Framework, our goal is to enable our customers to create their applications within a single code base, applying some tweaks for each platform for things like Lists, Buttons or transitions. In this sense we can expect to enable the creation of applications and experiences that are mobile centric, and yet cost effective by avoiding fragmented solutions where appropriate.

We are aiming to show the Flex Mobile Framework later in the year, and I’d love to see it supported in Catalyst in the future.

The Year Ahead
Throughout 2010 we will see Flash Player 10.1 on Palm’s WebOS, Android 2.x, with Symbian OS and Windows Phone 7 coming in the future. In addition to that we also have plans to bring Flash Player 10.1 to Blackberry devices, netbooks, tablets and of course the desktop. For less powerful feature phones we’ve got Flash Lite, and all of these platforms will demonstrate Flash living happily with HTML5 where it’s available.

Adobe AIR 2 is also in beta right now, enabling users to create cross-platform applications that live outside the browser on Windows, Mac and Linux computers. AIR is of course mobile ready, and later in the year we’ll be bringing AIR to Android phones, netbooks and tablets. On top of that, you will also be able to repackage your AIR applications for the iPhone with Flash Professional CS5 very soon.

The rollout and scale of Flash Player and AIR distribution over time are now inevitable, and largely committed over a year ago.

There are risks of course; these ecosystems are moving targets just like they have always been. However, I’m extremely confident that we can build upon our previous successes, learn from our mistakes and innovate faster than any of our competitors.

– Mark Doherty
Platform Evangelist for Mobile and Devices at Adobe