Saturday, December 13, 2008

Native Client and Alchemy: Software as a Service?

Not so long ago, Google announced Native Client which describes a way in which a browser may execute native instructions in secure sandbox. The natively executing code would run at full speed, and the sandbox would provide a platform-independent layer of abstraction so applications targeting whatever framework was distributed with Native Client The Product (tm) could run on Mac, Linux, or Windows. The paper linked from the "NaCl" page describes the security measures taken to ensure natively executing code can do nothing harmful. Presumably, just running a NaCl browser on a Linux, Windows, or Mac system as a user with minimal privileges to the file system and other resources is already sufficiently secure, but the sandbox protects the browser process as well.

Previously, Adobe announced Alchemy leveraging the Low-Level Virtual Machine bundled with the Flash player as a way to run C++ applications at near native speed with the safety of executing in a virtual machine and dynamic compilation framework. LLVM has the added benefit of being a mature project with fairly robust and well-designed development tools and runtime features.

The commonly cited application for these frameworks is "to run Quake in a browser!" While interesting in its own right, a conversation with Uniquely Joe sparked the idea that perhaps this offers a new business model for software development. Instead of buying shrink-wrapped software in a box, or downloading a torrent from your favorite pirate search engine, you simply log into your software account provided by Adobe, Google, Microsoft, or other, and use the applications you've purchased a service plan for. This benefits you because you don't have to worry about maintaining all of these software installations on the several computers you may work from, software upgrades are more seamless [perhaps less expensive for each subsequent version but now there are many more versions though only your checking account really notices], and perhaps there is a security benefit too if most of your applications run in some sort of sandbox.

This benefits software publishers because distribution costs diminish as there are no shrink-wrap boxes to produce, revenues are more constant due to the service-oriented usage model, you can push advertisements to your users and probably achieve better product integration, and you can curtail piracy since presumably you could build in a cryptographic certificate to prevent execution of your application except where authorized by your license server. With everything running in a sandbox with a uniform abstraction layer on all architectures, testing and support costs should also diminish. As we learned in CS 8803, dynamic compilation frameworks are able to perform many optimizations at runtime that enable an application to [eventually] achieve high performance tuned to the actual system on which it is executed. 'Application + dynamic optimizer' is clearly parallelizable so additional processor cores should reduce the impact of dynamic translation overheads.

Will consumers like it? While some won't even notice a difference, many might be attracted for the reasons previously listed. If Adobe can count on users having LLVM installed, or users willing to install it, it may take this route exclusively. How many people would be willing to eschew Adobe's impressive productivity suite in favor of the disjoint FOSS projects out there?

Comments welcome.

No comments: