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.
to post comments)