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

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

  3. 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.

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

  5. 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.

  6. 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?

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

  8. 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.

  9. 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.

  10. 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.

  11. 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.

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

  13. 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.

  14. 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.

  15. 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.

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

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

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

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

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

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