Posted by: Rich Brambley
Rich Brambley, Virtualization, VMware Workstation
While the topic of VMware licenses expiring is fresh on everyone’s minds, the VMware Workstation 6.5 development process is an example of how product expirations are normally used to ensure customers are working from the latest supported product builds.
The blog post Workstation 6.5 beta – Release Candidate available on the Gabe’s Virtual World blog not only let me know VMware is getting closer to general availability with the latest Workstation release, but it also helps put VMware’s recent blunder into perspective. In short, Gabe posted because users of the Workstation 6.5 Beta 2 now have expired licenses that need to be upgraded for the new Release Candidate 1.
I’ve read several posts and comments over the last week stemming from the August 12 VMware ESX/ESXi Update 2 bug that expressed administrator outrage over the fact that VMware uses license expiration time bomb code in their products. Opinions ranged from “VMware is too concerned with protecting their software that it hurts it’s paying customers” to “product expiration code bugs are impossible to catch in the change control process so they should never be implemented.” I’m not arguing that either of these opinions is wrong or that VMware did not make a mistake, but time bomb licensing is a standard development practice. The primary purpose of the license expiration is to make sure all testers upgrade and VMware is not only supporting the latest version, but is getting technical feedback about the right code level. It was easy to lose sight of this during the frustration last week.
Let’s assume that VMware’s Quality Assurance and regression testing process doesn’t fail to remove or disable any license expiration code when Workstation 6.5 is finally generally available.
By the way, VMware Workstation 6.5 has some exciting new features. Go to the Workstation 6.5 Release Notes Page for more information.