Slashdot Mirror
Has GNOME Rejected Canonical Help? Shuttleworth Responds
akgraner writes "When Canonical made the decision to make Unity the default desktop, some questioned the GNOME/Canonical relationship. Adding fuel to this fire was the recent distribution split of revenue generated by Banshee. These decisions caused the Ubuntu, GNOME and even Fedora community members to ask why these things were done. In Dave Neary's 'Has GNOME rejected Canonical help?' post, he states, 'I have repeatedly read Canonical & Ubuntu people say, "We offered our help to GNOME, and they didn't want it."' Neary gives examples in his post of what others have said to back up the 'they didn't want it' claim by Canonical and Ubuntu people. Today, though, Shuttleworth responds on his blog. 'Competition is tough on the contestants, but it gets great results for everyone else.'"
Some of us disabled users are looking for an alternative operating system for our Windows XP netbooks. The compiz magnifier is great, but GNOME is the _only_ desktop environment that has a screen reader. The GNOME screen reader performs _very_ slowly on a netbook though. It even runs slow on a modern system sometimes.
My point? Can we stop with the political issues and try to just produce the best, stable, reliable system we possibly can? Can we stop changing the underlying components every two years? Can we stop changing things that don't make the system any better (like notification bubbles that require more daemons) and fix what we do have?
also, this is not an odd "oops, we just didn't get around to it" event on the part of GNOME: how's that job D-Bus implementation in GNOME 3 coming? you know, the one that needlessly duplicates the one KDE implements, which we actually designed with thought of cross-project use including getting some feedback from non-KDE devs? or how about the screensaver D-Bus API which we implemented specifically with collaboration with GNOME devs at SUSE, only later to have GNOME not implement it and then complain to us that it used the org.freedesktop namespace? or how about how GNOME devs specifically blocked the formation of a common git repository for fd.o specs, and then when there was finally agreement (after an in-person meeting) insist on implementing it themselves, ignoring that repo had already been started but by people with @kde.org email addresses, and then after taking months to eventually duplicate that effort not implement the most critical part of it: the metadata?
Shuttleworth notes to that end, "Weâ(TM)ve failed." He adds, "Much of the language, and much of the decision making Iâ(TM)ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome."
There was a story on The Register today on why Nokia failed. They had the exact same problem - teams that should be working together are fighting against each other and in the end just losing together. That seems to be a large problem in OSS community too, and it's no wonder Nokia had it too (they had many Linux developers). But when a software company, usually proprietary, is ran good, it doesn't suffer such problems as management makes good decisions and gives orders. That is why Windows works good and why the quality is consistent.
Infighting in Microsoft is why we didn't get clear-type for over 10 years after it was available... (Clear-type is the software that gives fonts 3 times the horizontal resolution on LCDs) The Office Suite devs wanted it for their own -- to boost their own team's importance, and refused to fix the the MS Office font system to work with clear-type unless the clear-type devs were placed under the Office Suite team's umbrella.
This is just one small example of MS infighting stifling innovation. Please take your closed source software down from the pedestal. Management is the problem -- That, and a "not invented here" mentality. It can happen anywhere.
Ubuntu and Gnome are diverging because they each have their own goals and any interference with one's goals is not tolerated -- I've found that true collaboration basically requires an alignment of our goals -- Seems to me like human nature.
The difference is that when Canonical and Gnome bicker, I can still use the features that they independently develop... I'm not stuck waiting for 10 years (like for Windows clear-type).
@Lennart: "If you list this notifier spec, then I can list you the sound theming/naming specs which KDE has shown no interest in."
:)
... simply to provide compatibility. would GNOME devs do that today? doubtful, because our priorities, as you point out, are indeed different.
that's an incorrect comparison.
if we (KDE) had offered a bunch of critique on the sound theme spec, had someone come to us with an implementation in Qt and then still gone off and done our own thing instead, then it would be an adequate comparison. but that isn't what happened, is it?
we (KDE) simply haven't gotten around to implementing the sound theming spec. why? as you note, it's not a high priority for us. but i guarantee you that if someone stepped up to do some work on the event sounds infra in kdelibs, stop #1 would be that naming spec.
also, this is not an odd "oops, we just didn't get around to it" event on the part of GNOME: how's that job D-Bus implementation in GNOME 3 coming? you know, the one that needlessly duplicates the one KDE implements, which we actually designed with thought of cross-project use including getting some feedback from non-KDE devs? or how about the screensaver D-Bus API which we implemented specifically with collaboration with GNOME devs at SUSE, only later to have GNOME not implement it and then complain to us that it used the org.freedesktop namespace? or how about how GNOME devs specifically blocked the formation of a common git repository for fd.o specs, and then when there was finally agreement (after an in-person meeting) insist on implementing it themselves, ignoring that repo had already been started but by people with @kde.org email addresses, and then after taking months to eventually duplicate that effort not implement the most critical part of it: the metadata?
in contrast, we could see how KDE implemented support for the visual notificatons D-Bus protocol as implemented in GNOME, even though it has evident limitations and is a 100% subset of something we already have in the form of KNotify
what GNOME needs is not more apologists making excuses for poor behavior but people who will stand up and take ownership of their actions.
Jesus had a UNIX beard.