The work of the OSP

Great interview at EffectiveUI from Doug Schmidt (of Dryerfox fame 😉 as Adobe’s Anup Murarka discusses the goals and progress of the Open Screen Project.

It’s a long interview — printed out for me at 13 pages — and seems to have flown beneath-the-radar since published two weeks ago. I’m remixing some of the highlights topically below, but I’d urge you to read the original conversation too… OSP is an ambitious yet convincing proposal to gain the ability to write to any display, and I think this interview will help you predict the shape of the next few years.

What are the goals of the Open Screen Project? To make it both practical and economical to deploy to any digital screen.

We’ve centered on two key goals. First is the development and distribution of a consistent runtime that’s available across all sorts of screens, not just the desktop, but also mobile, television, set-top, and other consumer electronic products.

Second, is the notion that it needs to be easier to publish and distribute content to those screens, not just from a technology perspective, but also from the business relationship perspective. Too often, Adobe hears horror stories from developers about how hard it is to get their content to a mobile phone or to a television. Companies in the Open Screen Project would like to see that become easier.

… The Open Screen Project is really more about allowing developers a much greater level of flexibility to design and move assets from one screen to another without having to rebuild applications every time.

We’ve got to improve, not just the technical capabilities, but also the business realities. That’s why such a diverse partner list is needed:

When the Project was originally announced, we had companies from all segments of technology ecosystems participating. We have companies at the silicon layer actively participating — organizations like Intel and ARM. We also have OEMs, including all of the top five mobile OEMs: Nokia, Samsung, Motorola, LG, Sony Ericsson, and also companies from other industry segments that build other a wide range of consumer products — like Cisco and Toshiba.

We have service providers NTT DoCoMo, Verizon Wireless, and Comcast who most recently joined the effort, as well as major studios, content producers, and media brands including NBC Universal, MTV Networks, a division of Viacom, and others. We see the Open Screen Project as a very broad industry collaborative effort rather than just something that is applicable only to software companies… Since the original public announcement, we reached a very significant milestone in seeing some additional companies join the effort.

Why is such a diverse consortium of stakeholders so necessary? Examples here from service providers and hardware manufacturers:

One of the key Open Screen Project goals is to allow for over-the-air and over-the-wire updating of the core run time, just as we allow for that on the desktop now with Flash Player. If we can make that a seamless process and as easy to use as it is on the desktop, we think developers will get really excited and they’ll be able to do even more wonderfully creative things.

That’s why it was essential to have service providers participate in the project from the start — to help guide how we would do this successfully. The idea of tens of millions of wireless subscribers suddenly doing simultaneous downloads over a network is frightening. Consumers can undoubtedly overwhelm the network. So it’s something that has to be done carefully, and again, that’s why we wanted to make sure that we had partners in the project that could educate us on what the risks and struggles will be.

… One of the most complex problems we’re seeing right now is getting ActionScript 3 running in low-end, mass-market devices. It’s not easy. We’d love developer participation there. It’s going to require a lot of energy. We’ve had a number of the Open Screen Project partners participating in that — companies like ARM, Intel, and Qualcomm — working on getting a well-performing, just-in-time compiler working on current and future processors. There’s a lot of juicy work to be done in that regard…

One example is the announcement we made with ARM stating that Adobe is working with ARM directly to optimize Flash Player 10 for playback on processors. So much of the early engineering work is happening at the very low hardware levels in order to take advantage of hardware acceleration. ARM has made key contributions to the Tamarin project by getting the just-in-time compiler working with ARM processors instead of just desktop X86 processors. These optimizations are for core Flash Player 10 and Adobe AIR.

Adobe’s motivations and business goals?

As we shipped millions of units of Flash Player onto various mobile phones, we didn’t see real global success in terms of broad amounts of content being available everywhere. We saw many little ecosystems, smaller silos that made it challenging for Flash developers to see their content become globally available. If you look at the way Flash content has grown on the desktop and the Web, comparing that to growth outside of the desktop, it has been slow to develop.

We’d like to accelerate that. We’ve certainly played a role to some extent for mobile, particularly in Japan, in parts of the U.S., and parts of Europe. But we’d like to see mobile become a more consistent environment that developers can take greater advantage of.

… We don’t want designers to worry if Flash Player 10 on devices shipping now will work on devices that ship three years from now. I think this is a key aspect of what we’ve heard from Flash Lite developers over the last several years.

… We see consumers demanding greater access to the content they enjoy and the services they want. Rather than forcing developers to learn a completely new set of APIs, a completely new set of capabilities, we think if they have a common tool set, and a common language to deliver those applications and services, they’re much more likely to make them consistent and make them available on a wide range of screens so that experiences can move with users and not be dependent on a desktop in any one location.

Again, our goal is to make Flash more open and more appealing to developers around the world. That represents a significant step to allow for new innovation and for faster development to happen.

What about commitments and progress?

We’ve made some significant commitments to the Open Screen Project, as well as financial commitments by agreeing to waive the royalty fees, for example, for device-based implementations of Flash Player technology.

… We published the first round of specifications and details for development, as well as a schedule for releases that would be ‘Open Screen Project compatible.’ These future releases of Flash and Adobe AIR will really move the the Project’s goals forward.

… We’ve also published Flash information, including Flash technology specifications. We’ve made available various protocols over the course of the last year, such as the FlashCast client server protocol. The goal for that portion of the effort was to ensure that companies didn’t feel locked into some other piece of Adobe technology just because they wanted access to this runtime. Our other products and solutions, tools, and server services will compete on their own merits and not just because there’s any sort of proprietary lock-in to the Flash Player runtime.

… One of the exciting elements of dealing with ActionScript 3 is the fact that the Tamarin Project and Tamarin-tracing have been created as open source projects of the Mozilla Foundation. The Tamarin project is incredibly essential to making this effort one that’s going to truly be multi-screen.

Specifications, roadmaps, timelines?

For the desktop, nothing really changes. For smart phones, we think the specs are somewhere in the 300 to 400 MHz processor range — the really high end of the smartphone category for now. That means devices like the G1 or the iPhone, or some of the higher end series 60 devices are the best — basically the PDA class of devices.

The lower-end smartphones and mass-market phones won’t get all of the same desktop compatibility that we’re offering. They’ll miss some of the class libraries or actual APIs, but the core runtime will be identical. It will be better than what you have with Flash Lite today, but still not 100 percent equal to the desktop.

We think the profile is going to be somewhere in the 300 MHz range for the device processor on, let’s say, a quarter VGA, half VGA screen. We’re also targeting a similar footprint for set top boxes and mass-market TVs, although with some hardware acceleration.

… Schmidt: Did you say that you foresee the first Open Screen Project devices coming to the market in Q4 of 2009?

Murarka: That’s our hope, and things look like they’re on track for that. But ultimately it’s in the OEM and service providers’ control. So I think that’s certainly the target that we’re all trying to work towards, but I would expect the volume of the products to be available in 2010.

What’s the general strategy for developing atop common runtimes spanning diverse device types?

Today, Flash Lite developers have to consider the specific device and the specific operator, and what version of Flash Lite is in use. Our hope is that all these Open Screen Project devices will be able to support a consistent ActionScript environment and a consistent Flash environment. Yes, the physical differences of the device will still be there. Is there going to be a keyboard, is there going to be a mouse, is the screen resolution going to be HD resolution or is it going to be a quarter VGA on a small phone? Designers have to worry about those things even today on the desktop, although not quite as extensively.

We want to simplify the language constructs, we want to simplify the class libraries, we want to make sure that the same authoring tool is in play — and ideally even the same Flex framework and SDK in the future.

But today, many of the richer tool sets that are available to desktop developers are not available to Flash Lite developers. We think that’s a big obstacle to overcome — one that will help simplify the development process for all different screens.

… One of the biggest challenges that developers have described to us is trying to keep track of all the many different devices, and all the different implementations of software on them… The idea of testing everywhere is cumbersome, it’s expensive, and Device Central is a great way to help mitigate some of that cost in time and money. We expect that to continue; Device Central is going to be just as useful as it was before to help designers get a feel for what’s available across devices, but the big steps are really to try to close the gap.

The core focus is on the “big three” screens (laptop, mobile, television), but the principles and capabilities should also extend to any upcoming types of Internet-enabled digital display:

Adobe Flash technology has been used in such a wide range of devices — from digital signage to ATM machines, to toys to informational gadgets, and developer platforms like the Chumby. There is broad adoption of Flash across devices, but it has not reached the penetration and mass-market consumer awareness that televisions, phones, and desktop computers have.

We talk about those three categories most because they are the three largest consumer products categories, but the technology evolution we’re undertaking should benefit other industries and other segments over time. So you can imagine car navigation systems utilizing some of the same benefits that we’re working on for these other three categories of desktops, mobile, and television.

Just as PostScript made it easy to publish to any printer, Flash must make it easy to publish to any screen. I’ve been waiting for this convergence a long time, and the strength and diversity of its ecosystem makes the Open Screen Project look capable of realizing this goal. Nothing’s shipping yet, but if you want to better predict where we’re going, then Doug’s interview of Anup offers a very good return on investment.

Comments are closed.