Chris Wolf's Blog

I’ve blogged about many of the good things that VMware has done in the past year. But New Year’s Resolutions provide a time for reflection and self improvement, and I think even VMware President & CEO Paul Maritz would agree that there are areas where VMware can improve. Let’s start with improving software QA processes.

In my previous post, I talked about a New Year’s Resolution I’d like to see Oracle make. Today, I’d like to offer up a few New Year’s Resolutions for VMware:

• Continue to improve software QA and release processes
• Embrace your role as enterprise middleware
• Be clear with your ISV partners on your software direction and roadmap

I’ve blogged about many of the good things that VMware has done in the past year. But New Year’s Resolutions provide a time for reflection and self improvement, and I think even Paul Maritz would agree that there are areas where VMware can improve. Let’s start with improving software QA processes.

Improve Software QA and Release Processes

To understand the need for this resolution, rewind to August 12, 2008. In a letter posted on VMware’s Executive Blog, CEO Paul Maritz stated the following after a major ESX 3.5 Update 2 bug wreaked havoc on several VMware infrastructures:

We are doing everything in our power to make sure this doesn’t happen again.  VMware prides itself on the quality and reliability of our products, and this incident has prompted a thorough self-examination of how we create and deliver products to our customers.  We have kicked off a comprehensive, in-depth review of our QA and release processes, and will quickly make the needed changes.

Fast forward to December 2008. VMware releases ESXi 3.5 Update 3, and apparently shows some holiday goodwill by unlocking the free ESXi hypervisor API set. Problem is, however, that the API set was never supposed to be unlocked in the first place. VMware’s Mike DiPetrillo noted the mistake on his personal blog:

Turns out that while fixing an API bug the API set got partially unlocked. Yes, you read that right, VMware didn’t mean to unlock the API set - at least not wholly and not yet.

Mike DiPetrillo deserves credit for stepping up and fully explaining the issue. A lot of folks who work for software vendors simply would have tried to sweep the issue under the rug, but Mike didn’t do that. That level of integrity is certainly commendable.

That being said, it seems as though VMware still has some work to do with regards to QA and software release processes. I’ve worked for a software vendor and know that it’s impossible to ship perfect software, so I’m not trying to put VMware up on a pedestal. Still, with CEO Paul Maritz personally calling out the need for improved QA, these types of mistakes are not helping VMware to recoup some of the trust that was lost by the early ESX 3.5 Update 2 adopters. VMware took it on the chin last summer and acted fast to correct a bug that would not allow some of their clients’ VMs to boot up. Sure, you could argue that the latest bug is small potatoes in comparison. But let’s remember the big picture. VMware wants to be THE software that runs on the metal. That requires an enormous amount of trust, and VMware cannot afford to continue releasing software with major QA oversights. In the short term, I expect many enterprises to delay up to 30 days before implementing updated VMware software and new product releases. In the long term, VMware will hang its hat on the quality and stability of its products. Enterprises have a high degree of confidence in VMware software today, and for VMware’s future, that degree of confidence must remain high.

Embrace your Role as Enterprise Middleware

Attending a VMware conference and seeing a presentation that assumes the entire software stack runs on VMware infrastructure has been a bit of a disappointment for me. The reason for this is that nearly all of our clients run application stacks that traverse both physical and virtual infrastructures. While I like seeing how things may look in the future, our clients want help with the problems they’re having today. That means VMware infrastructure management must integrate up the stack with tools capable of managing both physical and virtual infrastructures. VMware would do itself and its major partners in the management space (e.g. BMC, CA, HP, IBM) a service by positioning its product portfolio representative of how it’s used by most enterprises. The internal cloud or dynamic data center isn’t going to happen any time soon if it requires a fully virtualized infrastructure. Instead, VMware needs to embrace their role in the middle of the stack and show customers how to integrate their products higher up the stack.

Be Clear with your ISV Partners on your Software Direction and Roadmap

Last week I talked to a vendor who said “We really wish VMware would be more open with us regarding future plans in the management space. It’s hard to know exactly where they’re heading and find our niche in their ecosystem. Microsoft, on the other hand, has been much easier to partner with.” I’ve heard similar comments from close to a dozen vendors throughout 2008. Moving into 2009, VMware needs to be conscious of their partner ecosystem and work closely with partners to ensure that their partners can grow alongside VMware. Otherwise, I expect some of those partners to exhibit more of a willingness to work with rivals Microsoft and Citrix. It’s hard to overstress the importance of this; much of Microsoft’s dominance over the years has been built on its ability to attract and keep third-party developers. Hopefully Paul Maritz, as an ‘ol MicroSoftie, understands this issue better than most.

That’s it. Like with Oracle, I don’t feel that I’m asking too much.


[This post appeared originally both here and on Burton Group’s Data Center Strategies blog. It is republished in full with the kind permission of the author.]