Slashdot Mirror
Open Source and the "Xen" of Xen
willdavid writes "In a follow-up to his original look at what happened to Xen, Jeff Gould talks to XenSource CTO Simon Crosby. Usually we hear about how open source provides freedoms for end users. However, this article talks about the difficulty a small software developer has with an open source license, in particular, the need to prevent Red Hat, IBM or Novell from running away with all the business revenue."
...where fending off Microsoft and IBM is a piece of cake.
Combining OSS + proprietary software can get complicated, but it's entirely possible to make a viable business that way and still have a positive, reciprocal relationship with the OSS community. You just need to make sure that the open source stuff actually has some value and is not a way to leech some free R&D. I.e. it should be be managed by you and hopefully mostly developed on your dime. If it is useful for your customers to be able to tweak the source, or if the software is useful by itself, then developers will work on it. However, if you're only playing lip-service to OSS, and people are really just going to run into a bunch of obstacles where they can't really edit the software because it's tied in to too many proprietary pieces, then you need to rethink your strategy.
I think what we are seeing is the never ending desire to have the benefits of an open source model while still having the closed source control. Finding the right balance so that people use your product while still having a reason to pay for the upgraded version or support isn't easy. And what we seem to be seeing these days is that open source isn't leveling the playing field, but rather tilting the game towards the big players who can leverage lots of applications without paying for all of the developers. There's a value with knowing how to run a business that the big players are providing and the smaller developers will need to learn if they want to compete.
Their reasoning is that if they released all of their stuff under GPL then Red Hat would just scoop it up and serve it in place of the very inferior management tools bundled into RHEL5.
This paradox has always baffled me. The open source community creates it, and then another company sells it, with the hope of making revenue from specialized knowledge. It's one of the two biggest flaws of the current FOSS model, in my view. The other is that FOSS software tends to clone/emulate existing commercial products.
Both of these face the same problem, which is that in a media-driven capitalist economy, ideas need to become products that are sold in order to be recognized as "part of" the economy and society as a whole. While GPLv3 is a good start toward working around this, another thought is that FOSS should operate on commercial principles from the beginning, and serve as a think tank and consultant shop that hires out its programmers to implement their own code for customers, eliminating the need for boring and unrelated "day jobs."
technical writing / development
I'm outright shocked (and awed) that Microsoft wasn't mentioned as a villian. This has to be a first.
Redhat Enterprise Linux refers to xen as Redhat Virtualization. Sure- the actual binaries are referred to as Xen, but the documentation gives virtually NO credit where credit is due. If I were a Xen developer, i'd be insulted.
There are plenty of licenses out there. Don't like GPL? Fine, don't play in their sandbox. BSD has a nice place to play, too, and you can keep your toys if you want. You might get a little lonely, though.
Yes, I realize you're not saying that Xen copied, but that Open Source in general copies. Xen is a great counterexample.
The Raven
I haven't read the FA yet, but this isn't the first time this concern has been raised. The OGP, from the beginning, have been struggling with the issue of some other hardware vendor legally taking OGP graphics chip designs and making their own version, thereby crusing the OGP out of existence.
Microsoft: "You've got questions. We've got dancing paperclips."
Most people are unaware of the work going on as part of Xen for support of Trusted Computing. The Security Enhancements for Xen project is working on integrating the TPM into Xen so that virtual machines will get "measured" (hashed into the TPM) and Xen can report which VM is running using Remote Attestation. This way if someone hacks their VM, remote parties will know about it. Other technologies related to this include Intel's Trusted Execution Technology (aka LaGrande Technology) which adds security beyond the TPM to really lock down the machine. See this mailing list thread for discussion of the recent patch adding TXT support to Xen.
Personally I think this is fine and can really increase the security and utility of virtualization. But particularly with the recent release of GPLv3 and controversy over trusted computing it is interesting to see Xen moving in this direction. I imagine that it means that Xen will stick to GPLv2.
If you were redhat why would you buy? You can get the product for free. There's no sense in buying the company.
Funny this should come up today - I just spent the weekend playing with Xen, trying to combine a couple of my household servers to get better utilization and to save power.
I've been playing around with VMWare since it initially came out, including a production install of v4.5 at work to virtualize NT4 machines so that our LAN goons won't complain, and I've always found it extraordinarily easy to use. From a "get it running" perspective, the damn thing's idiot-proof. Fire it up, boot off some install media (even if it's Knoppix, and you're going to image the system from elsewhere), and you're golden.
Xen? Eh, not so easy if you're not starting with a clean install of a Xen-aware OS. Lots of hours screwing with configurations, swapping kernels, messing with pygrub, and scratching my head as to why it wasn't doing anything, or was crashing with some cryptic error. Some of this is a result of the paravirtualization approach, as it requires some guest changes, but nobody's really published a good, generalized guide to native->domU migration. (Yes, I know about the CentOS one, and while it was some help, it was also wrong at some points, as it's never been updated for a CentOS 4.5 domU.)
My take is this - the (non-Xen) tools bundled with RHEL5 (well, CentOS 5, really) are, um, overly simplistic at best and completely unhelpful at worst. Graphical tools be damned - by the end it was me, the text editor, and xm on the command line.
I did get it up and running, and when given its own disks, the performance is impressive. It (unscientifically) *feels* faster than a Linux VM on Linux-hosted VMWare (desktop version). Now my web/mail server and house/firewall server have been combined. Tonight, I'll collapse in one more server. I'm quite confident I can do it in a reasonable amount of time, now that I've figured out most of the gotchas. Plus, sounds like a good thing to document and post so that others might not have to fight through quite as much as I did.
In an enterprise environment, the management tools make or break you. When I'm managing a handful of machines, doing it myself is annoying but acceptable. When I'm virtualizing a datacenter and need tools to convert machines, manage their resources, manage their operations, etc., then management toys become the make-or-break part of the deal. We all assume your virtualizer works - now let's see what makes our lives easier managing this strange new world.
I tried all of XEN, VMWare, KVM and VirtualBox on AMD X2 5000+ Linux, eh... GNU/Linux host, with a dozens of different guests platforms running in it. And I found XEN the least suitable for desktop end users for technical reasons, with VirtualBox the best and friendliest at the same time. On servers maybe XEN could catch but it is still a technical nightmare.
At the moment, not many users have good hardware for virtualisation but that will change in 2008 and I give XEN not so much chances to get major market slice.
There you are, staring at me again.