Thanks to old friend Stephe Walli, I had the pleasure of meeting with Bitrock CEO Erica Brescia bright and not too early (it was the day after our Bday party, after all) last Thursday morning. What I expected based on the initial introduction was a reasonably interesting packaging story, but candidly, little more.
What I heard was something at once broader in scope and more compelling: a legitimate network enabled application installation, management and monitoring story. One that’s cross-platform (Linux, Microsoft, OS X, and apparently Solaris as well) no less.
For those of you that have followed my Quixotic attempts to drum up interest in a network application with the ability to refine and evolve the application installation and management experience, Bitrock is worth a look as it provides several of the fundamental pieces (package management, monitoring, etc) one would need to construct such an offering.
The basic value proposition, then, to an ISV is that Bitrock can package your application such that it’s suitable for cross-platform deployment, thus freeing application vendors from the burden of delivering multiple builds themselves. Examples of their application stacks can be found here.
As an aside, when I say cross-platform, I don’t mean Adobe AIR-style “sure we’re cross-platform – you know, Mac and Windows,” but rather truly cross-platform. Both dominant commercial distributions, Solaris and Linux. Even better, the Linux support is not limited to the dominant commercial distributions, in Red Hat and SuSE, but is inclusive of Debian, Ubuntu and other commercial and non-commercial variants.
Bitrock has, in other words, replicated a portion of the basic package management functionality and dependency handling common to Linux but absent from OS X and Windows. Other similarly targeted efforts include the pre-tested and certified stacks sold by Sourcelabs and SpikeSource, or the virtual appliances championed by VMWare and partners.
By way of comparison, Bitrock lacks the central repository GUI common to distributions like Ubuntu and the comprehensiveness of Debian’s 25K+ packages, but it’s cross-platform while the package management approaches within Linux remain not only operating system specific (with rare exceptions like Nexenta) but distribution specific. As are the respective packaging formats.
Bitrock’s flexibility, however, does not come without a price. The primary cost of appears to be a lack of visibility into the existing resources, and an inability to manage them outside of application specific silos. While I was able to install a Bitrock-based BitNami Trac stack on Ubuntu Gutsy moments ago (see inset), the installer didn’t look for existing Apache, Python instances or other Trac requirements, instead dropping in its own. Some of these resources – Python2.5, specifically – were also left behind when the uninstaller had finished its work.
That’s the bad news.
The good news is that Trac was up and running in about 30 seconds, in 6 clicks – including an initial project setup. There are trade-offs, clearly, but for certain constituencies Bitrock’s abstraction of the installation process will be welcome. Particularly on operating systems like OS X and Windows that do not have centralized dependency handling.
Much of a prospective user’s appetite for Bitrock’s brand of packaging depends on context: their operating system, their skill level, their application needs, and so on. It’s not really aimed at a user like myself, who is content to leave the application installation, configuration and management process in the capable hands of apt. But on a volume basis, there are far more users not like me than there are like me – if only because Windows is still dominant in desktop and server contexts, and BitRock packages are well suited for the less technical and/or those that do not have systems like apt available to them.
With application installation a solved problem in some contexts, however, a product limited to that space would be of limited interest. Fortunately for BitRock, the installer is the least of what they’ve built, in my opinion (though likely not the developers’). Far more compelling to me is the network infrastructure behind the prebuilt stacks they make available.
Like many applications, including Flash or Java SE, the BitRock installer has the ability to “phone home” basic data: version information, for example. Which is nice. But certainly not differentiating.
What does potentially set BitRock apart, however, is the other telemetry that can be recovered from the client: everything from the expected installation data to useful systems management like information such as available disk space.
This ability to connect a simply packaged application back to a central network repository opens interesting new doors for a variety of audiences. What would it mean to ISVs, for example, to have active connections to and visibility of not just to their own application, but the dependencies it relies on? Or to be able to answer the “my server doesn’t work” question by pointing out that the machine in question is out of storage?
Or, nearer and dearer to my heart, what kind of developer ecosystem could be assembled around these connected application stacks?
As much as the potential utility of the telemetry impresses, however, it also has potentially profound ramifications vis a vis privacy. BitRock is apparently well aware of this, and devotes significant attention to safeguarding their install base. Good news, as I believe that’s a third rail issue for telemetry oriented firms. Lose the trust, once, and you’ll be working forever to get it back.
My one criticism in that area was with the delegation of control. Like pre-iTunes DRM providers, BitRock seems somewhat content to let ISVs implement that technologies as they see fit. Not only does this potentially jeopardize the consistency of the user experience, it also opens up BitRock to negative feedback for decisions that their ISV customers make. To wit, while the restrictions on early DRM offerings were a manifestation of outdated and nonsensical RIAA business decisions, that didn’t prevent users from blaming Microsoft and others for them. My own view is that BitRock would be best served by taking a strong pro-user stance, even at the risk of upsetting their customers, because as Apple’s iTunes success has proven the perception of being user friendly has substantial long term benefits.
It’s also worth noting that issues of telemetry are highly dependent on context: for many major enterprises, it’s a non-starter, while businesses further down the spectrum might be convinced if the returned value can be made immediately apparent.
Consider the consumer experience that many of us are familiar with: Internet Explorer, Google Desktop, and other desktop applications will occasionally ask for permission to share information about a crash or general usage with the developers. But there’s no instant gratification for users; they’re required to trust the data is put to good use. BitRock, on the other hand, can provide immediate reporting and aggregated data as an incentive to permit the return of application data to their network.
In any event, I’m looking forward to where the folks at BitRock take things; the convergence of application installation and network functionality is a trend that I’ve championed for some time.
