

Analysis of the conflict among Canonical, GNOME, and KDE - sciurus
http://blogs.gnome.org/bolsh/2011/03/11/lessons-learned/

======
tytso
The key problem is that the desktop community desperately needs one or more
architects who can act as a sheepdog and keep the sheep marching in roughly
the same direction.

It's far more critical in the Desktop world than in the Linux kernel because
in the kernel, there is enough development in the kernel that there is strong
incentive to develop in the upstream sources, and not behind distribution-
specific source trees. In addition, the Linux kernel releases on a regular 3
month cycle. So even if we don't have formal design documents, it's a lot
easier for collaboration between key kernel subsystem developers, because our
patches have to come together and _work_ every three months when we push out a
release. (In practice, they had better mostly work by the end of the two week
merge window, or there will be hell to pay, and Linus, as the great benevolent
dictator, will yell at people, and Make a Decision --- which will usually
involve reverting the change which broke things functionally.)

In contrast, the Desktop world has a much harder problem, because (a) not
everything lives in one source tree, (b) the kernel largely doesn't have a UI,
and there are objective measures of "does it work", and "did the benchmark
results go up or down", that either don't exist or aren't as important in the
UI world. Questions of whether a UI is "good" or "better" than some other UI
choice is a question which can't be easily answered objectively. And that,
more than any thing else, is probably why we have three major design centers
for desktop development: GNOME, KDE, and Canonical.

One of the things that worries me is that all too often, people look at the
way things are done in the Linux kernel, and assume that it will port over to
their project. In most cases, the Linux kernel is a much larger and more
complex project, and things which we do in the Linux kernel world probably
aren't needed in other projects. But in the Desktop world, I think the reverse
problem is true. It's a much larger and more complicated ecosystem than what
we have in the Linux kernel, and so decisions such as allowing the major
subsystem developers to negotiate major technical changes organically and
informally might work for Linux, but not in the desktop world. (For example,
in the storage stack, there are less than a half-dozen people I would need to
consult with in order to come consensus about some change to accomodate PCI-
attached flash, and we have multiple opportunities a year to get together and
work things out). Hence in the desktop world, hiring a full-time architect who
did nothing else but talk to the different stakeholders and try to come to
consensus on a common vision is probably something which is necessary, even
though we haven't found the need to have someone in that role in the Linux
development community.

------
mycroftiv
Posts like these really show the problems in the current free software
development world; balkanization between different stakeholders and bizarre
processes that alternate between bureaucracy and anarchy. Watching the tug-of-
war between Red Hat and Canonical play itself out in the form of dysfunctional
community development process is depressing. I'm aware that watching sausage
being made never makes you very hungry, but as a user of free software, I
don't feel my needs are served very well by the territorial and political
battles being fought.

What makes it even more frustrating to me is that not only are KDE, Gnome 3,
and Unity all failing to cooperate successfully on shared resources, but they
are all marching resolutely in the wrong direction, regardless of the pleas of
the user community. So far as I can tell, everyone hates Gnome Shell, everyone
hates Ubuntu Unity, and everyone thinks that KDE 4 has been a big mess
compared to KDE 3. I see all of these projects as engaging in a slappy fight
as they march together off the cliff of unusability and misguided redesigns.

~~~
fingerprinter
I think to be fair to all three, you have to give them six months after they
are actually released before we judge them. As is typical in OS Linux
community, a very vocal minority is probably speaking up and "hating" all
three. I would wager that the majority opinion is much different than what you
hear from the vocal minority.

~~~
bobbyi
KDE 4 was released in January 2008.

------
mpyne
As a KDE developer myself, I have to admit to being very disappointed by the
very first section regarding the development of the StatusNotifier
specification. Dave complains that there was no problem statement, points out
a quote relating to D-Bus, and somehow still entirely misses the point even
after claiming to have read through the threads relating to the proposed spec.

The problem statement is _easy_ : Have a way of separating notification items
and applications, such that the notification item is part of the desktop and
not part of the application. In other words, XEmbed sucks as a way to have
notification items in a system tray. Anyone who has ever used e.g. GAIM in a
KDE 3.5 desktop with a pixmap background knows exactly what I'm talking about,
as GAIM's icon would show up as an ugly box with an icon inside, while the KDE
application's would have a notification item with a properly transparent icon
drawn.

Claiming that the entire idea was merely to hook up notifications into D-Bus
is so far afield that it mystifies me completely, and claiming that _no one_
has ever had issues because of this is patently false. In fact, the __VERY
EMAIL __[1] that Dave quotes has an _actual problem statement_ directly before
it:

<quote> In the past few months in KDE we worked on a new way to represent the
systemtray icons to overcome the following limitations:

-lack of communication between the systemtray area and the items, that mean we don't know about their status, their importance of if they are being used or not

-the xembed process is quite slow and doesn't give control to the systray on the paining

-it's not possible to have more than one systray (useful in multi monitor setups)

</quote>

I know this because I actually bothered to use GTK+ and GNOME software even
with my KDE desktop, but now I wonder if Dave has ever tried the opposite.

I also was passively watching the threads as they happened back in the day,
and stating that there was disagreement due simply to lack of a problem
statement would be flatly false.

Dave then goes on to accuse Aaron Seigo and Marco Martin of being obstinate in
their positions by that point, which simply does not mesh at all with my
memory of things. For instance, A GNOME Panel hacker named Frederic Peters
mentioned that it would be nice to be able to merge launchers with
notification icons [2], an idea that was warmly received, not thrown out [3].

In addition, given that the implementation changed several times during just
the KDE implementation period, there would have been no major problems with
even incompatible changes to fix problems. For instance Aaron Seigo in reply
to Dan Winship recommending a different way to send notification signals over
D-Bus mentioned: "yes, this is a nice idea for limiting the bus traffic. would
require an incompatible change to the spec, but it is doable." [4]

I'll read the rest of the article, but if this is the kind of
"uncontroversial" fact stating that's going to be going on then I'll probably
just unsubscribe from the xdg list and get on with my KDE developing life...

[1]
[http://lists.freedesktop.org/archives/xdg/2009-September/011...](http://lists.freedesktop.org/archives/xdg/2009-September/011038.html)
[2]
[http://lists.freedesktop.org/archives/xdg/2009-September/011...](http://lists.freedesktop.org/archives/xdg/2009-September/011072.html)
[3]
[http://lists.freedesktop.org/archives/xdg/2009-September/011...](http://lists.freedesktop.org/archives/xdg/2009-September/011073.html)
[4]
[http://lists.freedesktop.org/archives/xdg/2010-January/01122...](http://lists.freedesktop.org/archives/xdg/2010-January/011229.html)

------
gord
These problems might take forever to solve [as the organisations are large]...
In the meantime, I wouldn't be surprised if someone came up with a better
technology model as a replacement.

Id like to see a desktop development model more like modern web development -
UI in HTML5/javascript/SVG, json data messaging, UI & system events coming
from a port [eg. shinetech/eventserver], able to write small server-like
plugins in Node.js / C / Ruby / lisp that can provide services and be remoted
away from the UI.

Would be nice if some of this was reusable across OSX/Win/Linux. Perhaps my
desktop work should be done in the browser?

The old unix guys might have approached it this way if they had the current
web at hand to reuse/augment/embellish upon. Maybe this is more in the true
spirit of unix than QT/GTK/Xwindows?

~~~
gord
Can anyone point me to a good architecture/dev overview of Gnome Shell and
Unity ? I find it hard to sift out the marketing from the tech in what Ive
seen.

~~~
sciurus
Unity is a plugin for the compiz window manager.

<https://lwn.net/Articles/430686/> <https://wiki.ubuntu.com/Unity>
[https://wiki.ubuntu.com/Unity?action=AttachFile&do=get&#...</a>

~~~
gord
thx, I do trust LWN to give us the gist.

------
acabal
I'm interested to see how this ends up being resolved (I use Ubuntu, don't
like Unity, and Gnome Shell looks to be just as bad) but have only been half-
following this drama. This is a really great summary post.

I'm totally unsurprised that Shuttleworth's penchant for decision by fiat and
Jobsian cargo-cultishness has driven a wedge between his company and others in
the FOSS movement. (For example window controls, before windicators were
announced: "Yesterday I decided to move window controls to the other side for
our LTS. It's for a secret project. DO NOT ASK ME WHAT THE PROJECT IS."). But
I'm also unsurprised that disorganization and what also appears to be at least
a little ego and maybe even jealousy has warped things on the other side as
well.

------
fingerprinter
"My understanding of GNOME is this: GNOME does not have technical leadership –
it hasn’t had clear technical leadership since, as I understand it, the
creation of the GNOME Foundation (at which point, by design, the board was
given a mandate to build and define GNOME, and then soon afterwards removed
that mandate from itself). The foundation does not now dictate any vision or
direction for GNOME."

This is a huge problem, as I see it. Even in OSS, where you have very capable
people, someone needs to provide direction. I'm reminded of a military story,
which I will paraphrase.

Single most important thing in warfare is to have a known objective. That way
if the person in charge is killed, as is the second in charge, the troops
still know they need to take that hill or everyone dies.

I take the same approach to software and it has worked my entire career. If
Gnome doesn't have a stated vision/objective, it is no wonder it looks like
chaos to someone outside!

Someone from Gnome _should_ step-up and provide some leadership, some
technical direction, some market direction or some general foresight that
things are going in the right direction. I hope the author is wrong and there
is someone already doing this, but if not...

------
jdp23
Great post. Excellent TL;DR summary, and well-articulated details on each
point.

Hard feelings and lack of communication between competing UNIX desktop
environments ... where have I heard this before?

------
dillon
It's so sad that such great ideas are just so dysfunctional.

~~~
jpr
What is the great idea are you referring to?

(not trolling, I honestly don't know what it is that you mean)

~~~
dillon
The idea of free software. It's a vision the Open Source community has that
all software should be free.

------
cgranade
I'm surprised that no one here has yet pointed out that posts like this are a
part of the self-correction mechanism present in transparent communities.
Sure, it may be drama in the short term, but I think the fact that we _know_
about these altercations is an important thing in and of itself. I would be
highly surprised if this kind of drama didn't occur in the proprietary
software world, but we don't get to see it and learn from it.

