When Google introduced word processing and spreadsheet programs that work through the browser, the move was seen as one more step in the demise of the traditional desktop application. To which the folks at Adobe say: “⁠not so fast.⁠”⁠ With Apollo, a free-of-charge runtime environment available later this year, the company is arguing that desktop applications created with Web development tools may be preferable to their browser equivalents.

Like Java which came before, Apollo is a “⁠runtime⁠”? a virtual machine upon which developers can write desktop applications once, then run it without modification across Windows, Mac and Linux platforms. The difference is in who those developers are. Adobe wants to tap the skills of Web developers, especially those who use Adobe development products like Flash and Flex, of course, but also JavaScript and other Ajax-related technologies. As online applications have become more desktop-like, Adobe thinks Web developers might as well go the rest of the way and create actual desktop applications.

To learn more about Apollo, I spoke with Mike Downey, the runtime’s senior product manager for Apollo. Downey joined Macromedia in 2000, well before Adobe bought the company in late 2005, and was already well known among Web developers as senior product manager for Flash. Downey’s blog can be found at http://weblogs.macromedia.com/md/. We spoke just ahead of Adobe announcing the first public alpha version of Apollo. The SDK [software development kit] provides a set of command line tools for developing and working with Apollo applications.

Google has put office tools like spreadsheets online. You seem to be going in the opposite direction, putting online applications on the desktop.

There is something cyclical here. Thin client, browser-based applications put your content, your brand, and over time, your application within reach of more people. With more and more content moving to the Web, there has been a need for richer functionality, richer experiences and much deeper functionality. That’s why you’ve seen the emergence of rich Internet applications. These apps have a very desktop-like interface that is delivered through the browser, created using technologies like our Flex technologies.

And I also associate RIAs with Ajax technologies.

Yes, you get that with Ajax applications as well. But it’s not that people are trying to move things into the browser, per se. Rather, they are trying to reach more people with richer functionality, and the browser is the way for them to do that.

These browser-based applications are something that we at Macromedia started pushing five or six years ago when we coined the term “⁠rich Internet application⁠”⁠ or RIA, meaning rich applications on the Web. There has been a huge explosion of RIAs, and we’re one of the biggest drivers of that. We’re investing in making Flex the best technology for rapidly building very complex, Web-based applications.

But what’s the next step in this process? We’re seeing that more companies who want to deliver richer functionality are starting to hit the limitations of the browser. These companies are already building Ajax applications. They are already building Flash applications. Now they want to take the work they have already done and go beyond the browser. So that’s where Apollo fits in.

You’re saying that people who build RIAs have different skills than people who are building strictly for the desktop.

Absolutely. There’s no question about it. There are four million Web developers. And there are such rich resources for them to access as well as resource sites on the Web--all these ways for a Web developer to get information on how to build better apps. That’s why so many companies and independent developers are creating really great applications. The companies that are building these kinds of apps are, as a whole, employing people with Web technology skills. They know HTML and JavaScript and Flash and ActionScript. So they are making these investments, building code libraries. And they are already building the apps. So while there is still a big market for traditional software development, this whole Web 2.0 thing is all about people with Web skills building really powerful applications. I think that’s a big threat to companies who are invested in pushing their operating systems in that traditional style. This whole emergence of Web 2.0 is a big threat to the traditional software business.

With Windows having such a large market share and Macintosh and Linux developers forming their own communities, is cross-platform still important?

I think it is, because it’s not just Windows versus Mac. It’s Windows Vista versus XP versus Windows 2000 and it’s every version of MacOS and Linux. People don’t want the hassle of having to do every OS-version-specific coding; anybody who has done traditional software development knows that it’s a huge investment. It’s true that Windows has a huge mass market share, but Linux and Mac are growing in momentum, and who knows where that will be in five years.

Are you trying to do with Apollo what Sun was trying to do with Java applets?

I think that you could draw that comparison. Java’s value proposition was “⁠write once, run anywhere.⁠”⁠ That is, you could have a single runtime that ran on any platform. But there are some big differences. We are the beneficiaries of observing what Sun did and what worked and what didn’t. Part of the problem was that Java was a whole new language and framework that people had to learn, so there wasn’t a huge existing base of developers already using the technology.

C++ developers had to convert their skills to Java.

Exactly. And that was a barrier to adoption. But the big issue was that in the end, every Java Virtual Machine ended up being different?so you couldn’t write one Java app that would run on any JVM. And every app was tied to a specific version of a JVM. That happened because third parties could write their own versions of the runtime, which lead to different implementations. We’re avoiding all of that. Adobe, and only Adobe, makes the run time. We’ve taken the same approach with Apollo as with Flash Player. Adobe maintains the code base for the Flash Player because we want to preserve a consistent appearance across every platform.

One of the problems with the JVM model has been backwards compatibility. But with Apollo, every version of Apollo will be backwards compatible with previous versions. So if I write an Apollo 1.5 app, I can run that in Apollo 3.0.

You’re also in a better position than Sun to distribute runtime.

If I’m in a briefing with CTOs and CIOs, I like to remind them that Adobe has distributed more software to more people than any other software maker in the world. With Flash Player and Adobe Reader, that’s over 700 million people. Flash Player is the number one installed piece of software in the world, and Adobe Reader is number two. Number three happens to be the JVM, but that’s the problem. You can say that the Java Virtual Machine is the third most distributed software, but they are all different versions.

What types of applications you expect to be built with Apollo?

The apps that we’re hearing discussed the most from our beta testers and customers are productivity apps: note taking, brainstorming, email, and calendar. There’s a lot of talk about those because they effectively leverage online data, which means you can access your data from anywhere.

If these applications are often found as RIAs on a browser, what’s the advantage of running them on the desktop?

That’s an element of Apollo that’s hard to articulate and tough to prove?but let me give you an example. My parents use a popular tax package that’s available as commercial software that you install on your computer. The program is also available online, with the same functionality. Every year, I tell them: don’t spend your money on the commercial software, just use the website: you’ll get the same results, and you won’t have to install new software. But every year they go down to the computer store and buy the package. I finally got my parents to tell my why they are doing this. It became clear that they perceive more value in having a desktop application with an icon that they can click. They feel they are getting more because they are actually using an application, not just looking through a window into a website.

In this particular case, I’m focusing purely on the aesthetic appeal of having a desktop application. But there are other benefits, such as all the features you can get when you are outside the browser. That said, there is something about having a dedicated application. [Publisher and Web 2.0 expert] Tim O’Reilly was at a summit we did earlier this week and talked about this as well. There are certain Web applications that he uses every day where he doesn’t want to click on a tab in his browser to get to them. He wants a separate app with its own window that he launches and keeps in the background. There are some apps where you want that kind of experience?it’s either more convenient, or at least psychologically you feel there is more value in it.

Do Apollo applications have to have an Internet interface?

Not necessarily, but probably. You’re using Web technologies to build the application and there are so many benefits from accessing Web services, that most apps will do that. But if you wanted to build a small, self-contained utility with no Internet access, you could do it. The draw here is for Web developers. They may not know C++, .NET, or Cocoa on the Mac, but they may know Flash, ActionScript or JavaScript well. Using those skills, they can write an app.

Are those the three major programming skills Apollo is trying to leverage?

The primary skills are HTML, JavaScript, XML, CSS, and of course, Flash and Flex?for which our programming language is called ActionScript, along with the accompanying development tools. But we’re not introducing any new tools or languages with Apollo. All of this is already in use.

What other applications do you expect people to build?

There are media-centric applications. For example, there are all kinds of situations involving audio and video on the desktop: where people want not just to download and view, but manipulate the data. Some people are building simple video editors in Apollo. One company is doing a pretty extensive audio editing tool. Adobe is working on an application called Filo which is basically a desktop media player that will aggregate RSS video feeds, with DRM capabilities built-in.

What kind of response have you gotten in Japan?

I’ve briefed several companies in Japan who are interested in Apollo. One of them is doing mini-applications that they currently deliver in the browser. They are working with some automotive companies to “⁠brand⁠”⁠ the application?that is, advertising through the application itself. Imagine having an app that tracks your stock portfolio, but also happens to be completely branded for some big car company: the colors, style and name might all reflect the brand itself. We’ve seen that kind of idea from a lot of people who are developing Apollo apps: attract users by giving them something of value, which is what the app does, and in the process, you will get your brand in front of them.

Do you have any sense how Japanese developers may use Apollo differently?

My experience after managing our Flash team the last three years is that Asian developers have tended to be the earliest adaptors in doing new, really cool things with our technologies. So we’ve spent a lot of time over there meeting and learning from customers. I think there’s a higher premium on design and aesthetics, but also on really immersive user experiences. Pretty much every company I’ve visited over there has had that kind of focus. As a result, they’ve built some of the best Flash content that I’ve seen. Asia has also produced some innovative business models that you don’t tend to see elsewhere. As for Apollo, especially in Japan, as well as in South Korea, we are seeing some really engaging applications that we didn’t even think of.

Where did the idea of Apollo come from?

It started at Macromedia. In 2003, our chief software architect, Kevin Lynch, put together a project called Central?that was aimed at taking Flash out of the browser and onto the desktop. We learned a lot from that project, including one thing that didn’t work. All Central applications had to run within the same shell. It’s almost as if we created another browser, but one that only hosted Flash desktop apps. That didn’t really work, because people couldn’t completely own the user experience. But we did see the potential. When we combined with Adobe, we realized we could leverage a lot more of our capabilities. For example, we realized that if we built in a full HTML engine into the runtime, that all these Web developers who were already building great browser-based applications could use the same platform to build desktop apps.

Finally, what impact do you think Apollo will have on application development?

Well, I’m a bit biased, but knowing what I know about the technology and the people who use it, I think Apollo is going to introduce a whole new generation of applications and experiences. This is going to be a monumental shift in how we interface with applications on the desktop and the kinds of applications we see. The promise of being able to experience these applications regardless of platform will matter. I have family members on Windows and family members on the Mac?now I can send them a link to an app without worrying about which one.

A big factor here is that the types of people who are building these applications are very different than the traditional software developers. Web developers are used to focusing on really engaging experiences, creativity and design. As these people move their stuff onto to the desktop, I think you are going to see a whole new class of desktop apps.

Is that because the culture of online development is different? That you have to grab people to get their attention?

Yes. I think these are different types of people who are doing this work, with a higher concentration of artistic、 creative people gravitating toward the Web as a medium. They like the technology and the tools?of which there are nothing comparable on the desktop. Now that they are able to build desktop apps, we are going to see things we have never seen before.

Sidebar: An eBay Desktop App?Built with Apollo

The Denver-based design firm effectiveUI has been using Apollo to build an experimental desktop version of eBay’s online auction environment. Reasons cited include better response via local storage and improved caching. But the real reason may have more to do with the rationale for Apollo itself: desktop applications don’t disappear when you shut off the browser. That icon shortcut on the desktop is a subtle reminder of an online service just waiting to be used.

Anthony Franco, one of the firm’s managing partners, thinks that most Apollo applications will replicate the eBay project. They will begin life on the browser, and then try to stake a claim on the desktop with additional features. “⁠If users want to do things the browser doesn't allow, they can take that same application and user experience to their desktop.⁠”⁠ As for developers, they can start with the same code base, and then add functionality. That’s the Java idea, as well, but “⁠Java tried to be all things to be people, and therefore never focused on the GUI. That's what Apollo and Flex gives us.”

Formed two years ago, effectiveUI is staffed by “⁠a bunch of guys who were doing this on their own.⁠”⁠ The firm has done design work for some big companies, including Intel, Yahoo!, Boeing, Cisco, United Airlines and?by the way?Adobe, which is perhaps how it got its collective hands on the beta version of Apollo.

For the eBay project, code named San Dimas, the team of four developers and a designer leveraged its skills in Flex and Fireworks image editing tool, as well as some Illustrator and Photoshop expertise. “⁠We’re using Web-based tools for all of our development,⁠”⁠ says senior developer Sean Christmann. Apollo plugs into the Flex Builder development environment, allowing debugging and testing to take place in an application mode. When that process is done, “⁠you just go to an export menu and select the files that you want to bundle into the application?and you’re done. Apollo takes care of the install process on the user’s end.⁠”⁠ Christmann credits Apollo with putting the team a month ahead of schedule.