Lessons learned

12:51 am community, freesoftware, gnome

After my rather controversial question a few days ago and multiple reactions from around the KDE & Canonical world, a lot of reading and digging into archives, and a lot of conversations with people across the spectrum, I have some preliminary findings and lessons which I hope can serve us going forward to help improve things. Nothing in here is controversial, I think, but each of these is a contributing factor to the current mess we find ourselves in.

tl;dr

For those without the patience to read this article (which is much longer than I intended it to be when I started!), here are the headline points:

  1. FreeDesktop.org is broken as a standards body
  2. Mark Shuttleworth doesn’t understand how GNOME works
  3. GNOME is not easy to understand
  4. Deep mistrust has developed between Canonical, GNOME & KDE
  5. Difficult people are prominent in each of these projects
  6. Behind closed doors conversations are poison
  7. For people to work together, they need to be in the same place

In summary, there are a number of things we can do to move forward from where we are now: improve processes & structure for freedesktop.org (this will require buy-in from key GNOME & KDE people), make the operation of GNOME (and the operation of individual modules) more transparent from outside the project, cut out a lot of the back-channel conversations that have been happening over the phone, in person & on IRC, in favour of documented & archived discussions and agreements on mailing lists & wikis, and work to ensure that people working on similar problem areas are talking to each other.

The major challenge we have is how to move beyond the deep mistrust which has evolved between members of our communities, who are all to eager to assume the worst of others, and how we can improve the tone of discourse when some of the most prominent members of our communities are also hard to work with.

Now, to elaborate:

FreeDesktop.org is broken as a standards body

This is not surprising when you consider that it’s written right there on the front page: “freedesktop.org is not a formal standards organization”.

In the case of the StatusNotifier spec, the brokenness shines through. Work started in April 2009 by Aaron Seigo, using the Galago spec as a starting point. Once KDE had begun working on an implementation, Marco Martin started on an initial draft of a spec. The first round draft there was mostly done on September 17 and proposed as the KNotificationItem spec. Then Aurélien Gâteau and Ted Gould made some (offline) suggestions, resulting in a rename, and some revisions, in late October. The spec was proposed as the StatusNotifier spec in December 2009.

At the point that GNOME developers Dan Winship & Mathias Clasen, and Citrix developer Giles Atkinson, reviewed the spec and made comments on it, too much had been invested in it to make major revisions. At that point, it is disingenuous to call StatusNotifier a cross-desktop standard. Hosting a document on the freedesktop.org wiki does not a cross-desktop standard make.

It’s interesting and ironic to see Aaron mention the nascent DConf specification from 2005 in these terms:

instead, the idea was, “If we propose it on fd.o, then people have to accept it because otherwise they won’t be cooperating with fd.o.” this is completely different from trying to work with others and having those efforts ignored.

In fact, that is exactly how StatusNotifiers were perceived (and exactly how Mark & Aaron are messaging GNOME’s non-adoption of the spec).

There is no freedesktop.org process for proposing standards, identifying those which are proposals and those which are de facto implemented, and perhaps more importantly, there is no process for building consensus around a specification, and signalling that consensus.

If I were in charge, I would require every spec to start with a problem definition. Only by agreeing on the problem can we hope to arrive at a solution which will be acceptable to all. The problem statement is the guiding light of a spec. Then I would make sure that the people with an interest in solving the problem were committed to the project. Only then do you start working on a spec and implementations. Without agreement on a problem, and without the right people at the table from the start, the effort is doomed. Some guidance on the process for the creation of a spec would be a start.

In this case, there was no founding problem statement. The spec proposed by Marco Martin listed this as the problems which it was solving:

The new protocol is based upon D-Bus, and separates the presentation of the items from the logic, in our case the painting is completely controlled by Plasma and the applications registers via D-bus (with a small client library shared across KDE) to a central server, while there can be zero or more instances of the systemtray. if either the serve or no instances of systemtrays that supports this protocol are registered the system will fall back using the old freedesktop.org systray specification.

This is not a compelling problem statement. No user ever had a problem because notifications didn’t use D-Bus.

It’s clear when reading Dan Winship’s follow-up comments that there was disagreement on the problem to solve, as well as disagreement on how to solve it. Dan felt that a spec should include policy, and document expected behaviour, while Aaron and Marco were at that point committed to the separation of “the visualisation” and the API. With a better problem statement, this would have been a minor implementation point, without one, two people ended up arguing over positions, and not interests.

If, instead, people had agreed on the problem of the panel or the issues they wanted to address before starting to work on a solution, things might have gone more smoothly. Note that the wiki page linked above was created at the end of December 2009, and the mailing list post was from February 2010 – to communicate what had already been written, not to concentrate people on a common problem.

Mark Shuttleworth really doesn’t know how GNOME works

This one really surprised me, but I think it’s indisputable. Mark wants GNOME to have “strong, mature technical leadership”. He talks about a GNOME cabal, and GNOME’s strategy being “whatever Jon McCann wants to do with the panel”. Mark and others don’t understand why libappindicator was rejected as an external dependency, misunderstanding that external dependencies are, by definition, dependencies of GNOME modules. He admits himself that he has failed to have Canonical developments considered as “internal to Gnome”, and clearly does not understand the position that the GNOME community as a whole has taken with respect to copyright assignment, or the history behind that position.

My understanding of GNOME is this: GNOME does not have technical leadership – it hasn’t had clear technical leadership since, as I understand it, the creation of the GNOME Foundation (at which point, by design, the board was given a mandate to build and define GNOME, and then soon afterwards removed that mandate from itself). The foundation does not now dictate any vision or direction for GNOME.

It can be argued that this is something which should be changed. That change will be effected by people involved in the foundation and the project. It is not enough for Mark to tell the project that “you need leadership”, or Jono Bacon telling foundation members (as he told me in 2007) that they should step up to the plate. Decisions are made by those who turn up – and I consider Mark, Jono, Ted Gould and others as members of the GNOME project, with as much mandate to change GNOME as I do. If Mark wants GNOME to have strong leadership, then he needs to help make that happen.

Given that this is not (yet) how GNOME works, to get things done in GNOME, you need to talk to the right people. That means, defining your problem, and identifying the stakeholders who are also interested in that problem, and working out a solution with them (am I repeating myself?). Mark seems to want GNOME to behave like a company, so that he can get “his people” to talk to “our people” and make it happen. I think that this misunderstanding of how to wield influence within the GNOME project is a key problem.

But then again, over the years I have heard similar feedback from GNOME Mobile participants, and people in Nokia – so it’s not all Mark’s fault. As Jono says here: GNOME does have a reputation of being hard to work with for companies – no point in denying it (then again, so does the kernel, and they seem to get along fine).

GNOME is not easy to understand

When I evaluated GNOME’s governance for Simon Phipps recently, I scored the project 0 (on a scale of -1 to 1) for the criteria of oligarchic governance. The notes from the evaluation were:

Newcomers to GNOME often have trouble figuring out who’s in charge. The Release Team is responsible primarily for the release process and has not traditionally set any strategic direction for GNOME, and individual module governance rules are varied. The foundation board is responsible primarily for maintaining the infrastructure of the foundation, and dealing with sponsors and benefactors, and does not set any technical direction.

Score: Governance is open, membership of the release team oligarchy is meritocratic – scoring zero for oligarchy because much of the governance is devolved to maintainers, making it hard to figure out how to accomplish project-wide change.

Finding the right person inside the GNOME project to help work on a given problem is not straightforward. If you want to make a change to one module, then it’s as simple as working with the maintainers. If, on the other hand, you want to propose a system-wide change, it is a much harder job – you need to work with module maintainers to get them to adopt your proposal, then work with the release team & the wider GNOME community through the module proposal period to get your library included in one of the module sets. Libraries I can think of in recent times that have not gained sufficient traction include Beagle, Geoclue, Soylent, or LeafTag. Other projects like Pyro, GNOME Online Desktop, or Zeitgeist have had baptisms of fire. Even libraries like GStreamer and Telepathy have taken a long time to get traction in core GNOME applications.

Even once you’re in the right place, having work reviewed can take time & effort. I have been told stories of dropped or unreviewed patch-sets by developers I’ve known across a number of projects for many years – one that is mentioned frequently is GNOME Control Center. Maybe persistence was all that would be required, maybe the patches were submitted in a way other than the usual method, or maybe the maintainer was just stuck for time & forgot – in any case, patches were lost, or their integration delayed, and contributors ended up disenfranchised.

But then you can say the same thing about the Linux kernel – contributing to the project is so confusing that Jon Corbet wrote a book about how to contribute, or even KDE – Stuart Jarvis wrote a timely article yesterday explaining that “KDE is not like [a company]. We don’t have leaders. We have prominent community members, but they tend to operate within their own areas of expertise.” Sounds familiar.

The bottom line is that GNOME can improve, but it is not going to change its nature, and working with GNOME needs to be done on the terms of the community you’re working with, not on your terms.

Deep mistrust has developed between Canonical, GNOME and KDE

Regardless of the causes & the history, it’s been made very clear over the past two days that people in our communities are prepared to believe the worst about their fellow free software developers.

Aaron Seigo, for example, clearly has no confidence in GNOME developers as a whole. He writes in a comment that:

@Tom: “do you think the Gnome my way or the high way attitude is connected to company agenda?”

i don’t think so. [...] it really seems to be something common to the culture of the project rather than the culture of the companies they work for.

and later:

it’s not a belief that GNOME has decided to not collaborate on this (and other) initiatives for no good reason: it’s a fact. there is a demonstrated “if isn’t invented here, it isn’t used here” pattern of behavior.

Mark clearly believes that GNOME Shell is a Red Hat project. He feels short-changed, feels he and his team have made a good faith effort to engage which has been rejected, offer suggestions which have been ignored. On the other hand, Jon McCann does not see things the same way. And a lot of GNOME people see the move to Unity as a deliberate effort to undermine GNOME Shell, one more in a series of initiatives designed to give Ubuntu differentiation over their competitors without feeding the results into the upstream ecosystem.

Looking at some of the tweets & comments on the various posts, I see an employee of Intel, a developer from the Junta de Andalucia, a number of ex Canonical employees, a Novell employee, an unaffiliated volunteer, and others.Mark’s article blaming GNOME for the problems in the relationship was literally met with “WTF”s and laughter.

Ill will toward Canonical as a company is not limited to GNOME – Greg Kroah Hartman’s infamous presentation at the Linux Plumber’s Conference in 2008 comes to mind. Clearly frustration has been building across the community for a number of years, and it’s far too easy to dismiss it as jealousy because Ubuntu has so many users.

Difficult people are prominent in each of these projects

At this point, the participants in what has become a menage à trois each have a world view which is so different and a prioris so ingrained about the motivations & attitude of everyone associated with another project that undoing the damage will be very difficult.

It’s made even more difficult because a number of key contributors in the projects in question have a reputation of being hard to work with. In GNOME we have our share of people who, to use a phrase Jon Corbet uses to describe kernel hackers, are “not always concerned with showing a high degree of politeness”. I could come up with 10 names of hackers who might themselves be surprised to be on the list, who would be considered by people who have worked with them to be “prickly” to say the least. These people can be found at all levels of the project – prominent on the GNOME Foundation mailing list, maintainers of modules, employees of all of the major companies working with GNOME, even on the release team.

On the KDE side, Aaron also has this reputation – one KDE contributor I spoke to recently said that if Aaron had been a little more open to the feedback he received rather than adopting his “habitual air of superiority” that things might have gone better. And he’s not alone.

Reading the thread on freedesktop.org where the StatusNotifier spec was being discussed, it’s clear that Dan and Matthias considered that Aaron was being dismissive of their concerns – and I can certainly see why. Aaron, on the other hand, in his blog post, considers that “there was a lot of communication about Status Notifiers on the freedesktop.org xdg list where good feedback was offered and the specification improved significantly as a result. So communication really can’t be to blame here, at least not communication by those outside of GNOME” – there is a clear disconnect between how the thread was perceived by Aaron and by other participants.

Mark himself is no angel – I’m sure he will recognise that he is not one to avoid polarising positionn, or to change his mind easily once it’s made up. On the subject of copyright assignment, his mind is made up, for example. There is no revenue motive  behind the decision (I am convinced of this), but on principle, Mark has come to believe that controlling the copyrights to code is a best practice, and nothing will change his mind about that. Similarly, he has made up his mind on GNOME Shell it is “McCann’s” plaything, design suggestions made early in the process were ignored, and even though he now admits that the result is better than the early mock-ups, it is clear to me that there is no chance that Ubuntu will ever voluntarily adopt GNOME Shell.

We have two problems: first, that key figures in our communities can rub people up the wrong way. Second, it’s easy to ascribe to entire groups the characteristics of the people we come in contact with.

To solve the second problem, we need to start using names instead of project names. It’s too easy to ascribe ill-will to an anonymous faceless project, it’s another thing to do so to an individual with a name & a face. GNOME didn’t reject the StatusNotifier spec – two GNOME contributors on the xdg@freedesktop.org mailing list who read the spec (and who were in a position to do something about it) felt that their concerns were getting short-changed, and disengaged. I’d wager that 90% of GNOME project members didn’t even know about xdg before this week. Let’s call each other by our names (and be nice while we’re at it).

Behind closed doors conversations are poison

Another major issue we’ve had is a distinct lack of tracability. It isn’t helped by many Canonical developers using infrastructure which the appropriate GNOME developers don’t – but in fact I don’t care what public forum you use to develop & talk about your software. What is harmful is what I’ve dubbed the Water Cooler – when too many conversations happen in private email, at conferences over drinks, or on IRC, there is no tracability. One example: A key event in the timeline of shell/notifiers/Unity was the UX hackfest in 2008. Different people say different things were said. And there is no written trace of agreements or proposals concerning notifications. I was told that there were some conversations after the conference on IRC, but nothing was sent to a mailing list or recorded in a wiki page.

A member of the GNOME Shell team recently, in response to some questions about design decisions, said that a lot of the discussions & reasons behind the design would have happened on IRC. So there is no trace.

I have personally been involved in dozens of OTR discussions with Canonical people. I recall one where Jono urged me to “step up to the plate” and provide technical leadership for GNOME – my response was that that wasn’t the role of the board, that the distributors who depended on GNOME for their products had to set the lead. It would have been nice to have the discussion in public.

I know that writing stuff down after the fact is a pain. But it is required to allow for a traceability of community decisions and agreements – and also to highlight misunderstandings. If I had a dollar for every time I’ve had a conversation with a client about a technical spec, and he understood something different than me, I’d have enough money for a nice meal. By writing down understandings in clear and unambiguous terms, you are also giving the other party to the discussion the opportunity to correct misunderstandings early.

I also understand that there is an interest in putting on a good face, and not airing your dirty laundry in public (ironic, eh?) – for the past few years, the party line in Canonical has been “We love GNOME, we’re a GNOME shop” while behind the scenes there have been heartfelt conversations about the various problems which exist in GNOME & how to address them. The problem is, because these discussioons happen behind the scenes, they stay there. We never get beyond discussions, agreeing there is a problem, but never working together on a solution.

The party line in GNOME & KDE has been “we’re all pulling in the same direction, we like each other” – and for the most part it’s true. But if this week has shown nothing else, it’s shown that senior members of the KDE & GNOME projects actively mistrust each others motives & don’t believe we have the same interests at heart. At least, this is clear from Aaron Seigo’s comments on his blog post.

For people to work together, they need to be in the same place

I have seen a number of people say that Canonical worked on libappindicator and Unity “internally, not in the open” or that “a lot of design in free software are (sic) developed in secret”. Yet the code is open, the entire history is in Bazaar… how is this consistent?

First, design is not code. Design documents can behave like code, however, with peer review and an iterative process, and can be wedded to the process of developing code, evolving as technical constraints and schedule pressure get in the way of the original design. Good designers work with coders – and this is how it happens in Canonical too.

However, Canonical has occasionally opted to create new projects, housed in Launchpad, rather than engage existing projects to evolve them. libappindicator is an example – several people suggested that it should/could be part of GTK+ – what changed between January 2010 when Ted Gould said ” I’d like to think that the code in libappindicator would useful, and maybe even migrate into a replacement for GtkStatusIcon in GTK+” and February 2010 when he wrote ” Q: Shouldn’t this be in GTK+?
A: Apparently not”?

Canonical has a policy that Canonical development is done in Launchpad, using Bazaar. Sometimes that’s fine – if you’re originating a project, then you get to choose the infrastructure. Bazaar & Launchpad are working just fine for a plethora of projects. But when you are working with other projects, you need to be where they are.

Cody Russell, long-time GNOME contributor, former Canonical developer, and the developer of client side decorations for GTK+ among other things, wrote in a comment to Aaron’s blog:

CSD is really not a good example of how stuff development between Canonical and GNOME should work. I’m the person at Canonical who started CSD, but never finished it.

It started as just an experimental hack, and somehow got picked up as a “Canonical project”. Once that happened my immediate manager told me to stop committing code to GNOME git and do any further work on it privately in bzr.

For me this made developing it further much more difficult, because it was an extremely large and intrusive change into GTK+ source code and my manager didn’t want upstream developers to help me with at least peer code review.

Apparently there was originally some desire to have libappindicator developed as part of GTK+. I don’t know why this did not happen, but perhaps the quote above can give some insight into why the project was developed as an independent module.

Similarly, having a discussion on a freedesktop.org list does not ensure that you are getting appropriate cross-platform buy-in for your ideas. There is no guarantee that you are talking to the right people.

Most free software developers I know are on lots of mailing lists, and for all but a small number directly related to their day-to-day work, they glance over them. I certainly fall into this camp – there are about half a dozen lists I’m on where I will open maybe only 1 in 10 emails, with a subject that looks like it might concern me directly. If you want to directly get my attention outside of that, a personal email, IRC ping or IM asking me to comment on something is a good way to get my attention.

In the early days of freedesktop.org, this is how things worked. There were well defined problems that needed solving, and the people concerned made a conscious effort to get the right people into a central desktop-agnostic mailing list. As time goes on, maintainerships evolve, people change jobs, new people arrive – there is no longer any guarantee that the people on the freedesktop.org mailing lists are the best people to be talking to.

Moving on

So where do we go from here? Well, first GNOME 3. We have a release coming up, and so does Ubuntu, and we’re both going to have a bumpy ride for the next few months, so that is presumably going to be the priority for everyone.

After that, the Desktop Summit will be an opportunity to start building bridges. We’ve made an effort this year to avoid tribalism in the conference, by framing the call for papers according to problem area (multimedia, mobile, platform, etc.) rather than by desktop. We will be continuing this, I’m sure, through paper selection and drafting the agenda. That said, you can bring a horse to water, but you can’t make him drink.

Looking through the list of headings here, a number of them are easily fixable, a number of them are much more troubling, and a result of letting discontent fester for months or years.

We can certainly improve the operation of freedesktop.org – currently there is no freedesktop.org as such, it’s a wiki & a mailing list server. To improve it, there needs to be a process whereby things are agreed, and a way to ensure that all concerned parties are engaged in that process. There were discussions about this in Gran Canaria, including members of both the GNOME and KDE projects. But to evolve freedesktop.org, buy-in of a number of key GNOME developers is essential – I can’t imagine any long-term changes happening without Owen Taylor’s agreement, for example.

We can increase the transparency of the operation of individual GNOME modules. This is one of the things I hoped to achieve last year with the GNOME census. By identifying the key contributors for each module, and the processes under which each module operates, we can help reduce the friction when people try to figure out how to work with GNOME. Ideally, something like Jon’s guide to the kernel will help reduce the number of dropped or unreviewed patches, make it easier for people to see what kinds of contributions would actually be welcomed by module maintainer teams, and help people figure out how to gain influence in a specific module and eventually become a maintainer themselves.

We must reduce the amount of back-channel discussions between the various project participants. Any important decisions or agreements that happen off-line must get written down & agreed to after the fact. IRC usage has become predominant in some teams, resulting in a lack of transparency of operation – GNOME should adopt the Apache policy of “if it didn’t happen on the mailing list, it didn’t happen” and encourage companies who want to encourage change in the project to do the same. I would appreciate all participants committing to a general policy of releasing design specs and code early to peer review – and in the case of Canonical, working upstream before working in their own distribution.

I think there is a potential for a GNOME Design group, for example, with qualified designers in a publicly archived, but invitation-only, mailing list, to allow design collaboration without a high level of poor quality amateur participation which has typified public usability or design lists.

Finally, smaller, focused teams, started on a case by case basis, will serve us better than long-living “collaboration” mailing lists like desktop-architects or xdg. To ensure that the right people are at the table, they need to be invited, and their presence needs to be documented, on a project-by-project basis. Of course discussions on these lists should be publicly archived, but they should only be useful as long as the specific problem area is being addressed, and should die a natural death afterwards.

That’s the easy stuff.

The more difficult issue is that we have allowed relationships to degrade so far. It feels like GNOME & Canonical are in a bad relationship – we used to love each other, and now every time we talk it seems like we’re speaking a different language. For a while, it seemed like GNOME & KDE contributors were working productively together & overcoming some of the historical issues between the projects, but over the past 3 years, it’s been clear that the progress we had achieved was illusory, and that deep-seated ill-feeling among a small number of project leaders have ensured that any early progress has been squandered.

In addition, all of GNOME, KDE & Canonical have allowed personality issues to build up. One need only follow the discussions within the GNOME foundation concerning the Code of Conduct to see that the GNOME community has allowed some loud & confrontational characters to gain positions of authority in the project, and KDE is also no stranger to such personality issues among prominent developers.

Solving this problem is much more difficult, if it’s solvable at all. Change inside the GNOME project can only come from the grass roots, and the same goes for KDE. Adopting a code of conduct is less important than actually being nice. Too many people confusing being rude and abrasive as being terse and efficient. And getting a critical mass of community leaders in the same place at the same time to concentrate on common issues and approaches to solving them is difficult when there is so much pent up frustration and ill-will involved.

The Desktop Summit will be an important meeting point this year, where hopefully some of these issues can be resolved. In the meantime, I hope that we can start some small conversations soon to get people talking and trusting each other’s motives again. It will be a long and arduous process, and will require everyone to accept part of the blame for the situation we find ourselves in, and to accept the better days are possible.

As I said to Jono Bacon yesterday when he suggested we should all just get along & stop digging up the past: “Those who ignore the past are doomed to repeat it. And we have been failing for some time to understand the issues which people have working in freedesktop.org, or with GNOME, KDE or Canonical”. Unlike some people commenting on the various blog posts this week, I think that getting some of the dirty laundry out into the open will be beneficial to the general working environment. Sunlight is a great disinfectant, they say, and a number of issues have been kept under wraps too long by people who want to put a brave face on & pretend for public benefit that everything is rosy.

Well, everything isn’t rosy, and now even a fool could see that. But I don’t think there’s anything broken that we can’t fix. Let’s concentrate on getting GNOME 3.0 and Ubuntu 11.04 out the door, and then get to work mending relationships.

119 Responses

  1. daniels Says:

    At the Desktop Summit in Gran Canaria, there was a fd.o BoF where GNOME and KDE people got together and talked about how to fix fd.o and make it a useful semi-standards body. There was a fairly concrete process agreed that both sides seemed fairly invested in, but nothing ever really came of it.

    So at the moment it’s still basically just a hosting organisation, because no-one who knows and cares deeply about those kinds of specs, as well as has the time, has been able to step up and take it on.

    *shrug*

  2. Juanjo Says:

    I’ve been confused by fd.o for a long time, because I thought it was a project to build bridges between the different desktops, but lately looks more like a throwable weapon.

    Nice and informative post, worth reading. Thanks!

  3. Juanjo Marin Says:

    After too much blame game and nonsense these days, I think your post as healthy as a breath of fresh air. thanks !

  4. Sam TH Says:

    As someone who as active in GNOME a *long* time ago (I attended GUADECs 2&3), I think this account of GNOME’s technical leadership/history is subtly wrong.

    GNOME used to have (informal) technical leadership, and doesn’t anymore. The primary reason is that the technical leaders left the project, and couldn’t be/weren’t replaced.

    At GUADEC 2, it was obvious who the technical leadership was: people like Havoc, Nat, Miguel, Maciej, Owen (there are others that I’m surely forgetting). Since then, all but one of those people has stopped being in a position to be a technical leader for GNOME, for lots of different reasons. This happened over a period of 10 years, and ultimately there’s no one in the community who’s taken their place.

    This has left GNOME with a project that has neither formal nor informal technical leadership, and it leads to many of the problems you describe.

  5. Daniel Rodrigues Says:

    Well, you’ve said it all here. This kind of conflicts, this constant discussion environment (more and more looking like severe argues), only and only harms the community, not GNOME, KDE, Ubuntu but the entire community. Who would want to develop, who would want to integrate a community where constantly “shots are being fired”? If we want to succeed in the mainstream market, we need to engage developers.

    In order to do so, a harmless, welcoming, safe, a warming sense of fellowship is needed here, in the Linux community. We used to have it around here. Now we don’t. Not to have it is toxic, dangerous for the future of the community. I’ve already read some comments around the web from (now fellow) Linux users saying that the Linux desktop was going nowhere, specially with hostile atmosphere now installed.

    We need to make things happen, instead of stopping them from happening. We need all to be more open (Canonical, we’re looking at you), more open-minded (looking at you now, GNOME) and we need to remember that we all have the same purpose: to make Linux rock on the desktop and give users pure GTK/QT/Nux/Javascript/whatever Linux-awesomeness. How about that?

    This’s something we all should learn from. Events, times like these show simultaneously our worst and our best. Our worst seems to be everywhere. Now it’s time to make our best emerge: our ability to sit down, talk, laugh, analyse, settle the old conflicts, let the dust settle and discuss, wisely plan future points of convergence, of collaboration, of interaction, of cross-desktop compatibility. And, of course, always striving for excellence.

  6. M. Says:

    Great post. This is the most reasonable (and the only possible) position about this “matter”. I really hope everything will sort out.

  7. Poi Meyers Says:

    it’s clear to me that you and gnome people in general does not want to collaborate. and, of course, most of you(gnome people) hate canonical.

  8. Markus S. Says:

    At the point that GNOME developers Dan Winship & Mathias Clasen, and Citrix developer Giles Atkinson, reviewed the spec and made comments on it, too much had been invested in it to make major revisions.

    I tell you how democracy works: When there is an election, you go vote. When you don’t vote, live with the result.
    You wrote yourself that the GNOME side had no interest in even looking at the specs until it was too late.

    So even if StatusNotifier is not perfect, the thing to do by the GNOME side would be to adopt it anyway and help revamping it for spec 2.0, just as KDE adopted dbus even though their DCOP was better at that time.
    GNOME could even still have developed their own specs but at least make Shell compatible to StatusNotifier because that’s better than keeping XEmbed as lowest common denominator.

    I fiercely defend GNOME on many occasions but not adopting StatusNotifier and instead developing an entirely different spec that is not even recognized by a broken standards body is certainly not one of those occasions.
    That said, the way Canonical tried to push StatusNotifier/AppIndicator down GNOME’s throat was in no way excusable.

  9. Dave Neary Says:

    Hi Sam,

    You were around GNOME before my time, indeed – my first GUADEC was Kristiansand in 2004, but I had been around GNOME for a while at that point.

    My understanding, from many many discussions, was that there was a conscious effort at the creation of the foundation to spread the power around. At that point, Miguel was the BDFL of GNOME – the creation of the foundation was a pivotal point where this stopped being the case.

    Regardless, as you point out, the founders have moved on, and the only individual I can think of with the project-wide relationships and vision who could possibly hope to lead the project at this point is Federico Mena – and I would be delighted to see him auto-proclamate himself “Chief GNOME architect”.

    Dave.

  10. Justyn Says:

    I know I’m not the only one who has been feeling terribly disenchanted with the FOSS desktop effort(s) recently.

    This last week it had reached a peak where I saw no way out, and really just wanted to give up and forget about these projects and their bickering people.

    After reading this post I am feeling some optimism again.

    I truly hope that all the parties involved will read what you have said carefully and have the strength to recognize that they have all contributed to the current state of affairs – instead of stubbornly shoveling blame around.

    And then I hope we can deal with the root causes and make things better.

    Thank you for writing this.

  11. bombo Says:

    Lessons learned:

    When someone in the free-software world creates something good for users using an OSI-approved license and you try to imitate their stuff (after whining they didn’t invite you) but can’t stand comparison with this “something”, just bash this “someone” in every way you can.

  12. Thiago Teixeira Says:

    Hey, I just wanted to congratulate you on the amazing blog post. Very articulate, sober, to-the-point — and containing some great advice on how to proceed from here.

    So let’s all fix these communication problems ASAP and continue doing what we do best: designing, coding, testing, and using free software.

    Cheers,

    – T

  13. Hylke Says:

    “I think there is a potential for a GNOME Design group, for example, with qualified designers in a publicly archived, but invitation-only, mailing list, to allow design collaboration without a high level of poor quality amateur participation which has typified public usability or design lists.”

    This has been going on for well over a year on #gnome-design and the wiki.

    Designing in the open works. No need for closed mailing lists.

  14. Donnie Berkholz Says:

    I would go even further and say that if it’s not written down in a permanent form of documentation, it didn’t happen — as far as major decisions and rationale go.

    Too often people post to a mailing list or write a blog entry, then it’s lost in the ether. Sure it was written down, but nobody will ever be able to find it.

    These things belong in a permanent, centralized set of design docs for a project.

  15. Theodore Ts'o Says:

    The key problem is that the desktop community desperately needs one or more architects who can act as a sheepdog and keep the sheep marching in roughly the same direction.
    It’s far more critical in the Desktop world than in the Linux kernel because in the kernel, there is enough development in the kernel that there is strong incentive to develop in the upstream sources, and not behind distribution-specific source trees. In addition, the Linux kernel releases on a regular 3 month cycle. So even if we don’t have formal design documents, it’s a lot easier for collaboration between key kernel subsystem developers, because our patches have to come together and _work_ every three months when we push out a release. (In practice, they had better mostly work by the end of the two week merge window, or there will be hell to pay, and Linus, as the great benevolent dictator, will yell at people, and Make a Decision — which will usually involve reverting the change which broke things functionally.)
    In contrast, the Desktop world has a much harder problem, because (a) not everything lives in one source tree, (b) the kernel largely doesn’t have a UI, and there are objective measures of “does it work”, and “did the benchmark results go up or down”, that either don’t exist or aren’t as important in the UI world. Questions of whether a UI is “good” or “better” than some other UI choice is a question which can’t be easily answered objectively. And that, more than any thing else, is probably why we have three major design centers for desktop development: GNOME, KDE, and Canonical.
    One of the things that worries me is that all too often, people look at the way things are done in the Linux kernel, and assume that it will port over to their project. In most cases, the Linux kernel is a much larger and more complex project, and things which we done in the Linux kernel world probably aren’t needed in other projects. But in the Desktop world, I think the reverse problem is true. It’s a much larger and more complicated problem than what we have in the Linux kernel, and so decisions such as allowing the major subsystem developers to negotiate major technical changes can happen organically might work for the Linux kernel, but not in the desktop world. (For example, in the storage stack, there are less than a half-dozen people I would need to consult with in order to come consensus about some change to accomodate PCI-attached flash, and we have multiple opportunities a year to get together and work things out). Hence in the desktop world, hiring a full-time architect who did nothing else but talk to the different stakeholders and try to come to consensus on a common vision is probably something which is necessary, even though we haven’t found the need to have someone in that role in the Linux development community.

  16. Michael Pyne Says:

    Dave,

    Perhaps you missed it, but the problem statement that you mention being helpful was actually included (in at least a limited form) in the email from Marco Martin that you quoted [1]:

    In the past few months in KDE we worked on a new way to represent the systemtray icons to overcome the following limitations:

    -lack of communication between the systemtray area and the items, that mean we don’t know about their status, their importance of if they are
    being used or not

    -the xembed process is quite slow and doesn’t give control to the
    systray on the paining

    -it’s not possible to have more than one systray (useful in multi
    monitor setups)

    The first point is important for things like automatically hiding unused icons, while moving visualization from the XEmbed widget to the desktop hosting the icon is important for appearance. For instance if you have ever used GAIM on a KDE 3.5 environment, the GAIM notification icon would have looked significantly out of place due to not supporting transparency as KDE programs did.

    Separating visualization from application was essentially the whole idea to the specification, and D-Bus was relevant only insofar as it allowed that separation to occur. The problem was *not* a way to somehow conjoin D-Bus and status notifiers because it would be cool.

    Regards,
    – Michael Pyne

    [1] http://lists.freedesktop.org/archives/xdg/2009-September/011038.html

  17. Also Says:

    8. GNOME is a really stupid name for desktop software.

  18. Jimmy Smiths Says:

    @ Hylke

    Given the ongoing furor, claiming that “it works” doesn’t seem very convincing.

    Also, #gnome-design is not archived. So that’s not “in the open” then.

    @ Dave Neary:

    Congratulations. First post about this that really made sense.

  19. Sembla que les relacions entre GNOME, KD … « Només 5 línies Says:

    [...] que les relacions entre GNOME, KDE i Canonical no són gaire bones. :’( http://blogs.gnome.org/bolsh/2011/03/11/lessons-learned/ Som a l’hivern o a la tardor dels entors d’escriptori lliures?   LikeBe the [...]

  20. Henrique Says:

    Well, if fd.o needs a more formal process (and it _does_), and they’re unable to come up with something that works (which seems to be a fact), maybe they should just adopt IETF’s ?

    It is lightweight enough and yet formal enough that it gets the job done. It is far from perfect, but far better than a void where consensus is easy to ignore, and vague document dumps can happen.

  21. Canonical must change copyright policy | Linux Desktop Says:

    [...] Neary’s addition to the argument is sober by comparison to that of KDE developer Aaron Seigo, it serves only one [...]

  22. Neal Murphy Says:

    (Agreeing tersely and colloquially) well, duh! I don’t have a dog in any of these shows. But I’ve seen these things happen time and again in industries wholly unrelated to software. I hope you don’t get any “talk to the finger” responses.

  23. Sankar Says:

    Excellent post. I loved every line of it. You have categorized and summarized in a perfect way.

    Looking at last week’s events, and the comments of some KDE people, I wondered if there is even any use of having FD.o It projected such an abysmal image. Some KDE devs complained that GNOME has not accepted anything from KDE for the last 5-6 years. I personally consider it to be “Naive” to wait so long and never talk about in public, until an opportunity came up for Canonical Vs GNOME. May be having a FD.o architect committee which will take care of ensuring smooth (and open) talks between GNOME and KDE might help ?

    Regarding Canonical Vs GNOME, Shuttleworth is trying to be a back seat driver. As I mentioned in my blog post, “If you want to drive the project in your way, grab hold of the steering, dont be a back seat driver.” If Canonical had done their development in open and had people who could influence in DDL, Release-team etc. it wouldn’t have been so sad. The ex-employee statement is shocking indeed.

    Once again, I loved your blog post. It is an inspiration for me to write better. Thanks.

  24. Máirín Duffy Says:

    “I think there is a potential for a GNOME Design group, for example, with qualified designers in a publicly archived, but invitation-only, mailing list, to allow design collaboration without a high level of poor quality amateur participation which has typified public usability or design lists.”

    Boohiss. I’m with Hylke.

  25. nobody Says:

    Come on now! There’s a large number of emails in KDE mailing lists that describe the problem with the notifications. What you’re saying is: KDE guys chose to waste their time by designing some useless spec, and GNOME guys were clever enough at the time to see that it was a waste of time.

    Then why did you see the need to implement an incompatible spec years later? Why was it incompatible? Why did you ignore the KDE fd.o spec in the first place?

    The rest is simply hand-waving.

  26. bombo Says:

    i’d compare fedora and ubuntu (stock versions) and try to guess which team is leading the scene (and so, which design is working)

  27. Шаттлворт и Нири рассуждают о конкуренции и взаимодействии между проектами Ubuntu и GNOME | AllUNIX.ru – Всероссийский портал о UNIX-системах Says:

    [...] день, Дэйв Нири (Dave Neary) подготовил развернутый ответ. Краткие тезисы [...]

  28. Ian Says:

    Seems like Gnome needs to get their head out of their a**es and learn what collaboration means.
    Since day one they’ve been a “holier than thou” bunch and full of their own self importance when they thought they were being better than KDE on their choice of QT.
    Gnome are Microsoft in another guise

  29. Pawlo Says:

    Hi,

    I don’t understand some of you points. In example why are you saying Canonical doesn’t understand gnome? They (and KDE too) wanted to make some unified system notification, but you just showed them middle finger. There are more examples of your bad will:

    – swapping confirmation buttons to be not compatible with KDE,
    – while KDE put a lot of effort to make its apps look nice in your DE, gnome apps look like crap in KDE, and it seems you don’t care about this issue at all,
    – you decided to use something called ‘tracker’, so you another time ignored efforts to have a unified searching engine,
    – you’re using (unlike FLOSS and KDE) ms tech – mono,
    – you support/supported (unlike FLOSS and KDE) ms ooxml,

    I hope Canonical will show you a middle finger this time, so such broken project like gnome will die quickly.

  30. ebassi Says:

    @Markus: a) GNOME is not a democracy, but it’s a meritocracy. b) a specification, as much as the name does not apply to the StatusNotifier document, for interaction is not the result of a democratic process. so your comment is wrong in both contexts. nice try, though.

  31. With A Little Help From My Friends « Allison Randal Says:

    [...] take Dave Neary’s comments about private conversations to heart. To provide a little historical illumination, five years ago Dave and I founded a group, [...]

  32. Vadim Peretokin Says:

    So GNOME is without a stable leadership, and thus is has individual members deciding for the whole organization (with their technical decisions of approving or disapproving components and contributions).

    This is silly and embarassing.

  33. Hylke Says:

    @Jimmy Smiths: Sure, we can do better in that regard.

    My point was about Dave Neary’s point:

    “I think there is a potential for a GNOME Design group, for example, with qualified designers in a publicly archived, but invitation-only, mailing list, to allow design collaboration without a high level of poor quality amateur participation which has typified public usability or design lists.”

    Having a closed mailing list is probably the last thing you want to do right now. It gives a bad feeling of arrogance and elitism. That was the feeling I had when this was the plan for the ayatana list. Yes, there is noise sometimes, but nothing that cannot be dealt with.

  34. Andre Says:

    “This is not surprising when you consider that it’s written right there on the front page: “freedesktop.org is not a formal standards organization”.”

    A formal standards organisation is de jure. Freedesktop however was tasked to lead to desktop conversion / interoperability as a consortium with joint specifications. What was reported to me from participants is an annoying tendency of GNOME members to push their technologies as a Freedesktop standard, regardless of the needs of smaller desktop environments.

  35. The Full Story Behind the Canonical vs. GNOME Drama | JetLib News Says:

    [...] comments about GNOME (or the others involved) rather baseless and illogical. Dave Neary has an extremely thorough blog post which details problems on all sides that make the issue much more complicated than ‘GNOME is [...]

  36. moshe Says:

    great article, even though i am not sure i agree with most of your interpretations (on the other hand i am rather new to the FOSS world).

    one question though, the ex-employee from canonical said that canonical didn’t want him to keep his work on the GNOME git, is there a reason?
    after all, one of the advantages for developers to develop open software is the ability to use the help of others, if you don’t keep them in the loop it becomes much harder to develop.

    so i guess there is a reason for canonical to either not let the project continue on the GNOME git, but what is it?

  37. Shawn Says:

    No, Freedesktop.org is not a broken standards body. I followed the systray proposal and it was done in a transparent and open manner. Don’t blame FDO for GNOME’s inability to collaborate!

  38. Deltaray Says:

    Honestly. I think all this is all awesome. Not necessarily your post, but what you are talking about in your post. I feel like the democracy of open source is functioning and breeding new developers. You guys just need to take a break. Have a team building experience and not take it all too seriously. Go to Disneyland.

    Your account of everything makes it all sound just like a government’s bureaucrats at work. That might not sound like a good thing, but it tells me that there is activity and the community is alive and cares about progress. Its quite far from being dead like some closed source slanted media likes to herald. If we all really care, then it will keep going. And there is no shortage of people who care about what we are trying to accomplish.

    Another thing to remember about open source is that it is development like no other way of development. When things are so open, you have to be more protective. Its like a museum with the crown jewels on display. I remember hearing about a community radio station that had a loophole in its bylaws that in the end allowed members of a local church (that didn’t like the kind of music they were playing) to send its members into a board meeting, each pay $5 and then vote the board out and take over the radio station. So with that in mind its understandable that development communities are resistant to allowing those in that don’t have a trusted history.

  39. Roland Says:

    Freedesktop is an attempt to unify desktops. DBus is an attempt to unify notifications. These are attacks on diversity. Why can’t each group just ignore the others and march to their own drummer? I don’t see the need for ANY standards with regard to desktops. Both seem to want to control users’ desktops. KDE3.5 put users in control. I’ve abandoned KDE4.4+ because it doesn’t do that. Gnome is no better. Time for XFCE. Unanimity is a bad thing. Especially if someone is trying to enforce it. That’s how the US got into these stupid wars.

  40. William Stone III Says:

    I’d like to inject something here that may or may not be helpful. I’m going to be blunt at times, but I’m going to call it like I see it.

    I’m neither a developer nor involved with Gnome, KDE, or Ubuntu except as a user. I’m a systems engineer/administrator of some 32 years’ experience. I was a very early adopter of Linux, coming on board with the old Caldera Network Desktop distro because of its interoperability with NetWare (at the time the reigning king of LANs).

    I used various Red Hat distros for years, then switched to Ubuntu because they’d successfully figured out how to make a distro that installs and runs without incident on almost any X86 hardware platform that I threw it at. I still primarily use Red Hat or CENTOS on servers.

    I’ve primarily used GNOME over the years.

    As a user, I’ve watched the internal squabbling with some dismay. I didn’t really much until Ubuntu’s decision to go with Unity. At that point, it began to impact me as a user.

    I’ll be frank: when I first heard Ubuntu was going with Unity, I thought that perhaps it was a good idea. I’d attempted to use GNOME Shell and was turned off by it. VERY turned off by it.

    In fact, my reaction was (and remains) very simple:

    Has the GNOME project lost its mind?

    GNOME Shell is very cute and spiffy-looking, but it’s monstrously difficult from the perspective of trying to get work done. I need a computer I can fire up and immediately comprehend how to get my work done. If there are bells and whistles to make my life easier, so much the better.

    GNOME Shell is impossible for me to plop down in front of and use. It’s as simple as that.

    So when I heard about Unity, I thought perhaps it was a good idea. If the GNOME Project had collectively lost its mind, then it was time to use something else.

    Unfortunately, Unity isn’t any better — in fact, it’s WORSE in some ways.

    My thought with Unity is the same as GNOME:

    Has Ubuntu lost its mind?

    The Unity Desktop is as non-intuitive and difficult to use. It drives me insane to not be able to click back and forth between windows, to have a bash shell that’s damned near fullscreen, etc. I need to have multiple windows so I can be puttering away in one while logs stream past on another.

    In short: all y’all are NUTS at this point.

    You’re both building products that don’t make things any easier. In fact, I’ll come right out and say it:

    I see absolutely no reason to migrate away from a “Start Menu” and Taskbar-style desktop. It works, it makes sense, I can open and close my windows intuitively, etc.

    I’ve tried making my desktop more Mac-like on occasion, and I keep coming back to the “Start Menu” style. It just works.

    Were I to make any changes for improvement, I’d simply make the applications menu point to a subdirectory full of symlinks rather than need to be manually edited. It would save time.

    The reason I bring this up here is that after reading this, I can get some indication of how and where all y’all have lost your collective minds. It’s the in-fighting.

    With the various internal struggles, it’s clear that none of the developers have asked themselves, “Can anybody but us actually use this thing?”

    I believe that you’ll find that the answer is a resounding “No,” and it will be made crystal clear with the next release of your products.

    Your users are going to take one look and say, “Screw this nonsense … I’m going back to Windows.”

    Both GNOME and Ubuntu are about to slit their own throats — which is a shame, because I love the current incarnations of both products.

    Both GNOME Shell and Unity are massive steps backward in terms of user experience and usability. Release them in the form that I’ve tried, and you WILL fall flat on your faces.

    Strategically, this couldn’t come at a worse time. I’ve been in the habit of suggesting users switch to Ubuntu for about a year. I will no longer be able to make this recommendation in good conscience because users will have no idea how to use it.

    You are undercutting Linux adoption. The in-fighting has led to bad software design, and that design is about to be released. It’s a shot to your own brains.

    Get it together. Stop the petty bickering. Go back to your IDEs and come up with a desktop I can USE.

  41. Android OS news » The Full Story Behind the Canonical vs. GNOME Drama Says:

    [...] comments about GNOME (or the others involved) rather baseless and illogical. Dave Neary has an extremely thorough blog post which details problems on all sides that make the issue much more complicated than ‘GNOME is [...]

  42. Claude Says:

    “Reading the thread on freedesktop.org where the StatusNotifier spec was being discussed, it’s clear that Dan and Matthias considered that Aaron was being dismissive of their concerns – and I can certainly see why. ”

    I can’t. I read it again (and again), Dan starts with an admittedly harsh sounding posts (he feels compelled to add an emoticon as a foreword, not to rewrite it), Aaron’s answers include parts where he agrees on changes to be made and others where he asks for real-world use cases before agreeing for the change. The only time he is dismissive is when Dan and Matthias’ concern are somewhat orthogonal to the goal of the spec (they show concern for the visualization, and he wants to separate signals from visualization, and the spec is about signals). That’s far from being completely shut down in my view.

    What’s more, in the comments to this blog post, Aaron also states several other cases where he feels collaboration wasn’t as should have been. The only answer to bring to that is not resolving to describing him as difficult to work with (he may well be, I don’t know). It is addressing these highlighted issues. What’s up with this git repo, for example? Nobody from GNOME is answering, whether providing their side of the story, or acknowledging any mistaske. In my view, that’s the first step, if you want to move on.

  43. Greg Says:

    Karl Fogel in his book on how to run an open source project, makes many of the same points. especially the ones about having everything take place in the open and have a documented audit trail.
    http://producingoss.com/en/producingoss.html

  44. Spooky Action Says:

    Excellent post. While not a contributor to GNOME or KDE, I’ve been using Linux on the desktop for well over a decade now and often wondered why desktop development in Linux seemed so stagnant. In my time as an admin, I’ve seen Linux grow from an OS for hobbyist to an enterprise level server OS, but desktop development was (and still is) painfully slow in comparison. GNOME has barely changed in a decade and still has some of the same annoyances it always has, like why do icons on the panel rearrange themselves unless you lock them down and why does the default theme look like a mutated version of Win95? Looks do matter in UI design to the end user, which is the real audience of the desktop. Us in the Linux world can appreciate the technical aspects of the OS and the benefits of open-source, but the average user wants/needs usability and something that looks decent. KDE is moving in the right direction, but still took years to address basic issues with the UI (e.g. a real file browser for one), while Mac OS and, I hate to say, even Windows has progressed in leaps and bounds. Now I know why.

  45. RCasha Says:

    Perhaps it would be useful to look at the Java standards process – JCP – as a model. While it has its flaws, these can be identified and dealt with in creating a new freedesktop.org. It allows standards to be announced and developed with the participation of all interested parties.

  46. Ted Says:

    @bombo: Somehow I think that there are many, many other factors at work in the relative popularity of Ubuntu vs Fedora, marketing being the most obvious. If there’s one thing that Mark Shuttleworth knows, it’s how to create a buzz. There’s also the fundamental differences in the distros, such as stable vs bleeding edge packages, package management, et al.

    Anyway, you really can’t take popularity as the measure of successful design regardless, or else you would have to concede that Windows XP has the best interface designed, ever. ;)

  47. Ian Says:

    What i can read from this blog is that he is making excuses for GNOME not collaborating. GNOME were always a “me too” desktop group who produce an inferior product from a technical and design point of view, it was just a matter of principle, and not technical, to create something that didn’t use QT because QT was closed at the time. I bet they feel a little stupid now QT is open.
    GNOME, Canonical – learn to collaborate and stop working in your elitist silos, use fd.o and discuss with everyone when a spec doesn’t quite meet your needs because at the moment, GNOME especially, is behaving just like Microsoft by going off using their own specifications/standards. Perhaps we could rename GNOME to MSGNOME

  48. Paul "TBBle" Hampson Says:

    I found this article fascinating, because it portrays GNOME as executing a very different method of achieving standards than I understood to be the case in open-source software (and also in other realms)

    The GNOME method appears to be:

    Define the problem
    Identify the people invested in the problem who’re going to work to solve it
    Create a specification for the solution
    Implement the solution

    My understanding of the general flow of a successful standard is:

    Implement a solution to a problem
    Create a specification from that solution
    Get others to implement independent solutions to the same spec, iterating the specification as issues are found with it.

  49. ysth Says:

    You aren’t going to get people doing one kind of communication (IRC) to just switch to another (mailing list) for “transparency”. People will continue using the kind of communication they are used to or feel will best work for the task at hand. Rather:

    First, concentrate on getting the IRC channels publicly archived. Second, if necessary, encourage post-debate (or daily/weekly/whatever) writeup of what was discussed on IRC and get it posted to a list or on a blog.

  50. Paolo Says:

    @William Stone III (reply #40): I completely agree with you.

  51. oiaohm Says:

    Why is freedesktop broken simple fact its not. This is the problem I was there at the start. Currently is functioning perfectly as designed.

    First standards created. .desktop file format and the default menu everything you said was done.

    Panels of the willing formed and all the processes were done.

    Ok Lets lay out how Freedesktop is meant to be running. Started clearly on the front page. Freedesktop is not a standard body. Freedesktop is meant to be for drafting the standards.

    Each draft standard is meant to state the problem they are trying to solve.

    If a draft standard does not suite an counter standard is meant to be formed or the current standard improved.

    There is meant to be a version 0.1 document stating what the problem is without specifications so feed back can come. That has been highly neglected in recent years.

    Yes you are free to complain about standards coming too late to freedesktop.

    When was the last time Gnome BSD… Submitted a new draft standard.

    Basically by freedesktop.org rules if you did not like the StatusNotifier spec you are meant to propose your own replacement if they will not change theirs.

    Please be aware .desktop files have nothing in common with what KDE or Gnome or anything else was using to store there menu entries prior. This was a freedesktop solution.

    Amount of work invested so far means nothing since the standard is only draft by freedesktop rules is free to rip it up and completely start again with a better design.

    As a full proper standard body dropping a standard in the shredder and starting over is not allowed.

    People proposing the standard to freedesktop.org get to choose development system. So if you put forward a 0.1 you can then decide to go to a body people to discuss the problem.

    The design of Freedesktop.org is intentional. Freedesktop is design that a non working party will not stop its progress.

    Gnome is currently a non working party. Any non working party will end up steamrolled. This is the design. There is no requirement to be friendly to non working parties at all.

    This comes from people like me having to go around chasing down all the windows manager people doing menus to get all of them to the table to talk. This is non productive and a waste of time.

    Anyone not interested in standard should be steamrolled that is the way it is.

    Basically freedesktop Broken argument is false. Gnome involvement with freedesktop is broken and KDE is not running ideal.

    Should KDE have counter draft standards against theirs appear at times. Yes their should be.

    Due to freedesktop.org design it will steamroll forwards no matter what. Question is where on the steamroller do you want to be in-front of it or at the steering wheel. Current gnome is laying in front of it.

  52. Gürkan Sengün Says:

    GNOME first should fix their file selector. It’s the worst I’ve ever seen.

  53. nicu Says:

    @William Stone III: agreed 101%

    as for the rest of the GNOME war, which is one side Mccan’s personal playground and on the other Mark’s… i hope both sides die due to user rejection, after 9 years of having GNOME as my primary desktop, i am contemplating switching to Xfce to be able to get my work done, currently resisting upgrading from GNOME 2.x

  54. Rev Says:

    For an outsider like me, who would love to go Linux full time, this article is a sobering insight into the world of Linux development.

    If the article wasn’t enough reason for concern, the comments surely are. After only a few comments, things devolve quickly into he said/he said accuse-fest, without any of them actually addressing the main concerns of the article.

    It doesn’t look like there’s going to be a workable level of cooperation anytime soon. At least now I’ll know the reason for the glacial pace of improvements in Linux/Ubuntu.

    I’m not sure if any of the developers care about this, but the community may also want to start worrying about its image, as perceived by the (prospective) users of Linux.

    If I had to capture the tone of the comments in one word, it would be ‘Childish’.

    Who wants to dedicate himself to a computing environment run by squabbling children?

  55. TP Says:

    I haven’t been doing much stuff for gnome for 10 years at least, but these discussions sounds pretty familiar..

    It’s not a big surprise that working with other people all around the world is not easy. But I have a solution for the problem: If you have trouble getting your code accepted by gnome or kde projects, best thing to do is to release it independently of gnome/kde. That’s how all code is at the beginning — noone likes it. It has too many dependencies, it breaks existing rules of how the software works, and it implements some strange requirements noone has ever heard of. You need to work hard to get your ideas accepted by other people. Best way to do that is to make it work, and then release it to the world. If it seems useful, it’ll get integrated one way or another. The end result might not use your code, but your ideas were accepted anyway.

    That said, there are plenty of projects available that were just abandoned by the original developers. But they’re still important. Such module is absolutely needed, but noone is interested in developing it further. That’s where developers are needed. Developers are NOT needed in the core gnome or kde efforts trying to change the course of the projects.

    It’s quite often that once your custom project becomes popular, the original developer gets tired of it. If they invested too much time for the project and cannot let it go, it’ll become a nightmare. The new people who joined the project didn’t see the same issues as original developer and make completely crazy decisions and try to get them accepted. But they often make too many shortcuts. They didn’t follow the process that you release to the world and get your ideas accepted first before it is integrated. They want it integrated immediately. You need to work years before people will see what you’ve built is actually useful. And even then half the people will just declare it failure .. because it’s not solving the exact problem they’re having, since everyone have different ideas of what a good software should look like.

    People in power in gnome and kde projects didn’t get there just because they wanted to make best desktop environment. Their projects just happened to become popular. Thousands of projects just failed, and a few survived. But popularity has big downside. Everyone wants to change those projects to implement some crazy requirements. It’ll destroy those projects eventually, and good maintainers will see the destruction from far away and this is why your submissions are rejected. It just doesn’t have the acceptance required.

    Creating the software is not the difficult part. Anyone who thinks so have never done any software. Real problem is keeping it consistent when everyone wants to change it to different direction. Uncontrolled changes will destroy the project. Are you in side of destruction or in side of creating something wonderful?

    Worst thing you can do is try to pressure the maintainers to accept your code. The maintainers are still people and they’ll break eventually, especially in the most popular projects. Then the project has uncertain future, if the maintainers just leave. The rules they enforce are there for a reason. They keep the project consistent with the original vision. If you want your own rules accepted, just follow the process of making it work first, release it to the world, and once it gets accepted it’ll be integrated to popular projects.

    Getting changes to popular projects is very difficult. Gnome and kde are probably worst case. To exactly follow the process explained above, you’d need to release the whole gnome environment and get your modifications accepted by all users. Gnome and Kde developers understand this is impossible for most free software developers living in their basement, so the rules are relaxed a little. But there is always a danger in relaxing the ruless

  56. Mark Shuttleworth » Blog Archive » All the other guys are not wrong Says:

    [...] Neary, who to his credit has been trying to understand how matters reached this point, blogged his conclusions to date. They warrant a [...]

  57. Steve Says:

    @TP

    You nailed it. Now how should this be fixed?

    I am an industrial designer using Linux full time. What I’ve noticed during the years is none of the desktops or distro’s has gotten it right. It feels the Linux desktop is missing purpose and sendse of direction. Projects are started out of temporary, impulsive needs , not from some all-encompassing vision. Maybe the processes idee must be changed. Maybe we should start over. Maybe it will never ever work. Or maybe the free desktop needs a Hero..?

  58. SrART Says:

    Convince rasterman from enlightenment to take charge of fd.org. E17 uses at least a subset and at least his desktop environment has a leader. Those of you that dislike what Gnome and KDE have turned into, check out enlightenment 17.

  59. TP Says:

    @steve

    It doesn’t need to be fixed. People just need to learn to choose those projects that are not yet popular. It takes large amount of effort to make them popular. Better start immediately.

    Popular projects are supposed to be used and maintained, not changed.

    If you want to change the world, pick a project that is not yet popular and you can do larger changes to it. It’ll take few years to make it popular, assuming your ideas are good. Just need to pick carefully so that it can be eventually integrated to existing systems. A lib that reimplements gui for linux is not going to fly very far now that we have existing libs available.

  60. jospoortvliet Says:

    TP & Steve: you don’t get it – it is VERY easy to change things, at least in KDE. Maybe not in GNOME but if you want to come up with an alternative shell in KDE, go ahead – you’ll get ppl to help you if you provide a compelling vision, even. Seriously, if you are willing to do the work it is easy. Tell aseigo you want to build another Shell, he’ll get you an account and all the help and advice you need. IF you want to do the work on it he nor anyone will do anything else other than support you.

    The barriers you describe don’t exist. In GNOME it seems a bit harder as there is more control but if you convince the companies involved you can get it done too – and without that, just talk to some developers to get an account and do it on GNOME infrastructure. If it works it has a chance of getting accepted.

    Wasting your time re-implementing everything AGAIN in some small project – don’t. Working in GNOME and KDE is possible. They are different but both are FOSS communities where anyone can change anything – simply as long as they aren’t lazy, willing to work with others, and SHOW THE DARN CODE.

    Unpopular products are usually unpopular because they’re not good enough (yes there are exceptions).

  61. jospoortvliet Says:

    @dave

    what I find a bit disappointing is that you say “there is distrust between GNOME and KDE” but you don’t acknowledge that there IS a problem with GNOME as a whole being uncooperative. There are exceptions but I’ve seen many times (and there are plenty of examples mentioned in these discussion) where this was pretty clear. See Mark’s example of Ted and Aurelien’s work. Nobody is perfect, admit there are issues if you want to fix anything. Just blaming Mark for not understanding it – well, his response was spot-on: “Gnome is not self-consistent, or deterministic, so it can often come to two quite contradictory conclusions at the same time, and Mr Shuttleworth didn’t understand the one we’d now like to promote.”

    Canonical made mistakes, probably KDE did too – but GNOME surely has an issue and cooperation won’t get any better until you admit that and try to do something about it.

  62. mat Says:

    I don’t understand why all this fuss now.
    The situation between gnome and kde is like that from ages (with gtk apps becoming gnome ones and gnome deps moving inside this and that project, kde devs postponing/deleting decibel/telepathy work just to not work “for the other part”).
    Better to use fact than words, give us a superb Gnome 3 and Mark will regret “that” decision.
    Now Gnome 3 should be coming (Or this is the preparation for a further delay announce?) and get back some of the tech lead Kde actually has.

  63. David Smith Says:

    The need for AppIndicatiors / Unity and the reason why the traditional Gnome-Shell is broken.
    A lot of the Gnome developers seem to be stuck on the reasons why the Desktop notification system needs to be evolved. Part of the reason may be that they’re on PCs or laptops with big screens where throwing dozens of notifications to the user at the same priority level at the same time is not a problem, and part of the reason may be that they might not live the same kind of lifestyles that other people do.

    The reality is that a user cannot multitask as well or as fast as the computer can. As computers get faster and the users themselves connected better to other users wherever they go through the wireless networks, this becomes a much larger problem.
    The user can’t read an e-mail, read a tweet, answer an instant message, answer a VOIP call, authorize the installation of a security update, and do it all at the exact same instant the same way a computer can. In a traditional desktop, the applications will throw all those notifications to the user at the same time and force the user to sort it out for themselves what they think is important. This is a sloppy approach to notifications because it is fundamentally obvious that VOIP calls need to be handled immediately while e-mails can be read hours later. It is also fundamentally obvious that e-mails from certain people should have a higher notification priority than e-mails from strangers. For example, if you are very busy, then you might only want to be notified about incoming e-mail if the e-mail is from a family member. Otherwise, the e-mails can wait until the next coffee break.
    To take it a step further in another use case, perhaps you’re in a very important business meeting. You want to mute the sound on all your notifications in all your applications except for your VOIP application. The reason being is that your wife or another family member is in the hospital and the doctor is going to give you a call. But even within your VOIP application you can’t just leave it unmuted because you might, by random chance, get a call from your Aunt Betha who wants to brag about what a great vacation she’s having in Hawaii. So you need to be able to identify certain types of notifications from certain people during certain times. Sure, these are things that application programmers can do within their applications, which is nice, but it’s going to be a sloppy solution no matter how you slice it because applications just don’t know what’s going on around them. Even if the applications supported this kind of functionality, you’d have to manually switch to each and every application that could ever give you a notification and configure it to mute it. O
    ne could argue that you could simply close down these applications and your notification problems would just go away.. Unfortunately, that’s not a good solution because when Joe starts rambling on about the same thing over and over again, you want to have something to do so that you’re not bored to tears during the meeting.
    The better solution is to have a “visualization” that handles all your notifications. Then the user can tell the “visualization” to react audibly on VOIP calls from the doctor, and only visually on everything else. The traditional Gnome-Shell cannot do this. It simply lets applications do whatever they want with notifications . You can make all the notifications less annoying, but then you risk missing your most important notifications. You can make all the notifications more annoying so that you don’t miss them, but then you get flooded with too much stuff of low importance.
    Traditionally, applications were coded to do their own notifications to the user. Unfortunately as devices become faster and people more connected, the sloppiness of this approach becomes more and more evident as the user has to spend more and more of his/her time struggling to manually sort out which notifications are important in real-time as they arrive for the multitude of applications that are running.
    The solution to all of this is along the lines of AppIndicators and Unity. It allows applications to present their notifications to the “visualization” and then “visualization” will then determine whether it’s an important notification to pass to the user in the current context. As I’ve read, some application developers are concerned that their notifications from their applications may never be presented to the user. That is true, and in some cases, it’s actually better that way because if the user is incredibly busy, the “visualization” can create a “digest” of all the things that are of lesser importance and the user can browse through those if they get a moment of free time.
    Sure, there is still a lot of work that needs to be done but I think the “problem” with indicators on a traditional desktop is already well defined. In fact, there are already “solutions” out there, just take a look at what Google is doing with Android and HP is doing with WebOS.
    I personally feel that Canonical’s Unity is a step in the right direction and it was absolutely necessary given the circumstances and stubbornness within Gnome to address and understand the problems of notifications. The traditional Gnome-Shell just was not designed to do the things that the future desktop needs for mobile devices.
    In the heavily connected world of the future with faster and faster computers, it becomes more apparent that there needs to be a notification manager that presents only the notifications that the user wants in a given context without having to manually reconfigure each and every application dozens of times throughout the day.
    The separation of the applications and the presentation of the application’s notifications to the user is going to be the Desktop of the future. Everybody will move to it eventually.. The last thing we need is several notification engines running at the same time because that defeats the entire purpose. Canonical, KDE and Gnome need to work together on these notifications or it’s going to be a mess… I’d hate to see Gnome-Shell die, but I’m thinking it’s a possibility since they do seem to behind KDE and Unity when it comes to handling these notifications.

  64. Lazy Reading – DragonFly BSD Digest Says:

    [...] hard to follow the conflicting and changing plans on Linux device support?   There’s larger messes.  (via this and that)  I would suggest that when an organization says “There’s a [...]

  65. Randy Helzerman Says:

    This whole debate seems like arguing over exactly the right shade of paint for the titanic’s ballroom.

    Sales of desktops are plunging, netbooks are dead, and the next 2 billion people to get onto the internet are going to do so through their phones.

    Who cares about desktop guis?? I mean who really cares???? All this effort arguing over a notification system which–to within a rounding error–nobody will ever use.

    Free Software is facing an existential crisis right now, with its use being discouraged or prohibited on mobile ap stores, and this is what all you smart people are worried about???

  66. William Stone III Says:

    All y’all are still missing the point:

    You’re about to release advanced, nobly-developed free software …

    … THAT NO ONE CAN USE.

    GNOME Shell is UNUSABLE.

    Unity Desktop is UNUSABLE.

    Bicker all you like, but by releasing these unusable pieces of software, you are going to yank the rug out from under yourselves.

    Ubuntu will not be used. GNOME Shell will not be used. People will go to KDE, Xfce, or a distro that doesn’t use Unity or GNOME Shell.

    Ubuntu’s userbase will plummet — or at the very least migrate to Kubuntu or Xubuntu.

    The adoption of Linux on the desktop will stagnate. Adoption of Ubuntu will drop. Adoption of Ubuntu in the data center will suffer a hit.

    Bicker like children all you like — but at the end of the day, no one can use what you’re trying to sell. Since this is Linux rather than Windows, they have a choice: they will choose not to use them.

    Bottom line: bicker and lose.

  67. Devadittya Says:

    2009, and 2010 were brilliant years for Linux. I have a feeling that we have some not-so-great years ahead.
    Gnome and Canonical are both planning changes that are just way too radical, and much of it reeks of broken communications. I won’t get into how good/bad unity or gnome shell are, but the entire fact that the end-user is going to get caught into this entire mess is ridiculous.
    What is needed in popular desktop Linux at the moment is consolidation, not further fragmenting.
    I can’t even imagine whats going to happen a few years down the line with so many options – KDE, Gnome, Gnome without Shell, X, Wayland…
    I am on Arch, and I love it. However, a vast majority of users – especially enterprises – do not want so many choices!
    There IS a need of leadership. The ENTIRE open source community needs some leadership. Someone needs to bitchslap Gnome, KDE, Canonical, Fedora and everyone else into their senses.

  68. William Stone III Says:

    @nicu: Thank you for reminding me of Xfce.

    I’d previously tried Xubuntu and found that it had some issues with PulseAudio. One of the things Ubuntu had done was finally implemented a way to get a working system-wide equalizer, including a GUI for setting it.

    I installed Xubuntu Desktop this morning and checked: the PulseAudio issues have been resolved in Xfce 4.8. My system-wide EQ works perfectly.

    I have migrated and am now using Xfce full-time. I also checked in the Xubuntu IRC channel and got confirmation that Natty will NOT be using Unity.

    Bottom line: I’m using Xfce for the foreseeable future. I will advise users to switch to Xubuntu.

  69. Dirk Koopman Says:

    As William Stone said earlier, where is the usability? The nuts and bolts? The things non-gnome programmers might want to use?

    But I would go further than him.

    If anyone thinks that gnome is going to become a dominate desktop then they had better start addressing some of the serious weaknesses that all desktop systems have under linux. Especially when one compares gnome to the paid for “competition”.

    Those weaknesses in gnome include (but are not limited to):

    * No real consistency of UI interaction. If someone does not like or simply needs to do something else because the standard dialog is wanting, there is no overarching “look and feel” design document to say: “these are the rules”.

    The control panel was mentioned in the original post – and is a prime example of what I mean.

    * Selections in dialog boxes don’t “stick” (always). E.g File selection, the print dialog (which is going feature quite lot).

    Why do I sometimes have to start again from one of the “root” places everytime I want to select a file – yet other times it remembers the directory I was in?

    Why does the print setup dialog always default to “Any Printer for portable documents” even though I have declared a default printer which is named and has its own entry?

    And what is the point, exactly, of forcing a user to to reenter the fact I a) want a Canon printer b) 6×4 photo paper c) hunt for an orientation that might work d) select a resolution and e) quality. Try finding all those things and then, when one has achieved it, be disappointed with the result that once AND have to do it all again the next time for the next photo!

    * On one keyboard I use, I have function keys down the left hand side. I have thus discovered the frankly weird function key usage (as I miss the shift or tab key again) and also that there is no way to change them or switch them off.

    * What is the point of having “preferred applications” with only a couple or four applications (web browser, mail, MM player and terminal + accessibility) available?

    I want to control pdfs, editors, text readers, sound differently to video and so on. We have to accept what ever gnome chooses to give us and do everything else the hard way.

    * Printing is a complete mess. I understand it’s difficult (having written spoolers and printer drivers in my time) but nothing has really changed – other than the dialog which seems to have traveled backwards in the last couple of major releases.

    It’s not just in the choosing, it is in the actual printing as well. Forget photo printing on decent paper from the dialog box – use turboprint from the gimp as nothing else seems to work.

    But even firefox (one would have thought one of the main programs that users might want to print from) has rubbish formatting. It cuts off paragraphs at bottoms of pages, probably because it does not take into account the size of the headers and footers (that I can’t seem to switch off). It would not be so bad if the missing bits appeared on the next page, but the missing just stays er.. missing – try printing the IKEA “how to find us” page as an example (on A4 “portable documents mode”).

    Now you could say: that’s a firefox bug, and I would reply: no it isn’t because a decent printing environment would deal with headers and footers automatically, as well the fitting of stuff on the logical page for the program.

    And I could go on (and on).

    The issue is that it is these nuts and bolts that matter to people whom might consider switching to a linux desktop. They really don’t care about whether or how one uses D-Bus.

    In case you think I some KDE apologist, can I reassure you that while several of the things above are done better in KDE, that does not mean they are done well enough. And in any case the last KDE’s desktop looks lovely – but is largely incomprehensible (to me at least).

    So I still use gnome. But if something ever better pops up, I will use it like a shot.

  70. Jos Says:

    GNOME and Ubuntu are just another example of the main problem Linux is facing now: Arrogant developpers who think they know how to do it and don’t care about the opinion of others. When I read the attitude of Gnome about the buttons in the Window title bar, I knew for sure I’d never use it any more. Why the hell is it up to a few programmers to decide how the user want his buttons ?

    Too many captains, too many ships.

  71. Guillermo Amaral Says:

    I totally agree with Randy Helzerman, all this GUI talk is not important, and after 14+ years of listening to it I’m pretty fed up.

    That said, dudes and dudettes, OSS is suppose to be fun and profitable, not to mention a good excuse to drink with other like minded tinkerers/geeks/hackers.

    People really need to stop trying to make OSS some sort of utopia, we are all different and we all want different things. If we where common we would all be using Windows or Mac OS – we’re not.

    KDE and Gnome are different projects filled with totally different types of people. KDE and Gnome might have similar goals, but that doesn’t mean they have the same “interests at heart”.

    I know a few of you believe that popular projects should be kept, cuddles and kissed good night. But the reality is that people need to put on their big boy pants and grow a pair. We need to start innovating again, if you don’t like something in KDE or Gnome, FORK. If you think you can do better, start your own.

    We have the power to make OSS unique, *not* something similar to what is already out there.
    Like Captain Planet said, “The power is yours” :P

  72. Simon Says:

    Definitely in agreement with the “Difficult people” section. Both inside Gnome and outside it, there are far too many people who are busy pouring petrol on flames instead of doing anything productive.

  73. Jeff Waugh Says:

    David Smith: Funny, the GNOME Shell notification user experience was massively inspired by webOS. :-)

  74. Jerzy Bischoff Says:

    I don’t mind Gnome, but I don’t use Gnome or any Gnome apps (or Java apps, or more importantly, and what the writer here should key on, nor do I use OSX apps or Windows apps) and I definitely don’t think Gnome’s the be-all and end-all of free software let alone software period.

    Gnome can choose to work with Cannonical and KDE, or not, but I don’t see a constructive attitude in _this_ blog post.

    I really feel that the importance of Gnome versus “other FOSS” and the emotion here is out of whack. Gnome overtook KDE when KDE sat out with KDE4.0 birthing and growing pains, but KDE is coming back, likely stronger than ever. Unity too has its advantages, like it or not.

    Gnome isn’t entitled to free software hegemony, and anyone who cannot see that the proprietary software world remains dominant anyways is mistaken to say the least.

    Cooperation in Free Desktop is as critical as ODF. Drop your ego and help make it work.

  75. ReinoutS Says:

    @Rev
    Don’t mistake the people posting childish comments here for the people actually running any one project. They’re more often than not much too busy to waste their time on engaging in a discussion with people who, for example, think that accusing one project of choosing a different button order than another for the sole reason of being incompatible, will somehow bring us closer to a solution.

  76. barnabyh Says:

    No tracability on IRC? Whatever happened to logs?

  77. oiaohm Says:

    Simon and far too many people saying freedesktop is broken when its not as a reason not to be part.

    Lack of productive longterm is doing your own thing and not working well with each other.

    Freedesktop allows anyone to submit draft standards. Do they all have to live hell no. How is Freedesktop meant to help. Its meant to reduce reinventing the wheel and cause proper thinking about how you are designing things.

    Of course Freedesktop only works perfectly if everyone is involved.

    It skill remains partly working but steamrolling groups. If groups don’t maintain involvement.

    The complete Gnome vs KDE mess in how todo notifications really should be battled out in freedesktop. Not Gnome sit and do nothing. Then wonder why other now come and rip into them for not following common standards.

    If Gnome had submitted an competing draft standard Canonical would not had grounds to attack them. Neither would have KDE personal. Yes Gnome left themselves wide open here.

    Basically Gnome people get this you have brought this on yourself. This is the price of not working with freedesktop.

    Freedesktop was created to stop battles like this before they start. By containing them to draft standard implementation arguments that would hopefully produce something productive in the end.

    Normally the two competing draft standards ripped up and the best from the competing standards made into a new one. So a progressive result.

    If Freedesktop was a standard body not a draft standard body it really would not be able to have multi standards covering the same area and destroy the ones that long term no longer suit.

    Gnome is failing to use Freedesktop properly. Its not Freedesktop that has failed Gnome. Its Gnome that has failed Freedesktop. The failed party is Gnome project itself.

    Freedesktop is not about to force Gnome to implement any standard that does not work ever. There is a limit of course. Nothing stops others demanding Freedesktop compatibility. Submitting draft standard magically would have given Gnome compatibility.

    Being prepared to create a draft standard is a sign that the issue you are complaining about is not just a complaint out of laziness at implementation but a real issue that needs to be resolved.

    This US vs THEM problem existed before Freedesktop. Freedesktop is the designed system to deal with it if used correctly.

    Issue why Freedesktop does not block competing draft standards and don’t form boards to create standards.

    Is that both a parties particularly smaller ones can claim the rigging against them what can be true so their ideas never got to see the light of day.

    Freedesktop is very well design. There were a lot of complex debates that made it not a standard body.

  78. oiaohm Says:

    I will mention one other very important thing.

    KNotificationItem is the 0.1 version. Gnome developers only started commenting.

    When it become StatusNotifier what is too late. If there were any issues with design they should have been raised and if critical a competing standard placed.

    “Dan Winship & Mathias Clasen, and Citrix developer Giles Atkinson, reviewed the spec” Are all incompetent here. The spec they should have been reviewing was the KNotificationItem. Not waited for a spec to go into final state.

    All specs sumbited to freedesktop are meant to be desktop neutral and planed for all desktops to use.

    Then they complain when they got told hey you are to late to change things now. April 2009-Oct 2009 was over a 6 months window for comments they never came.

    Now how is its freedesktops problem if you miss you window for raising issues.

    You let it sit 6 months without comments by freedesktop rules you approved the design by default. Yes default vote in freedeskop is for.

    No matter how you argue Gnome screwed up here. Now are trying to shift blame on to other parties. Sorry this is not on.

  79. oiaohm Says:

    Also Aurélien Gâteau and Ted Gould had both commented in the time the standard was KNotificationItem, So they as it should be were part of the board to finalize StatusNotifier spec.

    Lack of commenting issue lost you a right to seat in the finalizing process. Yes lack of action is punished hard in freedesktop.

  80. oiaohm Says:

    Everyone Freedesktop in this case worked perfectly. Exactly how its designed to function. Every required step was done. Freedesktop has done nothing wrong. Blame for not being involved enough lands squarely on Gnome and it Developers.

    Yes the response that the spec is final and unchangeable is justified.

  81. asdf49 Says:

    The problem I see here is with the attitudes and the developers’s egos. This is something that has been stopped Linux from getting somewhere.

    Because the Linux developers can’t agree on something and instead of resolving problems in a mature way they prefer to start from scratch just to show how great they are and then try to grow their self-esteem or their egos.

    I believe Aaron is pointing out that problem here.

  82. Gnome :O « Syvo3 Says:

    [...] da qui: per forza poi ci si lamenta di come Gnome tira avanti, non c’è nessuno che guida lo [...]

  83. eGrove System Says:

    There are some interrupted options too available in this GNOME.
    request to avoid all those.

  84. Juan Due Says:

    Right now I think open source desktop is probably the laughing stock for M$ or Apple. We are in 2011 and while great work has been done on the desktop side, a basic thing like a desktop notification system still sparks a lot of debate. I think both Gnome and KDE have to remember that they are basically competing (more or less) for ~1% of the desktop market.

  85. Dave Neary on the Gnome/KDE/Canonical Relationship Says:

    [...] Neary has posted a lengthy analysis on the relationship between Gnome and other entities like KDE and [...]

  86. David Smith Says:

    @Juan Due

    You’re right in that it’s very difficult to dethrone something that has an overwhelming market share. Sometimes the best solution is to just not let that happen in the first place..

    In my opinion, it is the cell phones, netbooks, and tablet markets that need to be focused on more than anything right now. Already Linux dominates all the market share on super computers and mainframes and is well on it’s way to dominating the ultra portables as well.

    WebOS and Android are both Linux based with no decent Microsoft competition in sight.

    The big question in the next couple years, isn’t whether mobile devices are going to be using Linux (which they will).

    Rather it’s if Gnome and KDE can ever be scaled down into the multi-touch portable devices or will we be stuck with HP’s and Google’s solutions which have significant amounts of proprietary software built on top of Linux which can make it non-trivial to port existing open source projects over to those platforms.

    HP and Google are both banking on the idea that a lot of open source apps will be time consuming and difficult to port over to their platforms, and so their App Stores where they can charge $15+ for a simple document editor will be a huge success.

  87. Ubuntu Linux and GNOME: The Disputes continue | ZDNet Says:

    [...] work on the Ubuntu and GNOME technical dispute by Neary revealed, that Ayanta, under the name, StatusNotifier spec, had been worked on by KDE developers and that [...]

  88. Дайджест №12: По секрету всему свету | ByteFrames Says:

    [...] дистрибутиве используется именно Gnome, а не KDE(вроде вот таких вот бурлений). Марк решил высказаться по этом [...]

  89. IS11S08 a IS11S10: pinceladas de 3 semanas con mucho software libre - No sólo software Says:

    [...] El resumen de lo ocurrido según Dave Neary, miembro de la GNOME Foundation. [...]

  90. Dieter Says:

    Root cause: people who like to spend their free time hacking code are generally not the most socially handy people. Ergo, not great team players.

    Provocative, but true?

  91. cycle42 Says:

    I was glad to see xfce mentioned multiple times. I’ve shown xfce and lxde desktops to totally clueless computer users, and they liked them very much because of simplicity.
    Anyone can “just use the computer” with these desktops without an instruction manual.
    “Microsoft Disease” = Adding more and more features until a thing becomes useless.

  92. Jeffrey Bolden Says:

    There is a certain irony here in oiaohm’s comments (51,79,80) and the broader problem that I think might be illustrative. Oiaohm’s theory is that because FreeDesktop.org has a “standard” it is the standard. I’d argue that any “standard” rejected by Gnome isn’t a standard. To pick an example from the early 90’s and Linux: if Ubuntu were to reject the Filesystem Hierarchy Standard and bring back /export for NFS and /export/local for user software than the FHS wouldn’t be a standard anymore, thats part of the power of 60% market share. In the same way that if I write a piece of paper called a standard for fashion that Vogue, Elle and InStyle reject it wouldn’t be a standard.

    A freedesktop.org standard Gnome has rejected isn’t a standard, even if freedesktop.org wants to claim it is. That’s part of the power of being the dominant desktop. What does a freedesktop standard mean, if everyone but KDE rejects it, how is that different than a KDE standard? And that’s regardless of what 6 month rule exists.

    And that’s a useful analogy to the Canonical Gnome situation. That power over standards comes mainly from Canonical being with Gnome. So in much the same way that if Canonical has rejected the Gnome 3 spec, it ain’t going in Ubuntu and thus it isn’t a standard. There are only a few ways this situation is going to end:

    a) Gnome is going to substantially revise their spec prior to the Gnome 3 release, which seems like its doubtful.

    b) Canonical is going to fork Gnome in a major way and we are going to have two very different Gnome’s running around getting more and more dissimilar.

    c) Canonical is going to drop Gnome as their default desktop.

    The fact that Mark Shuttleworth has gotten involved is a major shot across the bow to Gnome. I can’t believe they can’t hear it. Your number one customer has rejected your direction, was openly talking about forking and is now making noises like they are getting ready to fire you as their desktop vendor. That’s a big deal, its a huge deal. And I am one of the people who doesn’t think that Canonical could off a fork.

    Or at least it is a huge deal right now. It seems to me that Gnome has always wanted to be the standard. Since the demise of United Linux, systems like Progeny Linux and User Linux choose Gnome. The moment Canonical walks, and one of the other desktops will be a good fit for Unity, Gnome spends years dealing with rapidly falling market-share. You can assume that Mark’s fork efforts fail and he decides come back hat in hand but that’s a hell of a gamble.

    IMHO Gnome views itself is the standard though Linux has a wide range of systems KDE, XFCE, LXDE,,,, with KDE being the biggest player. Gnome has the support of Canonical, Redhat and is supported by most other major players like Suse… This is a big change from the 90s through the days of United Linux when KDE was clearly the leading desktop. Canonical is bigger than United Linux, Mandrake and Suse were put together.

    Mark Shuttleworth can de-facto veto a Gnome standard the same way that Gnome can de-facto veto a freedesktop standard even though neither can do it de-jour.

  93. S04E02 – Stranger in a Strange Land | Ubuntu Podcast from the UK LoCo team Says:

    [...] (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in [...]

  94. S04E02 – Stranger in a Strange Land – OGG HIGH | Ubuntu Podcast from the UK LoCo team Says:

    [...] (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in [...]

  95. S04E02 – Stranger in a Strange Land – OGG LOW | Ubuntu Podcast from the UK LoCo team Says:

    [...] (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in [...]

  96. S04E02 – Stranger in a Strange Land – MP3 HIGH | Ubuntu Podcast from the UK LoCo team Says:

    [...] (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in [...]

  97. S04E02 – Stranger in a Strange Land – MP3 LOW | Ubuntu Podcast from the UK LoCo team Says:

    [...] (snappy name needed, apply within!) Whereupon the past is woken up and given, a kick in [...]

  98. David Smith Says:

    I will say is that I’m really looking forward to those tablets running Ubuntu Unity that will be coming out next month. I’ve seen a lot of videos, and those things are darn sexy.

    If Gnome can come up with something that works on a tablet better than Unity, then I’ll definitely install that. If not, it just doesn’t make sense to me why Gnome would take the actions that they did.

    Either way, sooner or later, time will tell.

  99. Moving the needle in GNOME | Be the signal Says:

    [...] and then, and quite a bit over the last week, someone will offer up the prize furphy that “GNOME does not have technical leadership“. This is poppycock, pure and [...]

  100. oiaohm Says:

    Jeffrey Bolden No you missed what I said.

    What gnome does is the problem.
    “I’d argue that any “standard” rejected by Gnome isn’t a standard.” This basically says Gnome is above all creation of standards will not take part in creating standards instead only take on standards that suit what we are doing. How can I say pure stupidity if you think freedesktop supporters have to accept this point of view.

    FHS standard lets say Ubuntu did decide not to follow it. Would this change the fact that the standard exists no. Would this change the fact lot of programs are developed expecting that standard. No it would not. Market share does not give you the right not to attempt to play nice with others and to be balled out over it.

    Rejection what Gnome is doing what I call disregard/ignore.

    New standard hits freedesktop from someone other than gnome it gets disregard/ignored and hope it goes away.

    When it does not go away they review it ask for a stack of changes when it cannot be meet say the standard is not up to snuff so we don’t have to follow it anyhow. Main reason is by the time gnome spoke up code is already being rolled out so at that point changes are limited.

    Then propose nothing as a counter. So basically disregard/ignore and pretend freedesktop does not exist and hope it goes away.

    Now go back to first step in the process wash rinse and repeat so with Gnome making zero progress.

    I can find standard after standard in freedesktop in recent years that have come from KDE and Other smaller WM. Yet Gnome does not have any. So why should Gnome have any right to change any? Gnomes actions say you are not interested.

    Complete result of this process if we had a rule that all parties had to approve would be no standard progress at all. This would totally be an invalid outcome to allow. This is why freedesktop does not have this rule. And remember when freedesktop started Linux was a minority. Unix and BSD were majorities.

    Like Gnome does not say normally clearly why it rejected. You don’t see a counter proposal either.

    Freedesktop by its rules any standard you hate you have the right to place an counter standard. Now if there are 2 standard in the 1 area and you are following 1 you are still following freedesktop.

    At-least this way people trying to make common standards have something to get an idea what you want. Basically you keep on leaving standard process in the dark. Are we not meant to presume that Gnome is simply a non interested party like the old Unix guys were.

    If you just want to play the disregard/ignore expect freedesktop to treat you badly. At the moment you are expecting to be treated well.

    Freedesktop is simply not doing anything wrong. Gnome interactions with it simply sux need to change. Its been here for over 10 years and its not going away no matter how much Gnome people wish.

    Yes it does mean documenting your interface internals of gnome for public release.

  101. David Smith Says:

    I’d suggest not blurring the lines between specifications on FreeDesktop and standards.

    A lot of the proprietary formats that are used today are standards but they don’t have open specifications that anybody could easily pick up and write their own implementation that would be compatible.

    It’s important to encourage writing specifications on FreeDestkop in the hopes of being more open and free instead of taking the Microsoft route and implementing it yourself, the way you see fit, without following any public spec.

    So long as Gnome has the market share that it does, just as with Microsoft, it’s true that any spec rejected by Gnome automatically makes that spec not a standard.

    I’ll agree with the guy from FreeDesktop who said that people can write specs all they want, but FreeDesktop has no power to create standards.. That power is in the hands of Gnome, KDE, Canonical, etc.

  102. Zeitgeist Moving Forward | sistem bazat pe resurse Says:

    [...] browser não suporta iframes. De asemenea poti citi acest blog post: http://blogs.gnome.org/bolsh/2011/03/11/lessons-learned/ Tags: sistem bazat pe resurse, sistemul economic, solutie criza, zeitgeist in romana, Zeitgeist [...]

  103. oiaohm Says:

    Besides MS rejecting ODF did not magically make it a non standard. Even that they had majority market share.

    The Gnome arguments are not logical when it comes to standards.

  104. Donde esta la innovación en el software libre? | el mundo según Linux Says:

    [...] unos días Dave Neary hablaba de esto mismo en su blog, refiriéndose al problema que actualmente existe entre Canonical y el proyecto Gnome, el cual ha [...]

  105. oiaohm Says:

    David Smith
    “I’ll agree with the guy from FreeDesktop who said that people can write specs all they want, but FreeDesktop has no power to create standards.. That power is in the hands of Gnome, KDE, Canonical, etc.”

    Problem is the power is in everyone hands. Not 1 party has a veto right.

    Read his comments carefully David Smith not once has he ever said Gnome has the power to veto. It is in everyone’s hands if a standard is strong or not because standards need implementations.

    Standards require implementations. Without a implementation its not a standard it is only a specification.

    One of the current defacto standards is mostly between music players. It has no requirement to get Gnome, KDE or Canonical to become defacto. Support from KDE Gnome and others to get application developers to support it would of course be helpful

    So Gnome reject it would make zero different at all.

    Others is that Gnome might change their mind when enough others have taken it on-board. Ie peer pressure.

    Rejection by gnome alone means nothing. Lets say something was rejected by everyone and there was no current implementations then its dead.

    Its not a all or nothing debate.

    Of course I am not saying that Canonical has not abused what freedesktop is and asked for stuff not written on there.

    One point I want to make majorally clear.

    I have had the argument that since people who have worked for gnome have put up standards to freedesktop gnome is working with freedesktop.

    This is wrong. Working with freedesktop requires support for standards put forwards. Preferable front and center. So that a person developing an application reading a specification goes this specification is supported by Gnome/KDE/Who ever. So its not going to disappear on us. So we can trust-able develop on it.

    Basically how does a person tell the difference between a individuals work and something gnome itself truly supports and is going to keep on following unless its declared.

    This is also required so standard progress under the freedesktop system. It is one of the current major issues why freedesktop is not functional as much as it should be.

    Interactions with freedesktop are broken.

    Those Interactions being broken lead to implementation drifting away from specifications as well.

    Excuses not to Interact correctly only make matters worse.

  106. Crispin Stichart Says:

    So, the main problem is that Gnome and KDE have no central leadership?

    I have a solution. A really exciting one, if I do say so myself: a bicameral legislature as well as an executive branch!

    Model it off the USA’s government. Each project would be like a state, and have a proportional number of representatives (based on lines of code, perhaps) for the lower house, but only one or two for the upper house. Either house can suggest legislation (project-wide design changes), but it has to be passed by both houses to become law.

    The legislature could also enter into “treaties” (cross-desktop standards) with other desktops such as KDE.

    The president would be elected by the congress, and serve as the figurehead and driving force behind Gnome. He would also moderate arguments between the congress members, and help them come to compromises.

    Comments, anyone?

  107. David Smith Says:

    ODF is a specification, it is not a standard…

    Teachers in universities across the USA require that all documents be submitted in Microsoft Office formats, especially because it allows compatibility with earlier versions of Microsoft Office..

    Same thing in the business world, if you’re sending documents around, it’s got to be in Microsoft Office format or people will be complaining that they can’t open it. People who do not have the authority to install additional software on their work PCs other than what their employer provides them with (old versions of MS Office)..

    What I consider a standard, is what the majority of people are using. ie: Market share = standard. You can have open standards and closed standards, but anything that isn’t used by the majority of people is not a standard.

  108. David Smith Says:

    My point being, you can make specifications up all day long, and even go ahead and implement them all you want.. But if Gnome doesn’t adopt the specifications, and Gnome can maintain the market share, the implementations of those specifications aren’t going to ever become a standard.

    This is an important thing to understand, because it is how companies such as Microsoft work. They shoot for market share first, and by doing that, they guarantee everything that they do becomes a standard by default because everybody is using it.

    Microsoft doesn’t even need to publish a specification to create a standard. Although published specifications are normally crucial to creating healthy standards.

  109. David Smith Says:

    @oiaohm

    I read through everything in there twice and it seems like the only thing I see you have a problem with is the fact that Gnome has the power to reject something
    and potentially cause it to end up in the back of the closet somewhere next to other things that aren’t widely used

    That kind of power is granted through desktop market share, it has nothing to do with freedesktop.org or any of the specifications on it.

    Users will always use whatever they think is best, and in doing so, gives whatever they’re supporting a lot of power in regards to rejecting or accepting any specifications.

    So yes, Gnome does have that power, and has every right to use that power as it’s granted to them by their own users.

    I really hate to see open specifications end up in the back of the closet just like everybody else, but if Gnome-Shell holds on to their user base during these times then it will have meant that those users themselves have already made the decision against the open specification in favor of the Gnome-Shell way of doing things.

    Honestly, I’d like to see Gnome-Shell fail for not adopting the spec.. But the reality is that might not ever happen..

    If you want to see Gnome-Shell lose their influential power, then it’s easy… Support Unity and KDE for using the specifications that you want to see being used.. If you do so, then Unity / KDE will then have all the power to make real standards and not just specifications that could end up in the back of the closet.

  110. oiaohm Says:

    ODF is a specification, it is not a standard…
    Officially legally it is a standard. You completely deleted my comment point this out.

    Teachers in universities across the USA require that all documents be submitted in Microsoft Office formats, especially because it allows compatibility with earlier versions of Microsoft Office..

    My train line example in my past post was that the USA is not the world. Sections of the world require all government documents submitted in ODF. ODF is a standard they accept. Send a .doc or .docx your document will not even make it. So just because the USA does something is small fry. If you are working international you have to consider the international requirements. Those requirements include ODF.

    USA education system has a big problem of not teaching students the difference between standards and adopted standards.

    Microsoft to Countries is the same as Gnome is to Distributions. If Distributions decided as a group that a particular features must be implemented. Gnome will be pinned because they are holding the market share.

    Distributions have just as much right to flex there mussels as Gnome has.

    Also applications also have the right to form up standard without Gnomes approval. So forcing them on gnome from under it.

    Basically the idea of Gnome having veto is false. There are two paths to shatter that veto. That again is using market share. Simple problem the market share is not only Gnomes. Gnome market share and rights is shared with Distributions and Applications under it.

    The grounds that you say you have veto are false. There are other parties above and bellow that can void that. Same way ODF has been forced on Microsoft.

    Now path of Microsoft or path of make freedesktop work. Path of freedesktop work will be far less painful longterm. Because battles like what just happened could become more and more common.

    Only way to prevent yourself from being dug in battles is to make sure standards suit you.

  111. David Smith Says:

    The grounds that you say you have veto are false. There are other parties above and bellow that can void that. Same way ODF has been forced on Microsoft.

    Microsoft dropped support for ODF in Office 2011 so I don’t see how they were forced to do anything, especially considering how bad their ODF support has always been. That’s off topic anyway.

    USA education system has a big problem of not teaching students the difference between standards and adopted standards.
    “Software standards” are a part of the software’s specification to enable interoperability with other software.

    It doesn’t make the spec a standard, in that it might not ever be adopted by the majority of users. So calling these kinds of specs a standard is a misnomer until they do get adopted by the majority of users. Until then, they’re just specs.

  112. 451 CAOS Theory » 451 CAOS Links 2011.03.22 Says:

    [...] already read the numerous posts written on the subject in the past week. If not Dave Neary’s Lessons Learned is a good place to start, while Mark Shuttelworth’s response is also worth a read, as is his [...]

  113. oiaohm Says:

    David Smith. Not dropped 2011. Not included because would have been a laugh stock item. Default word processor program in OS X had better support than MS Office 2011 did. Default on OS X was 1.2 ODF prerelease supporting. MS Office 2010 on Windows can out do there default include wordpad on windows 7 for odf support.

    Yes 2011 was only for OS X.

    Again cannot read. “Software standards” are a part of the software’s specification to enable interoperability with other software.” Where is the words majority of users.

    Standard software or otherwise does not have a requirement to be majority of users to be a standard there is another word required to have that meaning.

    De facto Standard has the requirement you are talking about to have majority of users. Shows you have been through a USA school that does not teach the difference.

    De jure standards are standards forced on companies by law. ODF is a De jure standard/De jure software standard in particular countries.

    De jure and De facto are the two types of heavily adopted standards standards.

    Basically please learn to read meaning completely and not add your own words to them so extending their meaning to what they don’t cover.

    The wording is wrong as well.

    http://en.wikipedia.org/wiki/Software_standard
    “A software standard is a standard, protocol, or other common format of a document, file, or data transfer accepted and used by one or more software developers while working on one or more than one software programs. Software standards enable interoperability between different programs created by different developers.”

    Yes horrid but true. Standard Software is valid even if only 1 program uses it. Since a software standard could have made with the belief that interoperability will come in future.

    Really would like to know where you dug up such a crappy define.

  114. David Smith Says:

    De jure standards are standards forced on companies by law. ODF is a De jure standard/De jure software standard in particular countries.

    I’ve already got an idea for some coding infraction tickets that FreeDesktop could start sending out to Gnome devs. They’re little postcards with a quote from the spec and an angry tux background.

  115. oiaohm Says:

    I’ve already got an idea for some coding infraction tickets that FreeDesktop could start sending out to Gnome devs. They’re little postcards with a quote from the spec and an angry tux background.

    Freedesktop deals in defacto draft standards and draft standards. Not De jure Standards.

    Freedesktop job is not enforcement. But this does not stop Freedesktop being a place of agreement to those who do enforcement. Freedesktop standards could have test suites attached. Something that is not forbin by the way.

    Then developers can used that test suite to confirm implementation and reviewers can use that test suite to find non conformance.

    Freedesktop itself does not enforcement has no need to. Its upto the parties using Freedesktop draft standards to police themselves.

    Yes if everyone using a draft standard want to rip each other to bits they are perfectly free to go ahead. Freedesktop job does not include being a bouncer. Maybe if it gets savage enough the importance of test suites to prove who has better conformance will come out of it.

    Items like Freedesktop works the best when there is conflict. Because parties end up having to depend on Freedesktop to protect their own tail.

  116. openSUSE Weekly News, Issue 168 is out! | Gnu Architecture Says:

    [...] 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 [...]

  117. Ubuntu 11.10 将搭载 GNOME 3 + Unity_Ubuntu新闻资讯 | UbuntuSoft Says:

    [...] GNOME 3 核心开发者之一 Dave Neary 的这篇文章和 Mark Shuttleworth 的回应。这在 GNOME Shell 和 Unity [...]

  118. Ubuntu 11.10 将搭载 GNOME 3 + Unity : OSMSG Says:

    [...] GNOME 3 核心开发者之一 Dave Neary 的这篇文章和 Mark Shuttleworth 的回应。这在 GNOME Shell 和 Unity [...]

  119. A szemléletváltás a Unity mögött « Udi Online Says:

    [...] amibe aztán egy KDE fejlesztő is csatlakozott. Ez egészen odáig vezetett, hogy Dave Neary GNOME fejlesztő az összefoglaló bejegyzésében a freedesktop.org szervezetet (is) hasznavehetetlennek titulálta. Vajon ez azt jelenti, hogy a [...]