Some recent software installation trials and tribulations (Microsoft's Team Foundation Server, for those who wonder) have encouraged me to restate the observations of a prior entry, Adoption = (Functionality - Cost) ^ Ease of Use.

In that outing, I observed that the adoption (or avoidance) of a product is often correlated with the ease of taking the first step, along with the continued ease of using the product. While I focused on the usability and adoption of PVRs relative to VCRs, this premise holds true in the software field as well: Even among enterprise level applications -- huge, complex solutions that drive the engine of corporations -- the initial impression, or beginning evangelism, is often driven by the ability of some random tech guy to get the product installed and delivering some sort of value. All of the specialization, customization, and advanced uses will come later.

This can be demonstrated by analyzing the historic success of many Microsoft products. Compared to the Oracle of old, for instance, SQL Server was brainless to get running, and often found its way into many shops via MSDN subscriptions. Soon enough that MS Access developer was targeting SQL Server, tying themselves and their solutions to the product, in time taking advantage of all of its advanced functionality. The complexity of the product was "time-released". Microsoft Visual SourceSafe is widely considered an also-ran source control system, with a litany of missing functionality and known defects, yet it's the source control product in use by a huge number of software development shops -- Given how trivial it is to get going (versus many of the competitors that often demanded a sea of dependencies and configuration steps), many groups adopted it as a defacto source control product.

From hosting that first micro-project, it took hold until it was the foundation of the most compex of solutions.

The examples go on. Of course people would point to Linux as a counter-point, and to a small degree it is, even among the Linux camp the real adoption began when companies like Redhat made installation a simple "hit enter to all of the prompts" affair. Linux took off, while the more difficult to configure FreeBSD floundered.

Products took root, and then sprouted, because the first step was easy. This happens while much more capable solutions, with longer feature lists and a promise of a more rewarding long term, sit unloved and unused.

All of this had me wondering what part virtual machines could play in this equation. Virtual machine technology -- where multiple logical machines are virtually hosted on one physical computing box -- is a wonderful (and improving) technology that I still considering somewhat akin to magic. With Virtual Machine technology, whole platforms, including all required libraries, applications and configurations, can be delivered as an already running box, perhaps requiring nothing more than an IP address and some very rudimentary configuration. From source-control products, to wikis, to web application servers, virtual machine technology could allow for hugely complex solutions to be delivered in a "ready-to-run" solution.

Of course there are downsides to this approach. For instance it sort of eliminates reuse of common components (even requiring a separate OS instance for each virtual machine), yet common components are often the most fragile, perilous element of many applications. It isn't entirely a loss. Also there are licensing issues, such as the fact that you can't simply bundle a copy of Windows Server 2003 R2 with your virtual machine.

It's more a solution that works in the open source world, where you can release virtual machines configured with Linux, Apache, Postgresql, PHP, and so on, all along with your custom, ready-to-rock solution.

Unrelated Note: The mood pictures were taken at the Oakville 5 drive-in this weekend, which is one of the few movie experiences we get with two very young children. One usability note that I always observe at the drive-in is how many drivers don't know how to turn their daytime running lights off (here in Canada all vehicles have low intensity lights on whenever the vehicle is running -- even during the daytime -- which has been demonstrated to reduce accident rates). For those who don't know, on most makes of cars you can turn off the daytime running lights by engaging the parking brake before you turn on the vehicle. This isn't universal -- for instance I know some Ford models where it doesn't work -- but I've used it in a number of makes and models to success. This allows paranoid-about-their-battery drivers to start their vehicles at the drive-in without inciting a riot.