23 March, 2011

The Collaboration Imperative

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:

111-SC-344998
Let's have a fight
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.
I Can't Afford an Actual Sign
I say opinions are cool!

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.

One big family
Call it a family trait...

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 Awful Truth, Day 4:  Could Be Working Harder
Reality?

Reality applied

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!

Entropy ≥ Memory . Creativity ²
*snap*

Actions

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.

Let The Wookie Hug
Time for a group hug?

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!

Welcome social event
Gran Canaria Desktop Summit

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!

12 comments:

  1. Nice article, I agree that important people should meet face to face, but normal folks who report bugs, might commit a patch sometime, spread kde, helps in forums, etc, also want to know about every decision in kde direction.
    What shouldn't be blogged is things like "they are badm I think it's because of X", and instead talking to the real people(maybe through specific mailing list at fd, like dave mentions in his article) and then blogging about the outcome of this discussion.
    Then the perfect workflow would be:
    There is a problem > a new mailing list is created to discuss this > all the people who should be there are invited > everything is discussed > the decisions are blogged > people comment about it, and necessary changes are made.
    Also to create the collaborative atmosphere everyone should admit that no project is perfect and that we all have to put from our part, maybe what someone could see as not collaborating from the other side it's really not having time, or not understanding what the other team is telling them and not having enough time to ask.

    ReplyDelete
  2. Very well written. Nice post.

    However, there is one area which I wish you have covered more in detail. While observing some of the KDE members comment, there was a feeling that nothing from KDE has been accepted to fd.o in the last 6 years or so. If majority of the KDE devs. feel this way, I believe it gives a pathetic opinion of FD.o (unless the proposals are rejected with valid reasons)

    From a neutral point, I felt that KDE folks should have complained long ago and perhaps should've even threatened to omit the cross-desktop focus completely if they felt they weren't heard. Waiting for 6 years and then using an opportunity provided by Ubuntu (for something GNOME rejected validly) to complain about GNOME is not correct.

    However, it is good that the cat is out of the bag at least now. I believe the next desktop-summit and openSUSE conference can strengthen the cross-desktop effects.

    I hope you got what I meant :-)

    P.S: Change your label to openSUSE instead of OpenSuse ;-) (no strong opinions on this though)

    ReplyDelete
  3. Many thanks, Jos for sharing your thoughts with us. And for your involment in openSUSE community!

    I home my words didn't arouse the fundamental attribution error in your mind :-)

    ReplyDelete
  4. """
    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.
    """

    This is quite inaccurate. I did not propose app indicators to KDE: KDE was already using them! What confuses a lot of people is that "app indicator" is Canonical word for "status notifiers". KDE Plasma devs created the concept of status notifiers, we (Ted and I) worked with them to extend the initial spec with dbusmenu.

    I think this whole story is not about one but two distinct failures, which can be attributed to very different reasons.

    First failure: Canonical devs (Ted and I), with the backing of KDE Plasma devs (Aaron and Marco) proposed the status notifier spec to freedesktop.org. This failed for several reasons, one of them being IMO that freedesktop.org lacks an appropriate process to ensure a spec proposal gets correctly reviewed and evolved.

    Second failure: A Canonical dev (Ted), proposed libappindicator, Canonical implementation of the status notifier spec as a GNOME dependency. This failed for other reasons, one of them being (again IMO) that Canonical and GNOME could not agree on a place to continue development: GNOME wanted it to happen using GNOME infrastructure, while Canonical wanted to continue using its own infrastructure. Another reason is the requirement for assigning copyright to Canonical to be able to contribute to libappindicator.

    ReplyDelete
  5. Oh, forgot to add... great post Jos! I hope we can get things moving regarding communication on freedesktop.org during the next desktop summit.

    ReplyDelete
  6. @Aurélien Gáteau: well, it seems nothing is correct in this whole discussion - which is why I kept my description to 3 sentences and just quoted and linked to some ppl. Better to stay away from the 'fact finding' as I don't think it really helps.

    I'll do what I can to help things move forward - besides my involvement in the DS I do have some other ideas but that is for another blog ;-)

    ReplyDelete
  7. Nice article, I agree that important people should meet face to face, but normal folks who report bugs, might commit a patch sometime, spread kde, helps in forums, etc, also want to know about every decision in kde direction.
    What shouldn't be blogged is things like "they are badm I think it's because of X", and instead talking to the real people(maybe through specific mailing list at fd, like dave mentions in his article) and then blogging about the outcome of this discussion.
    Then the perfect workflow would be:
    There is a problem > a new mailing list is created to discuss this > all the people who should be there are invited > everything is discussed > the decisions are blogged > people comment about it, and necessary changes are made.
    Also to create the collaborative atmosphere everyone should admit that no project is perfect and that we all have to put from our part, maybe what someone could see as not collaborating from the other side it's really not having time, or not understanding what the other team is telling them and not having enough time to ask.

    ReplyDelete
  8. I do think a common VoIP technology in the FOSS world would be nice. People are understandably not wanting to use Skype. But it'd be nice to be able to assume I can Jabber/Jingle with anyone in the same way I can assume I'll be able to IRC chat with anyone in FOSS.

    Sudden phone calls are rude and annoying, but OTOH voice communication is underrated in FOSS.

    ReplyDelete
  9. @Jos: Great post.
    @Ian: Hope is comming: GNU Free Call Announced http://planet.gnu.org/gnutelephony/?p=14

    ReplyDelete
  10. Nice article, I agree that important people should meet face to face, but normal folks who report bugs, might commit a patch sometime, spread kde, helps in forums, etc, also want to know about every decision in kde direction.
    What shouldn't be blogged is things like "they are badm I think it's because of X", and instead talking to the real people(maybe through specific mailing list at fd, like dave mentions in his article) and then blogging about the outcome of this discussion.
    Then the perfect workflow would be:
    There is a problem > a new mailing list is created to discuss this > all the people who should be there are invited > everything is discussed > the decisions are blogged > people comment about it, and necessary changes are made.
    Also to create the collaborative atmosphere everyone should admit that no project is perfect and that we all have to put from our part, maybe what someone could see as not collaborating from the other side it's really not having time, or not understanding what the other team is telling them and not having enough time to ask.

    ReplyDelete
  11. Thanks Jos!

    A quick response to Aurélien: libappindicator was *not* rejected for reasons related to the infrastructure in which it was developed (ie. the whole Launchpad issue). That much is 100% clear from the reasons provided by the release team.

    (License and copyright assignment issues were raised during discussion, but were again not the key reasons why libappindicator was not accepted for GNOME 3.0.)

    ReplyDelete
  12. @jos: I realized a bit too late (like, 3 seconds after hitting "Post Comment") my comment was not really on topic, sorry for that.

    @jeff: I heard different things, but as Jos said, it seems nothing is correct in this whole discussion, so let's not derail Jos message more than I already did.

    ReplyDelete

Say something smart and be polite please!