The XGL development model

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.