Thinstall: the “hairball” that chokes VMware?

I guess it was just a matter of time. When I last reviewed Thinstall, I noted that, while the technology was useful for certain niche scenarios, what the company really needed was to be swallowed-up by a larger player. Now that VMware has stepped up and filled that void, it’s time to assess just what it is that the author of the ill-fated “Virtual Desktop Initiative” (VDI) has ingested.

Some might see the acquisition as a “tasty morsel,” a way for VMware to expand into the nascent Application Virtualization space by purchasing a smaller (20+ people at last count) player with an outsized presence in the market. I, on the other hand, see a potential “hairball” in the making.

Thinstall’s self-contained virtualization layer is a version control nightmare, one that has hamstrung the company’s ability to penetrate the broader enterprise computing market. This is an architectural problem: The entire Thinstall runtime — along with any applicable Access Control Lists (ACL) — is embedded within the packaged executable. Changing any part of the package (patching the code, modifying the ACL) requires that you regenerate it from scratch. From an IT perspective, it’s an inflexible mess.

Of course, VMware is probably willing to overlook these caveats if doing so allows it to continue its endless quest to “topple Microsoft at all costs.” After all, the Redmond gorilla did its own gobbling a scan 18 months ago, scooping up the problematic SoftGrid in an effort to refashion its own delivery architecture. And in the battle for roadmap bullet points and RFQ checkboxes — where missing a tick or two might mean the difference between a sale and and empty stomach — maybe it’s better to cough-up the occasional “hairball” and hope nobody notices the stain on the carpet.