There’s nothing quite like being indirectly slashdotted. In this case, Jeff Gould, in a blog covering a discussion that he and I had a week or so ago, makes some interesting points about the Xen project and XenSource that someone on slashdot appears to think are direct quotes of what I said. The upside is that this is the first time the Xen project has been slashdotted for a while, which is a good thing, but the downside is that two layers of reader interpretation leaves a good distance between reality and what’s been written. So this is a “moderation” of Jeff’s post and the slashdot article, to put very clearly the XenSource position on the mixed-source model, the vital importance of the Xen community and its ability to deliver differentiated, value added packages of Xen to market, to maximize customer choice.

The Xen project does not develop a product. It develops, based on contributions from the world’s best software developers at IBM, HP, Intel, AMD, Novell, Red Hat, VA Linux, Fujitsu, NEC, Stratus and many others, the world’s best engine for virtualization , the Xen hypervisor.

That is a deliberate approach, in contrast to developing a whole productsuch as Fedora Core. Why? The project explicitly endorses Xen delivered as an integrated hypervisor in an OS (Linux, Solaris, BSD), or as a platform (such as our own XenEnterprise). Different customers have different use cases and needs for consuming virtualization technology. The project believes that the community is strongest if each vendor can take the engine, add value to it in its own way, and deliver it to its customers. An example would be Red Hat’s packaging of Xen in RHEL 5, and the addition of its management tools and libvirt, its API, or Novell’s packaging of Xen in SLES 10 SP1, and the use of (closed source) drivers enable SLES 10 to host Windows. Jeff refers to libvirt as “proprietary software, open sourced”, and it’s important to realize that this is not about the openness or closed nature of the software, but about the differentiated nature of the software as a “proprietary” value-add from that vendor.

The point is that libvirt and their virtualization management tool are Red Hat’s value-add, and entirely legitimately so, and valued by Red Hat’s customers. That’s what Red Hat’s customers will pay for. Novell’s approach is different, and will also have Novell-specific management add-ons, drivers and the like. XenSource delivers a yet another set of value added features by packaging Xen as a platform hypervisor to compete with VMware and for delivery into a different market segment (mostly Windows based) and that’s our value add. The object is to legitimize and endorse multiple independent vendors delivering their own value add to the market, therefore ensuring that they continue to commercially benefit from their contribution to Xen.

The XenSource model of mixed source product is in part forced by the licenses of key components that we use, such as the Microsoft DDK, which requires that drivers developed using it, are not open sourced. XenSource’s commitment to the community is that the core Xen engine is always the very best version of the hypervisor at all times. Every fix, every advancement that the community delivers, goes into the code base right away. Last night Ian Pratt found a bug that had plagued Vista on Xen for a long time. As soon as it was validated this morning, he posted the patch to Novell, who also support Windows on SLES 10 in their product. Aside from drivers, XenSource also has a .NET GUI, which is specifically aimed at our market segment. More legitimate differentiation around the same incredibly powerful core open source Xen hypervisor that Novell, Red Hat and Sun (to name a few) can deliver to market.

In summary, the project does not deliver a whole product, simply because it honours the value-add of the community vendors. So the “engine” approach is not “to stop Red Hat running away with all the value” as Jeff states, but instead to “allow Red Hat to independently add value to the engine and deliver a differentiated product to its customers”. That is an important distinction that Jeff’s blog fails to communicate.

XenSource delivers a platform hypervisor into a market that is largely Windows based. That’s just where we choose to play. Red Hat delivers an integrated hypervisor into an entirely open source market, with a primary focus on Linux. That’s a market that is inaccessible to XenSource, and we’re delighted that Red Hat can monetize Xen in their market segment. There is no conflict, and that is good for Xen and for the vendors that deliver Xen into different markets. So it is fair to say that the engine approach is the correct one, in comparison say to the “fedora core as complete product” approach, which would likely alienate sectors of the community. That said, the Xen code base continues to develop apace, and if the community wants to deliver a complete product, then it can.

It’s difficult to please everyone. The objective is to endorse, legitimize and encourage multiple vendors to deliver Xen to market, adding whatever value-added features they choose to. Red Hat’s product is suited to a particular market, and I think that’s great. Novell aims to use Xen to offer commercial support not only for SLES, but also RHEL, NetWare and even Windows. That’s great too. It encourages competition, and the best products in the market will win.