As you might have noticed, there is a little bit of a brush-up between GNOME and Canonical with KDE involved from the sidelines (just read Planet GNOME). Dave wrote a reasonable summary of this and so did Jeff Waugh in his series on the relationship between Canonical and GNOME. In three sentences:
Canonical gets a lot of criticism for creating a fork of the GNOME experience with Unity, instead of contributing upstream to GNOME Shell. Canonical responds that Unity was meant to be a GNOME project and their contributions are being blocked (giving libindicators as example). Suddenly Aaron Seigo from KDE weighted in, saying GNOME is indeed hard to work with.
I've been reading up on it and to some extend participating in the discussion on identi.ca. As you know, I'm interested in the subject of collaboration and this is a case where it clearly didn't work out for a variety of reasons. In this blog I won't try to weight in on the topic itself but rather argue that the psychological construct of "the fundamental attribution error" can explain much of the conflict and how to avoid it.
But let's start with a sample of the discussion.
forming an opinion
I'm not exactly the type of person who makes up his mind easily. And the stories that came out of this debate were highly conflicting and confusing. According to this, Canonical discourages its employees from contributing upstream. However, Aaron claims GNOME does not WANT to collaborate. And Mark blogs:
Jeff also goes on to talk about Ted and Aurelien, who were proposing the app indicators work in GNOME and KDE respectively. KDE apps worked smoothly, Gnome rejected Ted’s proposal.
So GNOME is uncooperative? Or does Canonical not get it, as Dave claimed? Is KDE just pushing things without listening? Depends on your point of view - the facts are vague. Read for example this thread on freedesktop.org about the StatusNotifier (systray) spec - there is about a 50% chance you'll decide KDE is the uncooperative one... This thread was referenced several times as proof Party X was inflexible and rude - where X was sometimes GNOME and sometimes KDE!
Makes you wonder what is going on...
So what is real?
A few days ago I had a call with Jeff Waugh. He offered to talk in a dent and I'm glad he did. Of course, as usual the whole situation is more complicated than what you can discuss in 140 characters on twitter. The talk was very enlightening and made me think of a psychological concept.
The fundamental attribution error
People tend to attribute what happens around us in the world to intentions. We believe things happen for a reason. This is quite a strong human tendency already present in very young children. Put a 3 year old in front of a room where stones are moved around by some invisible means like magnets. Ask the kid what is going on and he or she will describe the events in the room in terms of "the blue stone wants to talk to the red one". We know stones usually don't really want a lot - so why does the child perceive such intentions? This phenomenon not only forms the base of early religions (attributing 'intentions' to weather, trees or growth of crops) but also results in making conflicts worse. Psychologists call it "the fundamental attribution error" and it is fundamental (hence the name) to our perception of the world.
So the reality is, besides that stones and trees don't have 'goals' and 'intentions', that often things happen for other reasons than someone having the intent to do that specific thing. Or in English, if a specification gets critical comments - maybe the respondent might have had other reasons than just wanting to be a jerk. Like being busy, tired or having misunderstood/missed a part of the discussion.
The talk with Jeff made clear that the major reason for GNOME not supporting the systemtray spec was timing, not lack of interest The focus of the GNOME project right now is understandably narrow: get GNOME 3 out the door. Something like interoperability, no matter how important, is not on top of the agenda. Jeff said he expects the FD.o systray spec to be supported hopefully in GNOME 3.2! The lesson: sometimes things interfere with cooperation. And the 'other camp', blissfully unaware of the real reasons behind lack of response or rude behavior, attributes it to a lack of willingness and support.
As another example, take the adoption of the Galago (notification) specification and what went wrong according to this message by John Palmieri. And about GNOME and Canonical having misunderstandings: Stuart Jarvis blogged how hard understanding a Free Software community can be.
Now I'm not going to attempt to unravel all the events that led to this blog as that would simply be impossible. Nor will I attempt to figure out 'who is to blame' as that's pointless (and wrong anyway, as I argued above). What I can do is ask those involved to think about the fundamental attribution error: if someone looks funny at you, it doesn't mean they hate you. They might have something stuck in their eye!
Ok, so maybe the others don't hate you. That doesn't solve the problem - yet. We all need to step up and do something. What?
Make collaboration an explicit focus
I wrote about collaboration before and at FOSDEM there was a cross-distro-collaboration discussion. As I said there, a big blocker for more openness is that we simply don't think about collaboration. We need to be aware of the opportunities for and benefits of collaboration. The whole discussion that I started this blog with might be negative and things are all a bit tense right now, but it shines the spotlight on something that needs attention! And positive initiatives like Appstream are happening. As Seif Lotfy wrote on his blog:
And if you haven’t noticed we are working with GNOME Shell, Unity and KDE. So a sense of collaboration is possible ;)
It just needs us to take notice! So, Mark, maybe blog about Appstream? It's using Ubuntu Software Center for the GNOME side, after all... Let's also focus on the positive projects!
Talk together face to face!
It is important to talk about concerns and frustrations. Considering the distance Brazil-Australia the best Jeff and I could do was a phone call but it was certainly enlightening. And I bet that you'll notice the same when you finally get to talk to those you've been fighting with on IRC and mailing lists for so long... Even then, realize that one single person does not define his or her whole project. Not everyone in KDE is as jumpy as Aaron; not everyone in GNOME is as French as Vincent Untz. It is important to share the results of a chat as well - blog about it (if your blog is aggregated on your projects' planet), or add results to a wiki or commit logs etcetera. Make sure the positive results persist!
Allison wrote he also wants to start a bit of a discussion in the cross-desktop area which I welcome and support. Sounds like something which could make an impact and Allison, if you want my help, let me know what I can do.
Take advantage of events to meet
Don't overlook the opportunity to meet at events. For example, there is the Linux Foundation's Collaboration Summit in San Fransisco in a few weeks. It is co-located with Camp KDE which seems to me an excellent opportunity for stakeholders to get together. Go a few days before the Collaboration Summit starts so you can get some face to face time with desktop folks.
Then of course in August, there is the Desktop Summit. I'm one of the organizers and while collaboration isn't always perfect, the team has a common goal: organize a great event! Like the previous Desktop Summit in Gran Canaria I hope we can make some steps forward. This Desktop Summit will have collaboration even higher on its agenda than the last one and I hope this will have positive effects.
Doing more, moving forward
There certainly is more we can do to solve the conflicts. With apologies for the irony here, more blogs trying to analyze the whole thing may simply be fueling the flames more than extinguish them. Talking to people works better. I don't claim there was no talk, there was. However, much communication we do happens over the web. And as we are all aware, that can easily lead to misunderstandings. So the face to face meetings I suggest, as well as an awareness of biases like the fundamental attribution error, can contribute to solving these conflicts in a more effective manner. As long as the results get documented in a few (public!) places and as such don't get forgotten the results of such meetings can be good and long lasting!
Personally, I'll stay away from the subject now - I've dented, tweeted and now blogged enough about it. I'll focus on the positive - including the Desktop Summit. And making sure the next openSUSE conference will have as much of a collaborative atmosphere as the last one!