Log in

No account? Create an account
Previous Entry Share Next Entry
Frustration, thy name is trying to work on two projects
Last Tuesday I gave a talk at the Cape LUG about what I saw for the future of GNOME-Ubuntu relations. I didn't paint a pretty picture. A full half of my talk consisted of me moaning about how crappy it is that minor differences between the two projects are repeatedly being blown out of all proportion, resulting in the current river of bad blood we find ourselves wading through. (The other half was filled with my customary suite of bad jokes and incoherent rambling.) Interestingly, Mark Shuttleworth was also in town and dropped by [1] to listen and respond to some of my points. This was certainly welcome because it helped me to understand some of the decisions Canonical has made recently. Besides, it was a nice gesture.

Perhaps some context for what follows is in order. I'm an Ubuntu person who spends most of his time working upstream in GNOME. I do this because I think my work can benefit the wider community as well as Ubuntu users (and, erm, because I enjoy working on GNOME). It can be a bit crappy sometimes, though.

For starters, some [2] people in the GNOME community moan about how Ubuntu doesn't pull its weight upstream. They then make it difficult for Ubuntu-y folks to contribute things upstream. People within the Ubuntu community, Canonical employees included, have tried to make significant contributions and have been knocked back on several occasions [3], in most cases not for any particularly good reason I would judge. I've even heard stories about Canonical having to upstream patches via a third party because a GNOME maintainer wouldn't accept (identical) patches from them! (I know; citation needed.) There is an anti-Ubuntu (or at least anti-Canonical [4]) sentiment in parts of the GNOME community.

Equally, there is a frustration with GNOME in some quarters of the Ubuntu community. Rather than joining in on the GNOME side of things and developing upstream, people see the processes and dynamics of GNOME as hurdles to doing what they want to do. It seems easier to go off and partially reinvent the wheel than to try working with people who don't share your exact vision of the free desktop [5]. Of course, there is no middle ground to be had, and the "irreconcilable differences" which prevent us from working together on one thing or another often lead to "completely different" approaches being taken, like Unity and GNOME Shell [6]. This way of doing things is often a gigantic waste of time and reinforces the opinion of some in GNOME that Ubuntu isn't a team player.

To round-off this sketchy analysis of a complicated situation, I should also mention Canonical's role in all of this. Canonical are a for-profit company and intend to make money from the Free desktop. On paper at least, I think most people in the GNOME (and Ubuntu) community are happy for people to make money from Free software. The method you use to make that money is subject to intense scrutiny, however. Free software companies are already at a disadvantage compared to proprietary software businesses when it comes to making money [7], and insisting that all of their attempts to generate revenue fit into some warm, fuzzy picture of a benevolent cooperative for whom profit is incidental is unreasonable [8]. Sorry folks, but it's the 21st century - even charities are getting cutthroat when it comes to fundraising, because they realise you can do more good by playing the capitalism game whilst remembering to stop short of the excesses of Big Business.

If you want the Free desktop to be successful, to gain significant market share, to compete with some of the biggest, most ruthless companies in existence, you're going to have to throw away some of your ideas about how this should work in an ideal world and start playing hard ball. I think this is what Canonical are trying to do. And yes, that involves exploiting [9] the community to some extent, and of course people are upset about that. I don't think Canonical are hell-bent on milking FOSS for all it's worth, but they do require some freedom to operate. Having said that, if Canonical want to push the view that a pragmatic, corporate approach to Open Source is the route to success, then they're going to have to do a lot better at not making people feel used. Things like splitting Banshee's Amazon referrals and insisting on copyright assignment cause bad feeling without bringing in much dough, I would imagine.

My point is that the bulk of this bickering is counter-productive and unnecessary. Open source desktops are hardly swimming in market share, and I doubt chronic infighting will remedy that situation. I don't care who started it, or who is in the wrong. From my point of view, the whole situation is depressing and demoralising. If it continues, chances are I won't want to work in either community. But the differences are reconcilable! GNOME can understand and facilitate Canonical's commercial goals and can be more accepting of Ubuntu people and their way of doing things; Canonical can benefit from the fruits of the Ubuntu and GNOME communities' labour in a more sensitive way; and Ubuntu contributors can resolve to work upstream more. All it will require is for some people to swallow their pride and/or make small compromises [10].

1 In a Darth Vader mask. Really. There are photos somewhere.
2 I would like to draw your attention to my careful use of the word "some" throughout this post.
3 I'm thinking of things like Zeitgeist, app indicators (which are a Free Desktop standard!) and so on.
4 I fully understand that Ubuntu and Canonical aren't the same thing, and that there are tensions between them. They often get tarred with the same brush upstream, though.
5 The decision to switch to Unity instead of GNOME Shell is symptomatic of this. I asked Mark about that decision and he said that attempts were made to get Canonical design people working with GNOME design people etc. etc. and no agreement could be reached. Despite this fundamental disagreement between the two camps, Unity and GNOME Shell are doing a great job of looking and feeling almost identical to one another.
6 Sorry to harp on about it, but GNOME Shell and Unity are extremely similar, to the point where hardly any of the differences offer tangible benefits to the end user. Helpfully, they're just different enough to cause massive problems for documentation and support people though. Working together on one new shell would have been possible on purely technical grounds.
7 By this, I mean that factors like the code being open mean that it can be more difficult to get users to pay up; revenue streams other than the obvious, directly selling the software, must be found. Of course, Free software has plenty of advantages in terms of reduced development costs, community contribution and the like.
8 To pick an example at random:
"I thought you understood the spirit of Free Software, but you're just another normal company that is first going after money."
9 An ugly word, but I think it's the right one. You're making money by taking other peoples' work and packaging it up, without offering them any reward for that work (monetary reward, at least).
10 I will be swallowing some of my pride by working on documentation for Unity and assigning the copyright to Canonical.

  • 1

app indicator + zeitgeist

I have no influence, and contribute less than anyone in GNOME. But I do have a eye for bad taste. And about you point [3] App indicators are bad taste. And yes i'm only picking out a minor point, much of your article is very reasonable and points out the rocky path ahead :)

But... about [3].

Some of the design stuff in app indicators is worthy of GUI hall of shame. I mean, objects that fade when the equivalent of your mental attention (the pointer) hovers it. It's like turning to person starting a conversation, and then they disappear. It's so odd. Secondly the very well thought out keyboard activated on screen icons in gnome, has been replaced with app indicators. Before pressing volume/light controls was a onscreen transparent icon (huge) that was _centered_ on the screen. Now it's in the top right corner using about <5% of screenspace on some laptops. I've seen users miss 'app indicator' notify. When user presses a button themselves, there is no reason to hide it(!) in a corner, show that the intended action occurred - clearly.

I would have understood if all the work went into merging the window list and notifications. But no, instead we invent a third way to interact with applications. Great! It shows lack of understanding the mental concepts the existing desktop attempts to provide. It can't be a surprise that there has been resistance in gnome to add more features to the notification area. Read up on early gnome2.x

Zeitgeist is much more interesting. However, it's also very much research, both UI and tech because it has to run at all times, and not suck power and memory, and still gobble through huge amount of data. That's hard to get right.

Given the later architectural changes done in tracker to better support the goals of concepts of zeitgeist, _and_ that the only app using it at that time was an ill conceived 'journal', that in reality was more like a 'zeitgeist' debugger than an actual use case. It was the right thing to reject zeitgeist as a of the library foundation framework. It lacked user goals to accomplish and it showed.
I still think that finding the correct 'item' is hugely important, and tracker is big part of this.

Yes i'm harsh, but it seems that just because somebody spent valulable time on a project, it's by definition a valuable addition to gnome. Well, it isn't. We have to be able to say 'no'. If it's too hard to 'add' features after installing the desktop, fix that instead of breaking it for the majority by forcing stuff as default.

Re: app indicator + zeitgeist

The Indicators were mostly not accepted because Canonical refused to write a patch for GNOME Shell as well. Canonical only provided a GNOME 2.x patch.
Of course GNOME didn't accept a patch that developed a new technology for an aging DE when at the same time the technology wasn't even made compatible with Shell/3.x.

Re: app indicator + zeitgeist

With comments like "worthy of GUI hall of shame" it seems like you've made up your mind and you're not willing to listen to another person's perspective.

Personally I really like it that the Ubuntu notifications fade when I move my mouse over them. Sometimes I want to read whatever is underneath them. I don't want them taking my attention away from what I'm doing. For me, this was an excellent design decision.

Of course I don't know if you would ever take this perspective into account. Maybe you would, maybe not. Since you think it's literally shameful, I get the impression you'd not. But I'd be very happy to be wrong.

Re: app indicator + zeitgeist

I know it's harsh, and as you say, it is too harsh :). You are completely right.

Maybe it's because i'm actually disappointed :), I expected better?. It's such an obvious misunderstanding of wimp/mental models at work, humans try to fit a model to abstract behavior, and having the pointer just point at stuff to go away, is clearly backwards from everything else it does. Think of the pointer as an extension of our attention.

I'm not saying you do not want to see what's underneath, it should just be done in another way. But at worst, the notification disappears after like what... 15 secs?

Of course this is not research, i'm (almost) pulling it from my.. well you know :). Real testing (but it's quite hard to do such testing, almost impossible) would of course be the right way to do it.

That you can grasp it, i have no doubt. I'm sure most do after a few surprises. But now they have to reevaluate their existing model of what a the pointer can do, when exploring new interfaces or just using existing one. It might make stuff disappear or it might be a way to active way stuff pointing and clicking.

Re: app indicator + zeitgeist

You suggest that I "Think of the pointer as an extension of our attention." Maybe that's how you actually *experience* it (as compared to forming a theory about it). But I have never experienced it that way (with the possible exception of when I first learned the concept of the mouse). Instead, I pay no attention to the pointer unless I have to. Most of the time I have no idea where it is and I don't care. The only time I care is if it's in the way of what I'm paying attention to, or if I need to move it to perform some action.

In short, I think you've constructed a theory around an invalid assumption.

I was pretty heavily involved in the design of app indicators. As far as I know, there is nothing in them that fades, in any situation. And far from “add[ing] more features to the notification area”, they have replaced the notification area entirely with something that deliberately has fewer features. So, what are you talking about?

Re: What?

That would be pretty embarrassing if missed what project it was. But it would be stupid arguing against the design though. Isn't notification-osd part of app-indicator project?

At least up to 9.10 , when you move your pointer above a notification (in compiz) it fades away allowing you see what's underneath until it disappears after 15 secs.

You are correct that app-indicator does remove features, flexibility might be a better wording, my bad. The problem is that it also encourages applications to use it, which of course is the point, but the history of notification area was pretty specific about applications not belonging in the bar.

I know it is a poor argument, but the notification area was partly left as is because a good, well designed and easy to use API would only encourage more use from applications as one more way to active the same application. But something was needed to convey system events. That is the impression I got from the discussion back then.
And yes it's a very bad way to treat your developers ;).

The hope was that people would have time design the right thing. App indicator is of course a very good attempt at that, but it's also further down the path of having multiple possible actions to activate applications. That is my main objection.

But i'm arguing against somebody more qualified ;).

PS: I'm sorry about the grammar and spelling errors ;). Poor excuse, but english^H^H^H^Hrish is not my native language :).

Oh, sorry, I didn’t realize you were talking about Notify OSD. No, that has nothing at all to do with application indicators.

It’s an interesting point that having an easier-to-use API might make people use indicator status menus more than they would have used the notification area. But we can discourage overuse of indicators in other ways (interface guidelines, ridicule, and so on), whereas there was no other way we could have made the notification area more consistent.

I don’t know what you mean by “system events”, though. What kind of interface something should have depends on how much of your time it needs, how complex it is, whether it needs to interrupt you, and so on — not on whether it’s “system” or not.

Re: app indicator + zeitgeist

I don't see how you compare Zeitgeist and Tracker.
A metadata storage and a logger are not the same. And if any attempts to solve user stories of the other side then it is attempting to become a kitchen sink of data.
We learned our lesson and currently we are doing lots of zeitgeist work with upstream projects. Rhythmbox, Banshee, totem and gedit are shipping plugins and soft dependencies. Also we have some patches for GNOME shell that got reviewed ans hoping to get merged upstream for 3.2
Describing Zeitgeist as research is fair but then how is tracker not research. We have more community deployment and usage. Docky, Dockbar, Synapse, Tomboy, AWN, Cardapio. All these projects might not be upstream gnome but pretty well spread.

  • 1