AppStream: ASP throwback or SaaS savior?

I had an interesting conversation last week with Paul Valcheff and Brian Duckering of AppStream, a company with a long and checkered history of streaming applications over the Internet for execution on the desktop. The way it works is that AppStream sits on a desktop PC or other client and streams the application code from the server as it's required. Once downloaded, code is cached on the client until the end of the session — or it can be held there if desired for repeat use or for offline working. So the software is managed from the network, but it executes on the client.

My initial reaction to this type of technology is hugely unfavorable. Its main use case today is to encourage yet more SoSaaS — unreconstructed client-server applications with unwieldy and cumbersome thick clients that vendors can turn into what they imagine is a SaaS offering simply by implementing AppStream around it. This is precisely how AppStream is marketing the solution and in my view it's really doing a disservice to vendors and their customers. This is a throwback to the early days of application service providers (ASPs), one that encourages vendors to switch to an Internet-delivered model without doing any of the software re-architecting and business model re-engineering that's essential to realize the true benefits of the on-demand services model.

As you can imagine, I had a lively discussion with VP business development Valcheff while director of product management Duckering walked me through a demonstration. This showed how a PC user could have access to various applications such as Acrobat, Office and Visio, all of them stored on a server and downloaded as required by the AppStream software. An administrator can decide which users get which applications and which versions, can time-limit their usage, and set whether or not the applications get cached on the user's PC for offline working. Because the application code that's downloaded is a pre-installed copy, it takes next to no time to start up. An application like Visio can load with barely 20% of the full code downloaded. More of the code gets downloaded on demand as the user accesses additional functions.

The trouble is, this is not Software-as-a-Service. I know I've described SaaS as a journey, but this is not even on the first rung of the ladder. The software is still desktop software. It doesn't depend on the network in any sense, except for the automated download and installation. The applications are no more SaaS than Windows is when maintained by Microsoft's Automated Update. The installation and asset management is provided as a service, but the software itself isn't. It's just software, as, er, software.

What would make it SaaS would be if, even though some of the application resided on the client, it relied on other components that reside on servers or at other locations in the Internet cloud. Dan Farber published a useful interview with Microsoft's Charles Fitzgerald this week which fleshes out what the company's emerging server-plus-services mantra actually means. He begins by quoting from a recent blog entry by Fitzgerald:

"The reality is the desktop is moving into the cloud and the cloud is moving onto the desktop. The winners will bring together the unique capabilities of both. The losers will cling dogmatically to one or the other."

He went on to cite the example of the Xbox gaming console when used with the Xbox Live service:

"What's so interesting about Xbox Live is that it brings together software and services in a very powerful way. Xbox takes advantage of local processing and the Xbox Live service has a community aspect and updating on the fly. The opportunity is to bring to get best of both worlds. I encourage enterprises to check it out."

Compare that to what Cliff Reeves, general manager of Microsoft's Emerging Business Team, told ISVs attending the recent SaaS Summit about the role of Office as a client for accessing online applications:

"We think [Office] is going to be a very viable client for a number of applications and we're working with SaaS companies to connect Office as the main offline client for those applications."

While Microsoft sees Office as the ideal client for accessing cloud-based services, others look at slimmer packages or even browser-based solutions such as Zimbra's new offline client, which uses the Apache Derby database to store local data. That's a step too far for Ryan Stewart: "Is this really the best we can do? Offline applications in a browser? Please tell me it isn’t." His preference is for 'smart client' platforms like Adobe Apollo or Microsoft's Windows Presentation Foundation and other components of the latest .Net Framework.

But of course all these solutions mean downloading increasing amounts of executable code to the client. Having sat waiting more than five minutes for Microsoft Live Meeting to download before being able to view AppStream's demonstration — and an hour previously having waited several minutes for WebEx to download its Java-based client software for an earlier conference call (I replaced my hard disk the other week so all my web conferencing software needs downloading from scratch again) — it struck me that solutions like AppStream could become a saving grace for the future of SaaS in which ever-richer functionality, as well as cached data, is downloaded and stored on the client.

So long as it's managed from the network and the user doesn't have to tangle with the technology, that seems like a neat compromise to me. Indeed, it could even mean that I could log into and use any PC or other device wherever in the world I sat down in front of one, and I could have my apps and data streamed down to me just for that session. This, it transpired, is a vision that AppStream also shares, so maybe the company will have a role in the future of SaaS after all.