Thoughts on GNOME

Note: This post is part two of a series of thoughts on the relationship between Canonical and GNOME.

When you think about the huge mainstays of the Open Source world, GNOME is right up there with the likes of Mozilla, Apache, KDE, the Linux kernel and Debian.

These are the titans of Software Freedom. Massive teams of co-developers, who regard themselves as a family… including the occasional creepy uncle. Individual volunteers work alongside paid contributors with corporate affiliations. Structures are formed to deal with differences of opinion, and facilitate productive collaboration between different kinds of contributors — individuals, corporate stakeholders, hackers, designers. Small teams grow within the larger project. Conferences are established to bring everyone together. Eventually, you’ll even find cliques.

Such communities carry immense history beyond code, such as development tools and processes, community conventions, and as with any large team, the (“we should really document that”) unwritten wisdom of experience. And in-jokes. Always with the in-jokes.

It’s easy to find fault with GNOME. It is, after all, a massive, lumbering project.

Who leads GNOME? Originally, Miguel de Icaza founded and led the project as a benevolent dictator, with maintainers of individual pieces as trusted lieutenants. As GNOME transitioned from science project to core infrastructure, growth in stakeholders demanded more structured decision-making, which eventually led to the GNOME Foundation and then the Release Team.

Today, as in 2000, the Foundation supports the goals of the project, but does not provide technical leadership. Mostly it manages the resources available to the project, maintains relationships with organisational stakeholders and provides a venue to resolve disputes. It may intervene when the project is unable to make a decision or move forward — the most notable cases of that happening include the formation of the GNOME 2.0 release team in 2001, and instigation of a plan for GNOME 3 in 2008 and 2009.

The release team is delegated with a fairly narrow set of technical leadership responsibilities: what to ship and when. Everything else is up to the maintainers of individual GNOME components, and a lot — a lot — of negotiation on the unwieldy general discussion mailing lists. :-)

GNOME has always been terrible at flag-posting places to pitch in. It’s difficult to figure out where and how to get involved, especially if you just “want to help”. Documentation of bite-sized, easy-fixes for new contributors is reliably miserable. Even with the rigorous release process, few developers write down their agenda for the next cycle, which makes it hard to know what they care about and how you might help.

The GNOME community is absolutely shithouse at mentoring and motivation. It takes a lot of perseverance and banging on doors to bring big new ideas to fruition, and most of it has to be done under your own motivational steam. Much of the time, this is is the result of process over people. The words GNOME people use to describe what’s “in” and “out”, “accepted” and “rejected” sound terrible.

There is a deep irony here, because GNOME was founded by the greatest Open Source motivator of all time, Miguel de Icaza. You could send Miguel a completely misguided and broken patch and he’d rewrite the whole damn thing, explain why (in the most encouraging of terms), tell you how much you rocked for contributing, and then… after all of that… he’d praise you effusively in the credits of the next release! Yes, I wish GNOME were more like its father. :-)

There are people in GNOME who are difficult to approach. There are people in GNOME who are of a grumpy or abrasive disposition. There are people in GNOME who are jerks. But throw a brick at any large group of people and there’s a good chance you’ll hit a fuckwit. Of course, there are great people in GNOME too, as well as procedures to deal with problems.

Ideas that were once bold and terrifying have become assumptions, seeping into the DNA of the project. An example: Ten years ago the idea of a six-month, time-based release schedule was wildly controversial. Who doesn’t have a time-based release schedule today, and what are they smoking? GNOME is actually behind the curve now, because the wide adoption of time-based schedules and rise of agile development means “six months” sounds grandfatherly!

Since the beginning, most GNOME developers have regarded their creation as a coherent whole, in two pieces: a desktop user experience and a developer platform. This was practically written in stone during the process of creating GNOME 2.0, when we defined the separate “desktop” and “platform” release sets. GNOME is not a miscellany of parts, occasionally thrown over the fence — it is intended to be an integrated, considered stack. More than the sum of its parts. Decisions are made on this basis, which may sometimes be confusing to new contributors.

Since 2.0, a particular angle on usability took hold, which is loudly criticised as often as it is misunderstood. I don’t feel the need to defend it here, but must note the impact it has on recruitment and approachability. GNOME developers are more likely to reject a new option or feature (different things!) on the grounds of usability, applicability to vision, or consistency across broader goals than many other projects. Not only can that be difficult for contributors to understand, it can be challenging for GNOME developers to describe!

GNOME developers are more likely to take a long term view of improving infrastructure from the ground up than to accept a quick fix hack. Consider the range improvements to the entire Linux desktop network stack spawned by Network Manager. This is why, for much the same reason, Havoc Pennington founded FreeDesktop.org way back in 2000: To promote practical cross-desktop interoperability.

The funny thing is, despite external commentators suggesting that the GNOME community is unaware of or does not accept its faults, GNOME participants are painfully aware of them all. Conversations along these lines were rife long before and long after I was actively involved in the project. Some of these problems are merely a matter of manpower. Some of them involve big decisions being made. Some of them are the fundamental challenges of volunteer-driven and leaderless societies.

Assumptions calcify. Processes calcify. Code calcifies. You can fix a hardening of ideas, but it takes people to do so. Individuals or a small team. Getting involved. Defining a vision. Making decisions. Communicating and compromising. Pushing the needle. That’s how you get things done.

It’s hard work being a contributor, and GNOME sure has its fair share of quirks, but it’s not especially different to any other large FLOSS project with thousands of stakeholders, and most importantly, it’s an open, independent, meritocratic, co-development community.

GNOME is People.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

This entry was posted in General and tagged , , , , . Bookmark the permalink.

18 Responses to Thoughts on GNOME

  1. One thing that is often not clear to people outside the GNOME Project, or even to people who thought they were part of it, is why some projects appear to have special dispensation.

    For example why was GNOME Shell given a defacto “accept” despite no code having been written, while GNOME Activity Journal was given a “reject” – even though it was fully featured, just because it didn’t interface with the thing that hadn’t been written.

    I think it’s this tendency to accept, and even hinge, on some projects while rejecting others that gives the greatest impression that GNOME is clique.

    • Jeff Waugh says:

      GNOME Shell wasn’t a defacto “accept” — it had to go through the module proposal process for GNOME 3.0 as well. But in a way, it was a special case: GNOME Shell was a new user experience strategy that the GNOME project specifically decided to conceive and pursue in October 2008. There was no guarantee of success or deployment. But it was a mission of the project.

      The approach to GNOME Activity Journal made complete sense: It was a separate user interface (an “application”) which exposed a feature that should simply be part of the desktop experience.

      I don’t believe either of those represents cliquey behaviour.

    • jonner says:

      I think there’s some additional reasons that make it fairly obvious why there are differences between these two specific cases. The seed for GNOME Shell was planted during a GNOME-sponsored hackfest whose explicit purpose was to talk about and plan the next generation of the GNOME desktop. It was a GNOME community initiative and involved a decent cross-section of GNOME developers. After that initial spark, it was carried forward by a group of core members of the GNOME developer community who worked on it within the GNOME umbrella and using the GNOME infrastructure. The activity journal on the other hand was developed by a group of people that seemed quite content to be seen as separate from the GNOME developer community and did their work on launchpad instead of the GNOME development infrastructure. In addition to the fact that it really doesnt’ make much sense as a standalone app, it’s really unsurprising that it wasn’t accepted as a part of the core desktop. At least that’s my perspective.

      • bkor says:

        The new ‘featured apps’ suite is meant to address applications like GAJ being hosted on different infrastructure. But don’t forget, a lot of contributors really care for consistency. Our translation teams really care that everything is translated correctly. Once it is not on GNOME infrastructure, they have to work with other tools, deal with difficulties (getting commit), etc. See desktop-devel-list mailing list archives.

    • Frej says:

      Just because something is fully featured, it should not automatically be included. GAJ as a standalone app isn’t very interesting (my claim) and thus it can’t be used to ensure that zeitgeist should be in the platform, since there is no real api ‘test’, just a data viewer (GAJ).

      I’m no insider nor in any clique, not even close, at most a mailing list lurker. I still think it was the right decision. Read the threads again, the proposals were quite poor and had a distinct lack of purpose. But it also delved into useless discussion about protocols/procedures and not the purpose, which entirely weren’t their fault.

      And, nobody said the reject is forever, you can always try again later. I even think ithey were to try again in the rejection. I don’t think the rejection, was because the zeitgeist/gaj team were/are outsiders or new contributors.

      Anyway, this is somewhat off topic and specific. I can only agree that cliques exists, but I think they are impossible to avoid. Cliques happen in an office of 3 people.

      • Jeff Waugh says:

        And, notably, rejecting GAJ was NOT a rejection of Zeitgeist.

      • bkor says:

        Correct. At the moment there is a patch in a bugreport which integrates Zeitgeist in the GNOME shell. It is still being reviewed. Patch doesn’t mean automatic acceptance though. It has to fit into the design. Once it does, I don’t see any reason not to accept Zeitgeist. Rejection really was about fitting into the design. Or: no technical showcase, but real enhancement in the way people work.

  2. Markus S. says:

    I think, creating the GNOME Foundation was the single biggest mistake in GNOME history.
    Originally GNOME was intended to be the desktop environment by the GNU project. However, since GNU is run by idealists with little intention to be a corporate puppet, Sun Microsystems and HP launched the GNOME Foundation – in a successful attempt (at least so it looks to an outsider) to effectively split off GNOME from GNU.
    Even though gnome.org still states that GNOME is a GNU project, both are entirely separate and in the end that hurt both: Almost no “pure” GNU software matters anymore (even the last strongholds glibc and GCC are in defensive mode: glibc was forked into eglibc and LLVM is the upcoming star on the compiler front) on one side and on the other side GNOME fails to be a multi-purpose FOSS community. The GNOME community creates the desktop environment and little more. There were several attempts to create an integrated office suite. Gnumeric was created and it was tried to get Abiword into the fold but both never saw themselves as a unified GNOME Office. At some other point, GNOME planed to fork OpenOffice.org.

    There are many applications for GNOME but few by GNOME.
    IMO the GNU-GNOME split caused a spirit that it’s OK (or even preferable) to be not part of GNOME itself. Pidgin and Banshee, for example, are aren’t applications by GNOME.

    If GNOME was nothing but the DE project by GNU, the spirit was spread to be part of the GNU project, and differences in attitude were resolved by a reform of the GNU structure rather than simply jumping on HP’s/Sun’s “Foundation wagon” to avoid the discussions, I think the unified community would today be bigger than GNOME+GNU today are.

    While KDE is anything but perfect, at least the KDE spirit lives there. KDE has not only the huge Software Compilation but also the very successful Extragear program. KDE manages to develop an office suite, educational software, web services (ownCloud), and is now even targeting its software to smartphones (Plasma Mobile).
    One may or may not like KDE software. How good or bad one finds it is only personal taste. However according to some report I once read KDE is the second biggest FOSS community after the Linux kernel.

    If GNOME was as inclusive as KDE, maybe the whole Unity debacle wouldn’t even had happened. Somehow Canonical manages to develop what it develops for Kubuntu mostly inside the KDE tree, so KDE apps directly support that Message Notifier thingie and not require additional patches.

    • Jeff Waugh says:

      If GNOME was as inclusive as KDE, maybe the whole Unity debacle wouldn’t even had happened.

      I believe GNOME is as inclusive as KDE, but they are different projects, with quite different values. It’s easy to misunderstand the intentions of people who operate differently.

      Regarding Unity… well. Stay tuned. :-)

      • Markus S. says:

        If GNOME is as inclusive as KDE: Where is the Extragear-like infrastructure?
        I can only find http://projects.gnome.org/ which is merely a link list.

        KDE allows almost everything to become part of the project and every contributor gets full commit rights to the whole source tree.

        OTOH it seems to me that GNOME’s history is a history of splits: It started with GNOME de facto splitting from GNU and leading up to Zeitgeist splitting from GNOME.

        Please don’t see my comments as attacks. I am actually concerned about what to me looks like a long going series of community splits and therefore weakening.
        I would be happy to learn that all my perceptions were wrong and both GNOME and GNU were in fact healthier than ever.

        • Jeff Waugh says:

          KDE allows almost everything to become part of the project and every contributor gets full commit rights to the whole source tree.

          The same is true for GNOME. You might be confused about the difference between “GNOME” as a project, infrastructure and meritocracy, and “GNOME” the product as defined by the release team.

          I don’t see your comments as attacks, but I think you’re speaking about a community you don’t actually understand.

          • Markus S. says:

            I know that every GNOME contributor has full commit rights to every module.
            However my point is: There are only few modules on git.gnome.org.

            Yes, I don’t fully understand GNOME as I am not an insider but I think you don’t fully understand “competing” communities either – possibly even underestimating how far reaching some inclusiveness efforts are.

            Well, it’s not like my comments here can change anything, esp. events in the past. ;-)

    • Chris says:

      Thank you for this insightful comment. Couldn’t agree more!

    • James Henstridge says:

      I was a member of the GNOME Steering Committee in the lead up to the formation of the GNOME Foundation, so maybe I can shed some light on this.

      One of the primary purposes of setting up the foundation was to have a legal entity to manage funds and property for the project. Prior to this, these funds were handled via the Free Software Foundation. In particular, the project had won some prize money in some free software poll/competition (I’d have to check my email archive to find out which one exactly).

      We had a good idea of what we wanted to spend the money on, but the FSF wanted veto power over any purchases, and wouldn’t guarantee that the prize money would be kept separate from the FSF’s general funds. The first point is understandable for a non-profit organisation, since they need to make sure that the purchase didn’t violate their charter. The second point meant that the longer we let them hold on to the money, the greater the chance that they would spend it on something else.

      Now, as far as the accusation that the GNOME Foundation is a corporate puppet, have you looked at the charter? Have you looked at how the board is elected? Have you looked at what it actually means for a company to be on the advisory board?

  3. bkor says:

    Really not true. When someone suggested forking GNOME and GNOME panel, I said it could be hosted on GNOME (after some initial effort). I don’t think it can get any more competitive than that. Aside from that, various times I’ve spend time to move projects to GNOME (including mailing lists and so on). I’ve suggested such moves various times. A projects can also request on their own to be hosted on GNOME, see http://live.gnome.org/Git/NewRepository. The only thing you have to be aware of (and what we warn about): it is volunteer based infrastructure and you have to keep that in mind. E.g. sourceforge or things like github might be easier for some projects.

  4. oiaohm says:

    Communicating is one of the big true problems. Not all these problems are Unique to Gnome of course. BSD camp is also known for quite a few. And Ubuntu has tones.

    Few major rules that need to become common.
    1) Don’t presume that somewhere will not listen.
    BSD example is claiming freedesktop does not support minorities.
    Ubuntu example is how much patching they do without talking to upstream first.
    Gnome example is how few new standards it sends up to freedesktop and other places for peer review. New draft standards are one of the ways of voicing disapproval for a freedesktop draft standard at the same time getting a broader check if what you are doing is sane.
    2) Don’t just walk away and not stand your ground if you believe something is the biggest defect going.
    Happens a lot at freedesktop.org we don’t like that standard we will not implement yet no feedback what is wrong. So this becomes lack of Communication. Something that Gnome is aware of internally. Gnome is just as bad externally.
    3) Upstream policies
    Freedesktop is technically upstream of Gnome. Gnome is upstream of Canonical . It is very hard for Gnome to say to Ubuntu upstream when Gnome itself is not supporting upstream and going and doing what it pleases. Do what I say not what I do. don’t work.
    Also stating clearly that Upstream policies have to be obeyed for inclusion would have disarmed a lot of the Canonical problems from the get go. KDE also has a second solve. To upstream the files have to be placed under KDE central management so while they are not they cannot be upstreamed. This rule would completely prevent Canonical copyright assignment problems.

    Some of the complaints about the notification item at freedesktop is that while the spec started with K since the draft was written by KDE it was not reviewed by Gnome people. Anything on freedesktop is meant to be an attempt at a spec for everyone. Gnome people need to become K blind basically. Something starts with a K read it anyhow. When the K was removed the Gnome people decided to read it and then found issues kinda too late after 6 months work has already been done and implementations on scale are being deployed to change it quickly. I am sorry but the boat was missed due to some of the Gnome people natural bias against anything KDE.
    Of course KDE personal at times need equal hitting over the knuckles for disregarding other party places standards and being internally looking.
    Its very much like being the best cart whip maker when everyone has changed over to cars and you did not notice because you were so focused on making whips.
    In some cases of missing the boat reviewing stuff means accepting the nasty. Yes the new standard does not fit well but we stuffed up so we are implementing anyhow and will try not todo this again. Problem is when lets blame the others happens. So preventing excepting the fact.

    A few shake ups in the way Gnome interacts with Freedesktop lot of problems will disappear. Even better work more with Freedesktop to get new standards out there and you can make Canonical job harder to claim to be Freedesktop compatible.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments will be sent to the moderation queue.