By Dennis E.
Powell, LinuxPlanet
The same week that smoldering hostilities in the GNOME
development community burst into flame with the angry resignation
of a GNOME 2.0 release coordinator, a longtime KDE developer has
opened fire on that desktop project. The two desktops have long
engaged in heated competition, which now seems to entail which can
do the most damage not to the other but to itself.
Both disputes highlight potential problems in large development
projects staffed in whole or part by unpaid volunteers, and the KDE
dispute underlines the ambiguities surrounding the rights of
individual developers involved in such projects.
In a blistering commentary on his home page, Daniel M. Duley,
known as “Mosfet” in the KDE community, charged that the KDE-2.2
release manager, Waldo Bastian, had asked him to remove his code
for Duley’s “Pixie Image Management System” from the KDE CVS tree,
but when Duley removed some otther items he had written, including
popular (and in one case the default in many installations) themes,
Bastian added it back without Duley’s permission and revoked
Duley’s CVS access.
“Well, it seems that the KDE project has decided to both fork my
code, against the author’s wishes, and include them unmaintained
back into the KDE libraries,” said Duley. “This is a regretable
circumstance, and I think reflects very badly on the KDE project
itself. Of course they have the right to fork whatever they want,
but usually when you do so it’s to add features. In this case it’s
not – it’s because they simply want to include things that I (the
author) do not into KDE CVS where I would ratherwrite and package
them independently. I think the crass behavior shown in this should
serve as a warning to all free software developers.”
In response, Bastian issued a copyrighted email message on the
kde-devel mailing list in which he said he bore Duley no ill will,
but found him ill-suited to a KDE-type development effort — and
pointed out that KDE has rights to Duley’s code.
“[B]y putting your code under and open source license and
putting it in KDE CVS you give the world at large, as well as KDE
in particular, the irrevocable right to use your code,” Bastian
wrote. “And KDE will use that right at its discretion to protect
the interests of KDE, even if that goes against the wishes of the
author at that point in time.
“To relate the above to the recent actions by Daniel (aka
‘mosfet’). I don’t think that Daniel accepts the responsibilities
that come with having code in CVS and therefor I believe that it is
better that from now on Daniel will develop his code outside KDE
CVS. In that light I have asked Daniel to remove Pixie from CVS.
Pixie is cleary primarily developed by Daniel and there is no
point in keeping a version of it in KDE CVS when all further
development will be done by Daniel outside KDE CVS. I haven’t asked
Daniel to remove any of its other code because this code is clearly
an integral part of KDE. Removing it would harm the interest of KDE
and its users. Removing such code can not be allowed.”
Bastian charged, and Duley admitted, that Duley has achieved a
reputation among KDE developers for appearing with new code just
before a major release and arguing for its inclusion. KDE-2.2beta1
is scheduled to be tagged for release before month’s end.
The public eruption had been building for several days following
Bastian’s request that Pixie be taken out of CVS. And it became a
public dispute as dissention among GNOME developers over the
direction of GNOME 2.0 flared, with the resignation of Martin
Baulig, the GNOME 2.0 release coordinator, in what apparently was a
dispute with Ximian, Inc., the surviving GNOME-based corporation.
This led to unexpectedly harsh words from a leader of the Linux
development community, Alan Cox.
“Thats why I’m now mostly using XFCE,” wrote Cox in a post to
the GNOME-hackers mailing list. “Its no longer about building a
cool environment; its about a small number of companies trying to
screw each other.
“Fortunately for GNOME most of those companies wont be here in
12 months time because they don’t have a credible business model.
At that point it will be interesting to see how people work
together again.”
The disputes among the two largest Linux desktop projects are
concrete examples of questions that have been raised in the
abstract as Linux’s size and influence has grown: To what extent do
developers have control over the implentation of their own code? Is
there a place for the work-alone developer in large projects? Can
permission to use a developer’s code, once given, be withdrawn?
And in a broader view: How large a project can be successfully
undertaken by unpaid developers? Is it inevitable that past a
certain point, factors other than the immediate task at hand govern
the progress of a project?
These questions have been mulled for years without any answers
forthcoming. If the disputes within the desktop development
communities are indicative of a trend, those answers may soon be
urgently needed.