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."
Umm, I read the (short) posting, and it does not mention Novell even once. This is just slanderous, because boohoo Novell wants to steal all of our money? Come on, that's just a lame write up.
Why not just sell out to a company like Red Hat?
...where fending off Microsoft and IBM is a piece of cake.
You are being MICROattacked, from various angles, in a SOFT manner.
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.
See, when companies make one section open source and the other section closed, not much is gained; just make it all closed if you care so damn much. Or, write your own restrictive license that gives you all the revenue, as almost nobody but me reads the licenses.
FUCK FUCK FUCK
And propsers. As does Mozilla.
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
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.
Starting a project as GPL is probably best because you'll get an idea how useful your application can be. It definitely makes it really hard to make money until you can run a Free red-headed step-child project and make people pay for the commercial version that's the belle of the ball. Another way to do it is to limit the GPL-ness of the project. Maybe by dual-licensing the code?
It's still not easy though. Getting customers to open their wallets when there are much bigger companies like RedHat and Microsoft is tough anyway. That's why sales people are so valuable.
I want to believe frustrations got the better of the person in question at that moment.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
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.
Their reasoning, which makes sense to me, is that they are afraid their hard work will be lost if Redhat or other commercial vendors can just include it in their distro and make sales based on it. Makes sense to me.
Wonder how this is done? This sounds like it would hinder the efficiency Xen. Besides who know's what architectures will be around in 10 years. I'm guessing it's not going to be a hypervisor anymore like VMWare, but more like VirtualPC which emulations the targeted architecture (perhaps both).
Without this I seriously doubt I'll be able to take a Xen x86 system image and put it on a "PPC 2017" system, or whatever processors will be popular then; without some form of emulation.
I mean come on, those are just the most ridiculous jumping puzzles ever.
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.
Either way Linux wins.
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.
Source is the engine for Half-Life 2, while Xen was only in the original Half-Life. The name should be "XenGoldSrc."
What?
Rob
But don't let the facts keep you from voicing more opinions.
It's funny if you think about it. Any company with a killer app can take Red Hat Enterprise Linux (or Fedora, (Open)SuSE, Ubuntu, or any of the others for that matter) and bundle it with their stuff without mentioning origin. That's the beauty in the GPL, you give and can take. In fact you can take without giving anything at all (with limitations), but that doesn't means that you should behave that way.
Yep, this incident can't possibly happen. All FOSSie companies are happy happy joy joy nice kumbaya-singing granola-eating people, who, um... just... happen to be profitting from the work of people they don't actually pay for...
Nothing to see here, move along!
Red Hat will probably switch to KVM soon, using Xen only for backward compatibility. By calling it "Redhat Virtualization" they can partly conceal the strategy change.
As to the problems with making money off of FOSS. Well yes it isn't always easy and frankly I don't believe in FOSS as a universal solution for all software problems. It is great in some areas but I think is far from the universal solution that RMS and the faithful believe.
This brings up an area where I prefer BSD type licenses over the GPL. I love photography and would like to program a compleat photo/graphics suite including editing, a db for inventory and photos, and a billing module along others. However if I were to work on an app for this I'd want to be able to be sure I could make some money selling it if I were to spend so much tyme developing it before someone else started making money off it, yet still have at least some of the source open. BSD allows code to be closed so long as all of the original authors are credited from what I understand. If I'm wrong on this could someone reasonably correct me? However the GPL says all of the GPL code has to be open.
FalconShould there be a Law?
I just made a quick check and found a download site with 1000 image editors. How many open source applications do you need? There's GIMP and Krita and... honestly, I can't think of a third one.
I've got a few more bookmarked. As for why there are so many, some are meant to do specific things, run in specific environments, or to edit specific formats. Some, like POV-Ray, are vector graphics editors. Some are bitmap editors. Some are 2D and others 3D. Some only run on Y OS in Z like Krita is for KDE. There are a number of reasons there are so many different FOOS image editors.
FalconShould there be a Law?
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.
...the need to prevent Red Hat, IBM or Novell from running away with all the business revenue. I think the idea of marketing and working with OSS is that level playing field and participation with the community.Competition under those rules implies that there's some out there for everyone. For too long we've all been operating under this ridiculous notion that success is measured by "growth." What if people were measured that way too? We'd all be failures somewhere between 16 and 22 years old!
RedHat isn't out there trying to "dominate" the market. Novell isn't out there "crushing" the competition. IBM isn't out there choking the life out of the other players on the field. Competition doesn't mean "kill and consume everyone else." (Someone said they were surprised that Microsoft wasn't being demonized in this... well, don't be surprised because here I go! It's the Microsoft mentality that has shaped our expectations that "competitiveness" includes carnivorous behavior.)
You don't see RedHat complaining that other Linux distros are also using RPM do you?
Competition on a "level" playing field means that everyone is contributing and that your customers will not change or move on unless you aren't delivering what they want or need... something someone else is willing to do.
I'm using KVM (yes I gather it is mostly Qemu) rather than Xen or VMware. Is there a compelling reason to use Xen over KVM?
Semi-automatic amateur armchair Australian philosopher; conjecture ready at any moment...
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.
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.
Yes indeed, and sadly that is a lesson that the XenSource people don't seem to have learned.
They have virtually abandoned the Xen hypervisor code to focus on their closed enterprise offerings, as a result of which it's rapidly becoming obsoleted by KVM and OpenVZ and others. And once Xen no longer has the unique property of being the only fully working virtualization technology, XenSource will suddenly find themselves with a dramatic decrease in customer base.
And it's all of their own doing. FOSS is not a free ride to the bank. You have to keep working at the code, and you have to maintain good community relations, as you say.
It's not too late for XenSource to turn things around, but they'd better start yesterday. As things stand, their competition is not going to be RedHat, but KVM et al, which incidentally will also be supported by RedHat no doubt.
XenSource seem to be too close to the trees to see the wood, let alone the approaching forest fire.
Say you develop a photo-editing (or whatever) piece of software and release it under the GPL. Then you add a few new features and decide to start charging money for a closed-source version with more functionality. No problem! That is just fine.
Ok, thanks I didn't know that. What if I were to take another GPL software like Inkscape and add a billing module, could I close source the module?
You see the difference? If it's your code, the GPL doesn't keep you from doing anything you want. The only thing it restricts is what you can do with Joe's code. Joe was nice enough to give you his code for free; why should you be allowed to charge other people for it?
Maybe it wasn't obvious in my previous post but in reverse that's what I was concerned with. Someone else taking my code then selling it, with or without bug fixes and such, without me seeing any money. Afterall why should I program some software if I can't try to make some money? I could be spending my tyme on something else like scuba diving and photography. See, I'm not a nerd sitting in a basement banging out code day in day out. While I don't work because of a disability, I love doing other things such as the aforementioned scuba diving and photograhy.
By all means, continue disliking the GPL (I certainly don't particularly like it). But please do so for the right reasons.
I never said I didn't like the GPL, what I said was I prefered the BSD style licenses. Appearently though, from what you say the GPL does allow me to do at least some of the things for which I prefered the BSD.
If you really wants to be able to sell (software including) his code, you can ask him for special permission to do so.
You don't need "Joe's" permission to sale software with his code do you? I thought the GPL just prevented you from taking his code and closing the source, you had to include the code source if you distributed it. If you can't sale the software then I was ripped off when I paid for RedHat years ago. How do all these companies get away with violating the GPL by selling software?
FalconShould there be a Law?
I have servers running xen fine. but the situation with xen bothers me: documentation is bad, support on mailing list nearly dead, and xen always uses some old outdated linux kernel as base, so I never know if recent security updates made it into the xen kernel. So I wonder: is any of the alternatives ready to replace xen servers? kvm or lguest?
I'm running linux below linux without hardware paravirtualisation support. or what about virtualbox - would be a much better vmware alternative.
on the other side xen absolutely rocks when it comes to integration. I don't need to think about the xen server in domU on my laptop - I stop, start and reboot my laptop as I see and the xen domain is always fine with it. not sure if the alternatives have reached that level yet.
I'm a happy xen user in a (mid-sized) corporate environment.
I'm using it for linux fileservers (not data storage), mail relays, mail servers, web servers, vpn routers, etc etc
It has been running very stable for me (I use Xen on Debian)
The primary reason for me to use xen is for disaster recovery. Not for consolidation necessarely.
My domU's are running on LVM2 partitions, every day I make a snapshot, tar/bzip it, and archive it.
This way I can deploy my serverfuntionality on whatever xen server in the company, (when domU migrating is not an option) within minutes, which I have done more than once.
As far as graphical management tools. Sure, they are missing for someone who depends on graphical management interfaces. It's not an issue for me. When it comes to administrative work, I don't like gui's, I'm comfortable using a cli but hey that's just me. I don't want to be a linux/*nix fanatic here, but linux/*nix has always been about the command line. While some people think this is a weakness, I think this "weakness" is its strongest point.
Command line system administration obliges you to know what you're doing, while a gui often tends to be an abstraction layer between performing complicated tasks and have little or no experience.
I do admit that in order to compete with vmware, xen will need to have some serious gui attention in order to be picked up by the mainstream, at least we can make some cool screenshots of xen *sigh*
Yeah, we certainly wouldn't want users to have a better experience.
Free software is about the users; proprietary software is about the programmers.