After hearing about VDI-in-a-Box and its impending demise, I started thinking about what could be next for Citrix. Citrix is in the middle of a restructuring that, among other things, resulted in the layoff of 700 employees last month. These employees ranged from contractors to product managers. The information about VDI-in-a-Box, in fact, was surrounded by conversation about these layoffs.
When thinking about the effect of this restructuring on Citrix’s product line, the product that keeps circling up to the front of my brain is XenClient. Those who follow Citrix can easily point out the last time something major was done with XenDesktop, XenApp, ShareFile, XenMobile, and NetScaler because there is activity with those products. There’s customer interest, acquisitions, and development happening around them. That’s not the case with XenClient (how long did we have to wait for 5.5?), and it’s why I think XenClient is in trouble.
Client hypervisors like XenClient have a use in organizations, but today’s world is far different from what it was when we first learned about them. The use cases for client hypervisors were limited from the beginning, and are more so today because the way we interact with our applications and data are changing. For instance, you don’t care about managing Windows in addition to a hypervisor on every laptop if your apps are coming from the web or on mobile devices. Why bother with that complexity when you can simply give a user a Chromebook or mobile device with some bookmarks?
Sure, that’s a simplistic view, but the use of XenClient boils down to just a few one-off situations in most companies. Good product? Yes. Lots of use cases? No. I want a client hypervisor, and you want a client hypervisor, but we don’t want our users to have them (generally speaking). That small number of use cases is hardly enough to justify all the development required to constantly keep the custom kernel behind XenClient modernized (even the latest version is behind the times).
So the overall picture isn’t very rosy. Among the 700 people who were laid off was XenClient product manager Pete Downing. If you’re higher up the food chain and you have to choose who stays and who gets laid off, do you lay off the PM of the successful product? No, you lay off one that you were going to probably have to find a new job for anyway when you cancel a product.
What happens to the XenClient product and customers?
First, it’s interesting to note that DesktopPlayer and XenClient are treated as completely separate products. It makes sense when you think about how they work, but I bring it up here to make it clear that if XenClient dies, DesktopPlayer doesn’t necessarily go with it.
With that in mind, Option 1 is to open source XenClient and turn it over to the public. It seems like it might be a good idea, but what makes XenClient different is the management and integration with the Citrix platform. Those things are also used in DesktopPlayer, so you can’t open source IP you’re continuing to sell.
Ok, then, what if Citrix strips out that proprietary stuff? All you’re left with is a custom build of Linux with the Xen hypervisor on it. There’s not much value in that, and running that on your own is probably more trouble than it’s worth (the same problem Citrix currently has with development).
Option 2 might be to simply shelve XenClient and convert customers over to DesktopPlayer. Ask yourself, though, if you’re a XenClient customer who purchased XenClient because it’s a Type-1 client hypervisor for all the security and management capabilities, are you going to be a fan of Citrix saying “Hey, yeah, that thing you bought…we’re not doing that anymore. We can give you this other thing we have that works a completely different way?” I doubt it.
Those customers would now have to go back to putting an OS on the endpoints that they have to fully manage as well as a VM that they have to fully manage. Plus, what options do those customers have right now? The only version of DesktopPlayer that’s out is for OS X. The Windows version has been “Coming Soon” since last May, but has yet to see the light of day.
Option 2 isn’t sounding all that great, at least if I’m a XenClient customer. Option 3, though, could be to introduce a third DesktopPlayer, this time for Linux. It would be a Type-2 client hypervisor, so Citrix wouldn’t have to get wrapped up in building in all that hardware support into the kernel. Instead, they could leverage the capabilities of whatever version of Linux you wanted to run. That means you could run Ubuntu wide open (and simply confuse your users into using the VM), or you could make a locked down version that basically only ran VMs, but still had the appropriate kernel. They couldn’t mess with the base OS, and you get to manage the VMs just like you always have.
Actually, Option 3 sounds pretty great, all things considered. You’d have to be more knowledgeable about Linux to pull that off (which isn’t the case when using XenClient since it “just works” from an OS perspective), but it’s the least bad option. There is also an fourth option, with Citrix selling off XenClient, but I can't think of any other time Citrix has sold a business off. They'd have to sell off DesktopPlayer too if there really is any shared IP, so that seems unlikely.
So that’s where we are, and it doesn't look good. If XenClient really is on the way out, the best option from Citrix to continue supporting the customers that bought into the platform doesn’t actually exist.
Until we learn the fate of XenClient, there are a couple things you can do. First, Citrix knows who the customers are that bought XenClient standalone, but if you’re a XenDesktop Enterprise or Platinum customer that uses XenClient, the fact that you’re using it might not be readily visible by Citrix. Let them know that you use it. Second, start thinking about what you’d do if XenClient were to go away. It won’t disappear suddenly, but if support ends, you might find yourself in a tough position when the next round of new hardware comes out and you can’t use it.