There’s been a great deal of interest about our big news over the past few days: from customers, partners, the Open Source community, and from within Citrix itself. Everybody seems to realise that taking XenServer fully Open Source is a big step, and means some big changes in how we interact with the world. The overwhelming response has been very positive (which is quite a relief, at this stage in the game!), but there’s one particular question that keeps coming up: “who’s in control of XenServer, now that it’s Open Source?”
The question gets asked in a number of different ways, and it’s an understandable one. Before I answer it, it’s worth explaining quickly how we got to this position. As we announced recently, XenServer 6.2 is now Open Source. This means that all of the code is available to the wider community for its members to look at it, change it, add new features and even create new products which are based on it. And this is what has led to some questions.
“If anybody can add features or functionality to XenServer,” people are asking, “then who controls it?”
The answer to this question is actually very simple, and it’s this: Citrix.
“How will Citrix support the huge range of features that might be added,” is the next question, “and how can I be sure that the functionality that I need, and which I’m planning my business around, will continue to be there?”
The answer to this is also simple: Citrix owns the XenServer product, and when we release a new version, it will be us – the XenServer team, and, specifically, the Product Management team – who decide what features go in it. That release will be tested, documented, maintained and supported in the same way that all other Citrix releases are. We will run roadmaps, plan with our partners and customers, and ensure that we match the functionality in the product to the strategy we are pursuing.
Can partners, customers, hobbyists and the like add new features to the codebase? Absolutely. They can create their own product based on that codebase, and decide to have a different set of features in their version. But that product won’t be Citrix XenServer, and Citrix will not support it. There will be occasions when our partners and customers will add new features to the codebase and ask whether Citrix will add them to the XenServer product. In fact, we’re already seeing this, and sooner than we expected. We will work with them to decide whether they should be added to the XenServer product, and many of them will, but it will be the XenServer team’s decision. Any features that are added to XenServer, whether architected, designed or coded internally or externally, will be subject to the same testing regime.
It’s worth mentioning that Citrix isn’t ramping down its XenServer engineering efforts: we still have a flourishing XenServer Engineering group, working on the next release (no teasers yet, I’m afraid!). The main difference in how they work is that everything they do will now be shared with the Open Source community, and now they have new peers in the community who will be adding their own code, criticising and refining existing code, and doing their own testing alongside.
We confidently expect to see the XenServer codebase expand and morph in new and exciting directions. Some of those directions, we know, will not be core to Citrix’ vision for XenServer, but that’s fine. Others will be, and we look forward to working with the wider community to build an even better product within the Citrix portfolio.