Once upon a time, just over one year ago, the
Compiz window
manager
hit
the net. Compiz, which features fancy 3D effects, was the result of
some months' worth of behind-closed-doors work at Novell. There was an
enthusiastic reception, and others began to hack on the code. It didn't
take long, however, before some of those others found that it was hard to
get their changes back into the Compiz mainline. Eventually one of those
developers, Quinn Storm, got tired of carrying an increasing collection of
external patches. The result was a fork, and the
Beryl project was created.
These events can be acrimonious, and the Compiz/Beryl fork was no
exception. Beryl developers complained that Compiz was run as a Novell
fiefdom which was uninterested in patches from the outside. On the Compiz
side, Beryl's decision to relicense the code from the MIT license to the
GPL meant that code could flow from Compiz to Beryl, but not in the other
direction. In early 2007, a Compiz site administrator vandalized Beryl's site, an
act which must surely mark a low point in relations between the two
projects.
During this time, development on both sides continued, with Beryl quickly
developing a reputation for bells, whistles, and an unbelievable number of
configuration options. Compiz took a more conservative course, working on
getting the core functionality working in a way which seemed, to its core
developers, to be right. Despite all of this, the differences between the
two code bases are apparently less than one might think. No major
architectural change have happened; instead, most of Beryl's additions come
in the form of plugins.
Recently, though, the Beryl developers started to ponder some more
sweeping changes. According to Robert
Carr, the conversation went like this:
Around a month and a half ago some of us were discussing some
rather radical changes to the design of beryl-core which we
inherited from Compiz, this inevitably led to "We should talk to
Compiz about this to keep things synced", which even more
inevitably leads to "If we are going to talk to Compiz to keep our
designs similar, so on, so forth, are our differences really so
large that we need to be two seperate projects?".
The result was that the two projects started talking again. As of this
writing, it would appear that Beryl and Compiz have come to an agreement to
end the fork and join back into a single project. Should things happen
this way, the results for eye-candy fans should be good. There are a few
details which need to be worked out first, though.
One of those is licensing. The fact that Beryl's work is licensed under
the GPL means that, for the two projects to merge, one of them must be
relicensed. It looks like Beryl will be the one to give here,
moving its core back to the MIT license. The number of contributors is
evidently sufficiently small that this sort of change is still feasible.
Then there is the issue of how to merge the changes in the code. According
to Mr. Carr, agreement has been reached on most points, at least with
regard to the core changes. In the past, Compiz leader David Reveman has
not been receptive to Beryl code:
With a few notable exceptions, most of the code I've seen going
into what is now beryl is not high quality code that would be
considered for compiz.
It seems that the situation is different
now:
The technical part of the merge seems pretty straight forward from
my point of view and I've got the understanding that so is also the
case for the main contributors to the core of beryl.
The merge is probably helped by the Compiz
project's plan to split the code into "core" and "extra" modules.
Much of what is currently in Beryl will, it seems, slip into compiz-extra
with little trouble.
So if licensing and code are not problems, what are the potential sticking
points in this merger? It seems that there are two of them: naming and
leadership. The Beryl side is pushing for a new name and structure which
would enable a clean start for the entire project. Without that, they
fear, one side or the other will probably get the short end of the stick.
Mr. Reveman responds:
The merge is done by moving changes made to beryl into compiz or by
adding alternative solutions to compiz. No changes are made to the
design of compiz and 99% of the code is still code being written as
part of the compiz project so I'm having a hard time to justify a
name change of the core and I know that most people in the compiz
community are firmly against such a name change.
From reading the discussion, one gets the sense that the leadership issues
have not yet been the subject of serious discussion. Some sort of project
management model will have to be worked out, or the newly merged project
will run a risk of falling victim to the same tensions and forking again.
There should be an answer, though.
It would be a sad day if these two projects could come together, resolve
their technical and licensing differences, then drop the whole thing
because they cannot agree on the name. Some great progress has been made
on reunifying one of the most unpleasant forks in our community; it seems
like the remaining issues must somehow be amenable to a solution.
(
Log in to post comments)
