Few sensational things happened last week in one of the oldest debates of the Linux community, GNOME vs KDE, touching on the topic of freedesktop.org and joined this time by the new hot topic, "GNOME vs Canonical". The bulk of the actions happened in the comments section of two blog posts, one by Dave Neary (1) , well-known GNOME advocate and another post by Aaron Seigo (2) , well-known KDE Developer. I want to improve my writing skills and the ability to get information from a community discussion. So, below is a step in that direction.
Disclaimer: All opinions are personal and none of the views expressed represent my employer, NASA, WHO or anyone else for that matter. The following is the juice of the events of last week written from a (as honest as possible) neutral perspective. Read through this post if you don't want to read through all the comments in the mentioned blog posts.
GNOME 3 release is just days away. Canonical and the GNOME community have taken different routes with Unity and gnome-shell respectively. Dave Neary wrote(1) a blog post with an analytic title "Has GNOME rejected Canonical's Help ? " . Neary cited instances of Canonical exhibiting behavior that shows discomfort in the Canonical-GNOME relationship.
The main point of contention was: rejection of libappindicator (3) by the GNOME release team roughly an year ago. appindicator is an implementation by Canonical for the management of system tray icons. It was brought under a specification titled "status notifier" to the freedesktop.org. Dan Winship and Matthias Clasen from GNOME have faced some severe issues with the specification and deemed (4) it unfit. The rejection reasons cited by the GNOME release team for appindicator were:
- it doesn’t integrate with gnome-shell
- probably depends on GtkApplication, and would need integration in GTK+ itself
- we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen
- there’s nothing in GNOME needing it
Neary asked for proofs of libappindicator proposal for gnome-shell and any convincing/rejection discussions following the proposal, if any. The openness and accountability of the gnome-shell development process can be known by such proofs.
Aaron Seigo of KDE blogged(2) about the controversy and used the opportunity to vent out his frustrations with GNOME. His post with an inflammatory title of "Collaboration's Demise" seem to indicate that the KDE project has faced severe pushbacks from GNOME for the ideas/standards proposed by KDE. Seigo feels in the last 5-6 years of freedesktop.org operations, GNOME seem to reject ideas based on a (Not Invented Here) NIH syndrome.
As expected, there were comments from GNOME people on Seigo's blogpost, though with a disclaimer that they don't officially respond on behalf of GNOME and are personal opinions. The main counterpoints by GNOME people that I could catch are:
- The idea of appindicators was proposed sometime in 2008. But was not discussed in open after that for a long time.
- Roughly 2 years after that initial proposal and without any open-discussions on the design, a big code drop was requested for libappindicator and proposing it as a external dependency.
- The libappindicator also needed copyright reassignments to Canonical for any contributions. A practice that is being widely frowned upon in GNOME and FOSS projects in the recent times.
The main complaint from Seigo on his blog is that GNOME is deviating from freedesktop.org standards consistently in the last few years and this is unhealthy for cross desktop applications. He feels that appindicators is yet another symptom of this problem. It remains to be seen if this is the personal opinion of Seigo or if the KDE Board/Project too feels the same.
In addressing the events of the past week, Mark Shuttleworth has posted a blog (5) and accused the GNOME leadership (probably referring to the release team and Board, which is unclear from his blog) that the environment in GNOME is not conducive for internal competition. He believes that internal groupism in GNOME is killing baby ideas from anyone outside the group. The tone of the post is harsh towards the GNOME leadership and is filled with advice. Towards the end of his post, Shuttleworth notes that strengthening the partnership with KDE and freedesktop.org is the way forward and is more fruitful than convincing GNOME.
It may be an eventful time in the next few days to see how the GNOME community reacts to this. There will be a blog post by Jeff Waugh for sure, atleast, it seems. As of now, RedHat the biggest investor in GNOME and we expect no change in their stance. Novell seem to be happy with the way things are going in upstream and will stay close to it, it seems. Canonical is toying around with the idea of creating new cross-desktop standards and make Unity more popular. They seem to have appealed to some people in the KDE camp atleast (like Seigo). But it remains to be seen if this newly forged friendship is exposing real problems with GNOME or it is just a temporary sensationalism that will subside soon.
During the next Desktop summit, the GNOME and KDE boards have a huge task of ironing out the difference of opinions between GNOME and KDE people regarding the freedesktop.org processes. I don't know if everyone in KDE camp feel that GNOME is blocking changes in fdo or it is a perception of a few people like Seigo only.
My Take:
+ Most of these problems could've been minimized if Canonical have done their work in GNOME git repositories instead of doing it in their own private space. Nobody likes huge code drops. Doing things in private and opening up later is not a correct behavior in any open source community. They should have learned from the past mistakes like: Novell's gnome-main-menu, Android's Wakelocks etc.
+ Involvement with the community should begin as early as possible. It is not okay to assume, "We are special and we will get our way through even if we involve community in the end."
+ As is said in every GUADEC, GNOME is People. If Shuttleworth is unhappy with the leadership of GNOME, the way to fix it is not by doing things in private or by working with KDE/freedesktop.org (which is good but won't solve perceived problems with GNOME), the right way is to get involved with GNOME. How many Canonical employees are part of the GNOME Release team ? How many Canonical employees have ever been part of the release team ? Employ more people to work in upstream so that you can influence GNOME decisions. Grab the steering if you want to drive, don't be a back-seat driver.
+ There may be serious problems with the way freedesktop.org is managed if the complaints by Seigo are shared by many people in the KDE community.
Links:
1 - http://blogs.gnome.org/bolsh/2011/03/07/has-gnome-rejected-canonical-help/
2 - http://aseigo.blogspot.com/2011/03/collaborations-demise.html
3 - http://mail.gnome.org/archives/devel-announce-list/2010-June/msg00001.html
4 - http://aseigo.blogspot.com/2011/03/collaborations-demise.html?showComment=1299623993569#c1004728938259200386
5 - http://www.markshuttleworth.com/archives/654
Some of my observations have been wrong. If so, it is just because of mistake and not because of bad intent. Please let me know and I will correct myself. Thanks.
35 comments:
well said
fd.o's desktop standards come from people working on GNOME, KDE, xfce, and so on. I don't think fd.o has a problem any more than GNOME does here; the goals differ somewhat in that fd.o needs standards that fit for multiple desktops, while GNOME and KDE don't always have that concern foremost in their requirements, but I don't see that as a systemic problem.
Thanks for that blog-post. I agree a 100%.
Hmm, sorry, but there is a standard called "status notifier" and you don't use it!
We (i'm not a kde dev but a free desktops user) don't care about Gnome using libappindicator... If it doesn't integrate with gnome-shell, you just need to code it for gnome-shell.
Freedesktop.org is not an organisation that strives to develop something, it is instead a place where anyone involved in the free desktop development can reach other such people in order to come to an agreement on thing they want/need to share.
So, there is no "management" that can "manage" things really. Nobody is forced to follow any particular "standard" that someone proposes. In many cases however people from all sides are interested in working on solving things together, so fd.o lets this happen.
Yet again, you bring a great view point to an otherwise messy discussion.
Hearing your calm voice in such a noisy room is soothing. Thank you!
One note about the "KDE Board": you're probably referring to the "KDE e.V. Board" (KDE e.V. is the foundation supporting the KDE community), which is quite different in a number of aspects:
- The KDE e.V. does not play a role in KDE's technical development, as such is not involved in this discussion. KDE e.V. supports the community where possible, but does explicitely not take technical leadership. Technical leadership and direction is working very well driven by the community.
- Aaron's post was not done in the name of the KDE e.V. Board, I do see a lot of people in the community agreeing with him though. It's safe to assume that Aaron explains a feeling common to many KDE developers.
Who cares! Indicators aren't useful, and are flawed by design in that they reduce usability by increasing complexity! QUIT CRYING AND GET OVER IT MARK!
Rejecting the use of Canonical's libappindicator is orthogonal to collaboration and implementation of the proposed Status Notifier spec. Focusing on GNOME's rejection libappindicator, one specific impelementation of the proposed spec, is to miss the forest for the trees. GNOME always had the option of creating their own implementation.
The real problem is the insular, isolated implementation in GNOME Shell of a different systray/notification mechanism that basically ignores the proposed spec and unnecessarily introduces yet another incompatibility between the GNOME DE and apps and the rest of the FLOSS app/DE ecosystem. This choice unquestionably introduces additional app/DE fragmentation that, in some ways, makes the systray/notification situation worse than what we had with the XEmbed systray. It is reducing precisely this kind of fragmentation that many of us take as the rational implication of GNOME's participation in fd.o.
The problem is a pattern over the last few years of simply looking past the activities of other participants in the FLOSS ecosystem despite the genuine efforts of others to collaborate with GNOME. Perhaps it doesn't happen every single time, but it has certainly happened more than enough times for many of us to be genuinely concerned. Goodness knows everyone has to take some accountability both for us getting to this point and for making it better. However, to suggest in your My Take list above that everyone has an action item but GNOME is... unfortunate.
Let me suggest that you examine in detail the history of the CSD feature development and its integration into gtk+.
CSD was led and driven primarily by a Canonical employee. There is little to no drama associated with its development, and seems to have gone quite smoothly.
Figure out why CSD development and integration was done well and stand that interaction up as a model for future engagement.
CSD is proof-positive that both sides can collaborate.
Here is what I see what went well in CSD feature development:
1) Early communication from the driving dev prior to full implementation to gather feedback from existing gtk+ dev community and leads as to implementation and technical specifics
2) Integration of that feedback in a timely manner early into the development
3) Willingness to use gnome project infrastructure which lowers the barrier to collaboration and makes it easier for existing gtk+ devs to review code and provide targetted feedback about implementation and technical details
4) No copyright assignment hassles.
And let me stress that this isn't the only instance when a Canonical employee has felt it was okay to walk outside launchpad and use an upstream's preferred development tools. Canonical's kernel team uses git internally to lower the collaboration friction when working with the upstream kernel. The pragmatic use of git in the context of good faith upstream collaboration with GNOME is not precedent setting. This is done with regard to kernel work Canonical is doing day in and day out every day and has been for a while now.
-jef
Good post.
Besides that, I agree with you.
GNOME should remain firm, otherwise I believe Canonical will attempt to force their hand further. Canonical seems to think it easier to tell others how to handle their business rather than creating their own solutions to their problems. The open source community has lopped off body parts in the past over less than what is happening here, and duly so.
Protip @Canonical: Fork or comply.
You are completely suppressing the copyright assignment madness around libappindicator. As long as copyright assignment is required GNOME won't adopt it.
@Anonymous
Am i missing something here?
The API that libappindicator implements is completely free of any copyright issues correct?
Then why not just re-implement the API yourselves? if an amicable agreement really can't be reached with Canonical.
What we have now is the GNOME devs coming up with their own incompatible API that no-one else is likely going to pick up, and for what reasons? It doesn't integrate well with Gnome-shell? What does that even mean?
Is GNOME not concerned about inter DE compatibility with Unity and KDE etc...?
Pushing this onto the application developers to figure out could lead to a much greater level of blow back IMO
The problem, as I see it, is that there are two goals - that of producing the best desktop for it's users, and that of producing something that interoperates well with other desktops.
Unfortunately, these goals are sometimes in conflict. One one hand, app indicators (and the spec behind them) are a way to get a certain kind of cross-desktop UI. On the other hand, the way that's implemented doesn't seem to fit the vision the Gnome guys have for their desktop.
And so something has to give, and so far, it's mostly been the standardisation part. Gnome are using (and creating) standards where it suits them, but appear to have little objection to ignoring the standards that don't suit them.
A lot of the responses from Gnome people seem to be in the form of trying to show that Mark is wrong.
No doubt he is in some respects but it seems to me that that should be the least of Gnomes concerns.
Gnome should be asking itself to what extent he is right and how it can do better.
What Canonical does doesn't seem that abnormal to me. Nautilus came from Eazel. Evolution came from Ximian (with copyright assignment).
It seems that Gnome is forgetting about the diverse variety of inputs that got it to where it is.
Open source should be about freedom, you shouldn't have some "foundation" telling you what do do. Canonical/Ubuntu are the only company that is after the non-business desktop market, they already have at least 60% of that Linux desktop market. There is no need for them to listen to a foundation that is out of touch with reality and is funded by companies (yes Redhat and Novell (whatever they call themselves this month)) that have very little interest in Linux Desktop market.
If anything Canonical should lead, and Gnome should follow.
Thanks for the nice digest.
Just one correction - there's no a thing like KDE Board and 'the opinion of KDE Board'.
There is a KDE e.V. and KDE e.V. Board - but we [e.V.] are not influencing the development or any technical stuff, but only provide a legal background and similar things.
So, the things Aaron wrote are his own opinions that some of us share due to being 'burnt' when trying to achieve something that involved fdo.
Cheerio!
Just a question??? How come the fantastic new Gnome icon set is filed with gtk-foooriginal-fd-name? They are nothing more than copies of the non gtk-foo named ones, and if a gnome user tries to use an freedesktop naming compatible theme in gnome. He will have alot of missing icons...
We in oxygen created a fully compatible theme for gtk that matches perfectly the oxygen style, (obviously the intention is to give gtk applications a integrated look in KDE), we also make use of the Oxygen icons, but we have to link them with the original freedesktop name. This seams completely pointless specially since the icons are mere duplications...
We in oxygen have hundreds of icons that are not in the fd. naming specification usually because apps ask for icons not covered by the fd. or Becouse I forgot to check if the name was there already...But we don't go out of our way to create such problems...
What is the point of it?
Same thing for the icons for the systemray, once upon a time I ask the good people in gnome icon land if we could extend the f.d. naming thing o include a subset for tray icons, at the time I was told "There is no problem in the systemtray its implementation is perfect"
We had to create something different, maybe it was for the best but it kinda tells you the mindset...
I do have more examples of this behavior.
I'm not saying its exclusive to Gnome. just saying its wrong.
Cheers
I am working on KDE but am in no way a core developer, so just to set straight who I am.
I have not read the StatusNotifier spec, though there is something to keep in mind with specs and code in general.
Whenever you implement something you will be haunted by bugs to some degree.
Take the accepted DBus. A shitload of bugs are/were caused by it. By functions not being thread safe despite advertising that etc.
Does that mean that DBus is bad? No I don't think so. It could use improvements but it is an improvement in itself.
Does that mean that DBus is the best thing? Certainly not. But it is quite good and often good enough.
Yet what DBus offered is a transparent way for applications/libs to talk to each other. Like the proposed standard for password storeing etc.
DBus does not care which technology was used to create an application and that is great.
Yeah implementing the notification spec would for sure also cause some pain in parts of Gnome, it was not without hickups in KDE. Yet imo that is the price of collaboration.
You can either collaborate and thus _have_ to make compromises -- otherwise it is not collaboration, but dictation -- or not collaborate.
Now I was talking about compromises, but of what type would those be?
I highly doubt (as in "I don't know but don't think so," ;) ) implementing it would change anything to the negative from the users' pov, other than introducing some bugs in fact. What I rather think that it is more a devs problem. Everyone is free to do what they want, this is FOSS, still one can ask if other ways wouldn't be better and healthier.
Nice post!
In the interest of improving your writing skills, as you mentioned was one of the objectives of writing the post, note that 'at least' is two words, not one. ;)
As a KDE user I agree 110% with Aaron. also I know many many people in real life who agree with him too.
As someone who hasn't missed even one post that was at least remotely connected to technical stuff on Aaron Seigo's blog for at least 4 years and who has been following KDE development in general for at least as long I can say that I haven't once heard any cheering from the KDE crowd due to GNOME adopting a standard that originated from KDE, but I did hear so grumbles about some KDE propositions being shot down or KDE adopting something that wasn't the best for it.
Also a correction: StatusNotifier originated in KDE before moving to fdo, where it was further developed in collaboration with people outside of KDE, including some GNOME developers. Canonical then created an implementation of the spec in the form of libappindicator, which it proposed for inclusion in GNOME. GNOME chose to not only reject libappindicator but the StatusNotifier spec as well and instead created its own System Tray replacement which is incompatible with the StatusNotifier specification. StatusNotifier seems to be gaining traction everywhere but GNOME, who seem to reject it primarily due to the applications not having control over the way the info is displayed or how the user provides input. In practice this doesn't seem to be a problem for anyone, so the objection seems for now to be based solely on some academic relic.
That Canonical's indicators didn't support some things like scrolling over the volume icon in order to change the volume is entirely the fault of Canonical and has nothing to do with the StatusNotifier specification. StatusNotifier leaves such things up to the implementation.
Note that in the comments on Aseigo's blog, the points dave makes are pretty much proven wrong. GNOME has a reputation of being hard to work with (not just from a KDE or Canonical perspective but from many others as well) and that is a problem. Meanwhile, Canonical has a reputation for not playing well with upstream - again deserved, and a problem.
On canonical, read for example these two comments:
http://aseigo.blogspot.com/2011/03/collaborations-demise.html?showComment=1299807005600#c2417381301530751354
http://aseigo.blogspot.com/2011/03/collaborations-demise.html?showComment=1299814706744#c1432139034199491817
It’s not like Canonical has nothing to fix. And so does GNOME, they have been notoriously closed to outsiders and it’s not getting any better – imho there is no excuse for not working with KDE and Canonical on using the statusnotifier spec.
So this discussion is imho good and healthy – it could benefit FOSS, collaboration is good for us. I hope it works as a wakeup call - we should collaborate more. No, not blindly following others or just doing what Aaron describes here: http://aseigo.blogspot.com/2011/03/collaborations-demise.html?showComment=1299827142761#c4757710492378664655 but engaging in conversation and finding a common ground on FD.o IS GOOD FOR FOSS.
Sankar, please consider expanding on this IMHO pretty balanced review, and submitting it to LWN. I'm sure the grumpy editor would like to include a good summary of this heated discussion in the next issue.
@Jos
Gnome notoriously closed to outsiders?
Don't know where you could have gotten that impression.
I guess I am what you would call a Gnome insider. It didn't take more for me than just pick a project I liked and start contributing to stop being an outsider! :)
Just another blog where Gnome people stick their fingers in their ears and sing "lalalala" - its not us, its everyone else - we know best - we don't care about desktop interoperability - since day one we've been "if we didn't invent it then its no good"
Those in Gnome that make the stupid non-interoperability decisions - go to a dictionary and find out what collaboration means.
One simple truth I remind myself about is gnome shell. I have been using it for so long now that I ve practically forgotten about gnome 3. It is amazing all told. Very sleek. Very minimalist. Very functional. Hats off to the gnome team for some good collaborative efforts in implementing a great user experience. Kde remains a bit overkill for me; though it is a good product as well. Unity unfortunately falls the way of mac osx, ie, assuming that I do not want to know how to use my computer.
@ReinoutS: it might work for Cheese. But try sending in a patch from an @kde.org address to make GNOME apps load a KDE file dialog while running in KDE. It won't go in, I'm fairly sure of that.
Or send in a patch for GNOME Shell to alternatively use the cross-desktop notification standard from an @canonical or @ubuntu address and fail :D
In either case, it's not just about code. it's also about not doing NIH NIH NIH all the time. See how hard it has been for a REAL gnome lib providing location awareness in GNOME to actually get in. I know the author personally and he has been extremely frustrated by the fact that it took years despite NO technical barriers; while in KDE everyone was excited right away despite the fact it was a clearly GNOME oriented library which posed several issues for the KDE developers.
Not that KDE is perfect in this regard, but what desktop team decided to write a theme fully in the other team's toolkit to make the apps of the other team blend in better in their desktop? Right.
@Anonymous Could You provide some arguments that lead You think that Unity is for people who does not know how to use computer? I am using Unity, and the three things I am happy about are:
1) It saves a lot of space on my netbook screen (big one, really!)
2) I can swith between open apps with one keyboard combination (I use this a lot)
3) I can continue using Compiz with the effects I like ( :) )
I would like to see gnome-shell in action as I have not seen it for some time, it would be interesting to compare.
I am sorry for this a little off-topic post, but I am noticing some kind of rejection of Unity across several sites about linux and FOSS. It would be fine if it was not from people who do not try it out. Because I do use it, I am curious every time, which feature they are missing. ... but I never get to know.
Seems to me the Gnome people's principles have always been stronger than their code anyway. They always chose the lonely road: shunning Qt and C++ and using that primitive GTK mess. Then alienating folks by rearchitecting for Gnome 2.0 and leaving behind so much that already worked. It never ceases to amaze me that the big distros keep on preferring Gnome over KDE. I'd like to see Ubuntu make the switch: focus on making the KDE experience the flagship one and let Gnome play second-fiddle.
But it also sounds like their commercial interests have sometimes overridden their sense of good free software etiquette. There's a fine line between contributing and hijacking. RedHat has done stuff like that in the past too.
good analysis.
Thanks Shirdi and others who all commented.
Hey, Sankar.
Since you said you wanted to improve your writing skills...
"GNOME seem to reject ideas based on a (Not Invented Here) NIH syndrome."
Generally, for parentheticals like this, you want to put the parenthesis around the second term, i.e.:
"…Not Invented Here (NIH) syndrome…"
That's a fine way to write it, but it would also be perfectly acceptable to write it as:
"…NIH (Not Invented Here) syndrome…"
They aren't exactly the same construction, but I don't think you'd get any complaints about which one you chose in informal prose.
The first form appears a lot in legal writing, where the parenthesized text is basically implicitly (although sometimes explictly) saying, "…Not Invented Here syndrome (hereinafter referred to as 'NIH syndrome')…"
The second form is used more often in informal writing, I'd wager. Using it is more like saying, "…NIH (or 'Not Invented Here' [in case you didn't already know]) syndrome…".
@colby Thank you a lot for the helpful comment.
Post a Comment