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.
Yes, I realize you're not saying that Xen copied, but that Open Source in general copies. Xen is a great counterexample.
The Raven
Microsoft: "You've got questions. We've got dancing paperclips."
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.