The XGL development model [LWN.net]

XGL is a version of the X server built on top of the OpenGL API. Many developers see the XGL approach as the way forward; as video hardware becomes increasingly 3D-only, OpenGL offers a uniform way to drive that hardware. Once an XGL server becomes available, the door will be opened for all kinds of fast 2D and 3D applications.

As it turns out, there is a paid development team working at XGL; these developers are hosted at Novell. This work is being funded with the apparent idea of upgrading the free XGL server and benefiting the free software community in general. So it is interesting to see a significant amount of criticism of Novell's work in the desktop community.

The problem comes down to this: all of Novell's work is being done in-house, using a private repository. The wider community knows that this work is going on, and has some idea of what has been done, but none of the resulting code has been seen beyond Novell. The best description of what is happening - and the reaction to it - can be found in Aaron Seigo's weblog. There we see that the non-Novell developers who would like to hack on XGL are frustrated. They know that a number of problems have already been fixed by Novell, but the code is not available. They fear that much of the work they are doing will be duplicated by what the Novell team does. They feel locked out, and wonder about Novell's reasons for taking this approach.

Everybody seems to assume that Novell's work will, eventually, see the light of day and be contributed back - though the X license does not require that. But that release will confront the community with a large dump of corporate code. It will not have been reviewed by anybody outside of Novell, it may well incorporate design decisions which are not acceptable to other developers, and it is likely to duplicate and conflict with any work done by the rest of the community. The possibility that Novell will hold the code until it has packaged it into a SUSE Linux release is also somewhat annoying.

In the absence of a statement from Novell, one can only speculate on why this approach is being taken. It is possible that Novell is just trying to avoid dealing with developers who oppose the XGL project in the first place. At the moment, it is almost impossible to use XGL without proprietary drivers; developers who feel strongly about avoiding proprietary code would thus rather take a different approach - and they have been rather vocal about that. It is also possible that Novell is simply looking to "get the job done" its way, without the distractions of dealing with the community.

This situation should work out in the end, once Novell releases its code and the process of merging begins. At that point, with luck, the X community will have a much-improved XGL server to work with. But the memory of having been locked out of the process will persist for some time. One can only hope that this code release happens soon so that the next phase can begin.

(Log in to post comments)

The XGL development model

Posted Dec 22, 2005 6:22 UTC (Thu) by airlied (subscriber, #9104) [Link]

I'm one of those locked out developers, I've long had interest in getting Xgl and more specifically (Xegl) going but not enough spare time to contribute in a massive way, however I've always planned to make time over Xmas this year to get the Xegl working on my r300 based laptop using open drivers.

The fact that Novell is sitting on code that is orthogonal to what I am going to work on (as far as I know they have no-one going to work on Xegl, its all Xglx with stacked servers), but to get Xegl to a working state I've got to fix up a lot of problems in the public tree that the Novell developers have already told me, they've fixed and it'll be available soon, soon being about 3-4 months now and holding...

It just gets very frustrating, I don't think they care about developers criticising the Xgl idea over any other, I think it is really just some stupid wanting to make a big splash in Novell Desktop with a GNOME desktop customised to it, and leave KDE (two developers of which I also know are locked out from the code base) looking less cool... I don't really care about the DE, I want to provide open drivers to use Xgl so people can use it on non-proprietary drivers and open development up to people who can't/won't run proprietary drivers..

The XGL development model

Posted Dec 22, 2005 7:34 UTC (Thu) by airlied (subscriber, #9104) [Link]

I personally have met the developers and don't think they would've done this project for Novell if it wasn't to be open sourced, the intentions of these developers has always been to open source Xgl, I doubt Novell has changed that. It just seems more Ximian pushed than big Novell pushed. I'd like to hear what Nat Friedman has to say, but his silence on the topic probably says he might be the person doing it.

And as the code is MIT/X licensed, they can always do in-house stuff once the core architecture is done.

The XGL development model

Posted Dec 22, 2005 8:53 UTC (Thu) by csamuel (✭ supporter ✭, #2624) [Link]

Bruce writes:

For some reason I am reminded for Corel and KDE. There never was a merge.

Hopefully it'll be more like Apple and KDE where, even though there was a bit of pain at some stages, they did merge code back into KHTML for the benefit of all.

The XGL development model

Posted Dec 24, 2005 2:42 UTC (Sat) by drag (subscriber, #31333) [Link]

I don't think that it's likely that Novell would be pursuing a propriatory 'value' angle given there history. After all they are the ones that openned up Yast and removed the main 'propriatory value add-on' features of Suse. Also they've openned up numerous software projects and code such as Hula and the like.

It makes sense that as far as X server goes they would want to be open as possible because for 'ISV' attractions to Linux you going to have to use stuff that is supported accross the board. The likelihood of Suse attracting ISV's to itself while reducing feature compatability with Redhat, Debian, and pretty much the rest of the world is pretty unlikely.

I beleive they will release the code, and release all of it.

What I do think however is that it's VERY likely that Novell has entered into NDA's with multiple 3rd parties.

Most likely, I figure, they are getting Nvidia's and/or ATI's to design a driver framework and getting help with some of the memory management issues in X drivers.

Also there is the deal with standardizing OpenGL EGL's extensions. When you look at the OpenGL 'archatectural review board'.. You have IBM, Apple, 3DLabs, Dell, Intel, Nvidia, SGI, and Sun Microsystems.

Many of those companies are not the most open (to say the least) and a few of them is going to maintain their own propriatory OpenGL implimentations that are going to remain closed come hell or high water. Like it or not if your going to build a OpenGL X server on Linux, your going to have to deal with them if you want it to work with more then a fraction of the end users.

I don't know in the past what sort of discussions and their openness revolving around OpenGL standards and whatnot, but I'd bet that NDA plays a large role until the actual specifications are released.

I know also that in the past Novell hasn't had problems throwing around the old NDA itself, even with free software. And some drivers such as the nv involve NDAs.

Of course this is just pure speculation. We won't know until Novell actually releases the code, which I still think they will do.

Not that I like it, though. I think its going to cause problems with this closed behavior. Both in public relations, in developer releations and for technical reasons.

The XGL development model

Posted Dec 22, 2005 7:46 UTC (Thu) by kleptog (subscriber, #1183) [Link]

Well, there are two ways this can go. Novell eventually releases, it gets hacked into shape and released.

Or some group gets fed up, hacks the public code into shape, merges it with X (so it makes incompatable changes to what Novell is working on) and makes a public release and Novell's private work turns out to be wasted (or at least difficult to merge).

That said, I don't understand their attitude. Maybe they're working on their own snazzy features they want to keep to themselves. But to hold back bug-fixes just seems anti-social.

The XGL development model

Posted Dec 22, 2005 10:51 UTC (Thu) by Duncan (guest, #6647) [Link]

I've a strong feeling a move to GPL xorg would go over about as well as
the move to add the advertising clause to xfree86 did... resulting in the
split.

Xorg is MIT licensed for a reason, and I seriously doubt the BSDs and
perhaps certain other private interests (slaveryware Unix, altho they are
a dieing breed and now just depend on xorg, for the most part) would be
interested in that changing. Xorg got virtually everybody on board to
maintain the MIT licensed one, and even if there were some theoretical
interest in a GPLed version, I don't believe anyone involved is interested
in going thru another split over the issue, so it's not going to happen.

Duncan

The XGL development model

Posted Dec 22, 2005 12:37 UTC (Thu) by airlied (subscriber, #9104) [Link]

Yes we still raise it as a theoretical over beers, and apparently when the XFree86 crap went on, a number of companies seriously thought about just forking the whole lot into a GPL tree, lucky enough the X.org Foundation picked up the ball, but if that hadn't come about, a relicensed GPL X server might have actually happened.

At this stage unless something seriously goes wrong with the X.org model I don't think there'll be any real talk of doing anything of the sort. I'd personally like to fork my private X server and remove all support for anything backwards compatible or old world just to see how small the source tarball would be :-), but kdrive is pretty much down that road already.