Moving the needle in GNOME

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

I was incredibly tempted to entitle this post, “Pushing your turds into GNOME’s immaculate and exalted vessel”, but thought it might be taken seriously. After all, everyone knows GNOME developers believe they’re inviolably perfect, right? :-)

All Changes Great and Small

Software development is an immature branch of the discipline known as “change management”. The weapons are different, but the war is the same: Improvement generally requires change, but change involves investment and risk. So we invent convoluted schemes, tools and rituals to make change easy, but not dangerous.

FLOSS projects in particular must make change easy, because people are their most valuable resource, and change is the process through which new contributors become familiar with a project and subsequently — hopefully! — become involved.

It’s pretty simple: Contributors are your participants. If there is nothing to contribute, you have no participants. If you have no participants, you barely even have a project, let alone co-development! For FLOSS projects, change has an incentive beyond improving the software.

Readability is the key to creating code that others will use. Because in the end? We can scale silicon, but carbon? People are much harder to scale.

– Brian Aker, Drizzle goes GA, From “What If”, to “What has”

Small Changes

By small, I don’t mean insignificant. A one-line patch can fix a crasher, resolve a terribly hard-to-find heisenbug, or launch a project-wide flame-war over its correctness. By small I refer to the risk/reward ratio, which will affect how easy it is to make a decision — with both social and technical influence — about the change.

Bug fixes: In the olden days, new contributors would file a bug and attach their patch, or send a patch to the project mailing list. In modern times, a new contributor would raise a merge request in the code review system from their own distributed revision control branch. The maintainer usually has a straightforward decision as to whether the bug fix is correct and appropriate… or not.

(Despite using distributed revision control, GNOME still mostly lives in the olden days, so patches are sometimes left to rot without review.)

Features: A larger change, adding functionality or behaviour. Most of the time these are best discussed with the project maintainer before starting work, as they’re likely to have a good idea about how they’d prefer it to be implemented, or may not want the feature at all.

In GNOME, the maintainer of a module is almost always the “architect” or “manager” of that code, and is responsible for making these decisions. If the maintainer is sceptical of your feature, then you’ll have to do some convincing. Co-development is as much a social endeavour as it is technical!

Settings: What if you want the software to behave one way, but your friend wants it to behave differently? Surely that’s reason enough to add a switch to choose between them? After all, software can do anything, and computers should adapt to our needs, right?

Most GNOME developers will look at this problem differently. You may occasionally hear the phrase “options are bad”, but that’s shorthand for a deeper philosophy: What if we could make that problem simply disappear, rendering the choice itself meaningless?

Switches like this increase the complexity of the code and the “surface area” of software machinery exposed to users. If we, as software developers (and UX designers), think a bit harder about the problem before foisting it on users, perhaps we can solve it… and if we get it wrong, it’s easy to fix.

That’s why “adding an option” involves more friction in the GNOME community that you are likely to find elsewhere. Of course, some developers hate that approach. Some users hate that approach. But others find it truly inspiring.

Applications or utilities: If you want to contribute an entirely new piece of software to GNOME, it must go through the Release Team’s module proposal process. As long as you meet the long list of conventions and standards upheld by the GNOME community, and your software is relevant, you’re pretty likely to get in. As of GNOME 3.0, it’s even easier, because the Release Team has split out recommended applications from the core components of the desktop user experience — panels, window manager, file manager, etc.

Large Changes

Cross-module changes: Sometimes you can’t surface a feature within the scope of a single module, so you have to convince a number of maintainers to not only accept the feature, but if required, agree on a way of sharing necessary information between their modules, and accepting the maintenance load of making sure cross-module integration continues to work.

A good example of this kind of change is the list of folders that are remembered and shown throughout your GNOME experience — in the “Places” menu in the panel, the sidebar of the file manager, in standard file dialogues, etc.

New APIs: Providing a new capability throughout GNOME, and perhaps to third party developers, usually means adding a function to an existing platform library, or for more involved capabilities, you might even need to write your own shared library and convince developers to use it.

Lots of mistakes can be made when it comes to APIs and shared libraries, and because the GNOME community wishes to provide a consistent, reliable platform, it is an area that involves a lot of rules and policies. Number one on that list is the commitment to API/ABI compatibility throughout GTK+ and GNOME’s major version releases. GTK+ 3.x involves the first significant, platform-wide API/ABI break in 8 years!

New APIs will often be adopted as copy’n’paste code from incubator modules like libegg. So rather than make new library developers worry about API/ABI compatibility during development, users of the new API can just copy the code. Once everyone’s happy, it can be deployed into an existing platform library (such as GTK+), or a new shared library.

Proposing a new shared library can be arduous. For the last 8 years, developers have been naturally wary of expanding the (sprawling) surface area of the developer platform, so your library would have to be incredibly convincing to begin with… even then, perhaps the new API would make more sense in an existing platform library.

Plus, it won’t land in the API/ABI stable developer platform or external dependency list straight away: That’s a very serious commitment. The community will need a chance to get comfy with the new API before taking any marriage vows!

User experience changes: Making GNOME itself — the fundamental user experience of the product — look or work differently can be the most challenging proposal of all.

On one hand, it’s an intensely social process, because you’ll probably find yourself trying to convince the entire project to accept your change. On the other hand, it is a technical issue, but very different to fixing a bug or adopting a library: Now you’re invoking huge questions about user experience, acceptance testing, user stories, who GNOME is for… if you don’t have the technical skills to make good decisions on all of those fronts, you’re in for a rough ride.

You just thought it might be nice to have two panels instead of one. Then everyone got all existential. Welcome to GNOME. :-)

The Inevitable Linux Kernel Comparison

All of that sounds terribly difficult. “Why can’t GNOME be more like the Linux kernel?”

They’re not really that different. Two big ones: Linux ships as a single tarball, GNOME’s user interface has quite a different audience profile.

Linux still has plenty of components and subsystems, maintained by different people. A hardware driver might be a nicely contained chunk of work, but if you want to change the SCSI subsystem, you’ll have to convince a few people along the way. Want to make a big change? Ask for advice (a “Request For Comments”) before carpet-bombing lkml with your patch-set. Thoroughly unsurprising stuff for large-scale co-development.

Believe it or not, kernel maintainers are getting the “options are bad” religion. Yes, even in the kernel, settings and magic numbers can increase complexity of code and the “surface area” of software machinery for users — systems administrators — to deal with. Years after calling my friends and I “interface nazis”, Linus questions whether or not big chunks of the Linux kernel can “just work”. :-)

You’ll definitely hear some developers whine that Linux doesn’t have stable internal APIs (one clear advantage to working in a flexible, monolithic codebase), but don’t get caught breaking the userland API/ABI…!

“We’re not so different, you and I.”

Technical Leadership

Every now 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 simple.

It might not be immediately obvious. It might not be particularly efficient. It might not be convenient. But you know it exists… if only because trying to sneak past it will cause all hell to break loose.

What is it? A meritocracy, where legitimacy and influence is derived from contribution.

Becoming a Leader

Training and growing technical leaders in GNOME is not unlike other open, meritocratic, co-developing FLOSS projects.

You send a little patch, perhaps to fix a bug, and the maintainer accepts and commits the change. Encouraged, you fix more bugs, implement some minor features and send a patch for each change.

Eventually, you send enough good stuff that the maintainer wants you to commit directly (the lazy maintainer principle in action). You request an account, and the maintainer backs you up. Now you can commit to all the things!

Your changes still have to be accepted by the maintainer, but now she can ask you to commit directly instead of sending patches or merge requests.

(You submit a few changes elsewhere, and the other maintainers trust you that little bit more, because you already have an account on the GNOME revision control platform!)

After a while, the maintainer sees that you have a good understanding of the code, and in a moment of brilliant laziness says, “Hey, you don’t need me to review your changes now, I trust you.” Of course, you still talk about more controversial or difficult changes prior to committing.

Eventually you work well enough as a team, you’re blessed as a co-maintainer, and five minutes later the original maintainer announces she’s travelling around the world on a donkey. So now it’s up to you, co-maintainer for five whole minutes. Time to find some more contributors…

Maintainers

If there were an Arthurian round table of technical leadership in GNOME, it would be the motley group of developers who maintain all the modules in the various release sets: The Maintainers (it’s not a band).

But there are a few round tables — maintainers of the developer platform, the core user experience, the language bindings, etc. Each has more sway in certain decisions: Should libfoo be in the platform? Should gnome-baz be integrated into the default desktop UX? These are project-wide decisions for which maintainers often wield increased influence.

Day-to-day, a maintainer’s influence is generally limited to their own software module, defining the vision and architectural approach, deciding which patches to accept, etc.

GNOME Foundation

Founded in 2000, the GNOME Foundation was designed to serve the project by doing all the boring things — keep money, manage relationships, etc. It was also granted the task of defining GNOME as a product, largely because there were arguments about it at the time, and the big companies joining the community desired… clarity and stability.

Today, the democratically elected directors of the GNOME Foundation essentially form a community council. The power to “set the technical direction” was delegated to a newly-defined Release Team in 2001. But if you want to “deal with GNOME”, you speak to the Foundation. If there is a disagreement in the community, you go to the Foundation Board for mediation.

The GNOME Foundation Board of Directors is still called upon when big problems need solving, but does not play a role in the day-to-day technical decisions of the project.

Release Team

The Release Team maintains GNOME’s six-month time-based release process, and is responsible for defining the product in a broad sense, and ensuring that it continues to meet community-defined maintenance policies (stuff like API/ABI compatibility, where work is done, etc).

Like the maintainers of individual modules, it is not a democratically elected group. If a member should leave, the team will choose a successor — amusingly, this has often been done by following the advice of the departing member!

It may not be a democratically representative group, but because the Release Team is delegated by the GNOME Foundation to serve the project — not the other way around! –the developer community could easily overturn a bad decision by the Release Team. If the situation warranted it, the community could even ask the GNOME Foundation to replace the Release Team!

I can’t quite imagine that ever happening though, because members of the Release Team know that they serve the desires of the community, and practically every decision is made on the basis that it properly represents those desires.

Difficult Decisions

Sometimes the GNOME community has found itself unable to make a particular decision at all. This is less of a reflection of GNOME’s decision-making capacity in general — or lack of technical leadership to do so — than it is of the impossible decisions themselves.

For instance, despite the many years of flame-wars and criticism, there has never been a clear answer about Mono. The GNOME community doesn’t “support” it, but in large part, doesn’t want to shun it, either.

That was an impossible decision because it meant telling members of the community — friends! brothers and sisters in freedom! — that they were not wanted. For all the legal and technical arguments in the world, the haters never understood this simple problem.

Mono is still a special case. It’s still in limbo. Some decisions are impossible to make.

GNOME 3.0

How does the decision to take on a huge new release effort happen in a community that supposedly “has no technical leadership”?

What happens after that decision is made is an entirely different question — a whole community of individuals contributes a huge amount of work! — but what about the decision to make it happen in the first place?

A meritocratic project doesn’t make a decision like that at the drop of a hat. It would require lots of agitation and convincing, plenty of groundwork, heaps of preparation.

Remember, the GNOME community had been talking about GNOME 3.0 as a concept since at least 2005!

I believe we can credit much of that agitation, groundwork and preparation to the sheer dedication of a single person. It was, without a doubt, an incredible expression of open, meritocratic, technical leadership. It moved the needle.

He began, like everyone, without any involvement in GNOME at all. Today, he is what I would describe as the architect and father of GNOME 3.0.

He would ever so predictably deflect that praise on to the entire community who rallied around him.

Thank you, Vincent Untz.

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.

19 Responses to Moving the needle in GNOME

  1. Jeff Waugh says:

    Owen Taylor also deserves immense credit for GNOME 3.0, particularly as lead developer on GNOME Shell. He is, perhaps, the CTO of GNOME. :-)

    I called out Vincent for praise in particular was because he basically cajoled the entire community into taking GNOME 3.0 seriously. From the UX hackfest in 2008, through to release team strategy — GNOME 2.30 = GNOME 3.0 and the ultimate GNOME 3.0 plan — he really did bring the community together.

  2. hanz says:

    GNOME needs a branch in every module containing bugzilla patches.

    • Jeff Waugh says:

      Owen Taylor has built a patch review system for Bugzilla called Splinter, which quite a few GNOME people use. There are also different ways of going about the problem like Review Board and even gitorious.

      But adding these kinds of things to GNOME infrastructure and then embedding them in the culture takes time…

      • nzjrs says:

        Don’t forget git-bz (the other piece of the puzzle)

        It is magical.

        (Ed: Updated with link to git-bz info for those playing at home.)

  3. These are great posts and the best part about them is I am traveling this week and the new posts show up just as I sit down for dinner by myself, so I have something to read

  4. Dave Neary says:

    Seems like I need to clarify what I meant by no technical leadership (of course, you are correct in your description of GNOME).

    There is no technical leadership body. There is no master plan. We don’t have a politburo who meet regularly to decide what to do next. The release team doesn’t fit that bill, although it would be relatively easy to make a list of 10 or 15 GNOME elders who could probably bring the entire project with them if they agreed on something.

    The group of influential maintainers changes over time in ways that aren’t obvious. Someone gets promoted to manager and does less hacking, but still wields enormous influence, Or changes jobs and has less time. Or gets assigned to lead development on an important module. And the leadership changes, with no warning, no announcement.

    That’s what I mean by no technical leadership – no formal and identified technical leadership. No bosses. Influence, not control.

    Dave.

  5. Dave Neary says:

    I had to look up furphy by the way :) Nice word.

    Dave.

  6. foo says:

    Please move this blog entry to gnome.org/contribute or similar.

  7. Vincent Untz says:

    Thanks for the love :-) Of course the praise should go to the whole community since the idea of GNOME 3.0 that the release team pushed would never had happened without a global move inside the project.

    But on top of that, a story about the genesis of the idea of GNOME 3.0 would highlight the role of other release team members very early on — especially during some discussions with Lucas in front of a hotel in Brussels (before FOSDEM 2008), and later with Andre and Olav in Prague (at UDS Intrepid, in May 2008). And it’s easy to see how other release team members have been rocking to make GNOME 3.0 a success since then. I’m very much in love with Frédéric Péters, for example.

    That’s why the release team is, well, a team and not a one-man show ;-)

  8. Vincent Untz says:

    Oh, btw, just in case you still have lots of time to document things… The story of the migration to git is an interesting one. It was one of those difficult decisions, but because of its really critical nature, we were able to move forward (with some pain, though).

  9. chris says:

    I should have read this article sooner but i always wanted to ask this at someone from GNOME.
    Are the GNOME developers dotfile fetishists?
    I dont use GNOME but every time i have to start a GNOME application i get 6 empty .directories in my $HOME. eg. .gconf .gnome2 .local .config etc etc etc etc.
    I used to have a libpulse in one of my systems. That alone, not a complete pulseaudio implemention, created a directory and a file.
    Have you ever seen what the $HOME of an Ubuntu of Fedora installation looks like? Its full of uneeded GNOME crap. I am definitely not against creating dotfiles.
    They’re very useful especially when they’re human readable. But why does each and every GNOME application need to have each own configuration directory? Isnt a .gnome enough? When does the madness end? Will dconf adress this ?

    • Jeff Waugh says:

      Heh, a lot of that is historical mess, still there for compatibility. It was only years later that everyone defined and adopted the XDG file locations to try and clean all of this up (~/.local and ~/.config). GConf and dconf do address this to a certain extent, keeping a bunch of settings from different applications in their own storage areas, but I don’t know when or if the old stuff will disappear.

      • chris says:

        Thanks for the reply.
        BTW i want to apologise for the use of the term ‘crap’.
        I didnt mean to sound disrespectful. I know most of those files are actually useful. But i think the situation can improve greatly in this.
        I was considering opening a feature request about this at one point on the bugzilla. Reading your article made me realise that most likely it would be classified under the “User experience changes” category, meaning i would probably be asked to write patches for every app.

        PS. I know that .config and .local are actually XDG specified. I just dont remember the actual names of the directories they’re created so i used those as an example. The only GNOME app i use is evince which is built without gconf support so it cant save settings, but also avoids creating all those needless for me dotstuff. Kinda like the evince-gtk package in Debin.

        PS2.I also didnt mention xdg-user-dirs on purpose. Thankfully i can avoid seeing those as they havent been pushed down the stack in udev or dbus, yet. :)

        • Jeff Waugh says:

          Messy dotfiles are not a user experience issue, just one of compatibility. There are probably only a few modules for which those directories still matter, and are easily found and patched. I can’t imagine it’s particularly high on the priority list, and rightly so.

  10. A few notes on meritocracies…

    Based on deeper consideration inspired by articles like http://asymptomatic.net/2009/03/21/2795/meritocracy-versus-do-ocracy and http://geekfeminism.org/2009/11/29/questioning-the-merit-of-meritocracy/ I have re-evaluated my use of the term “meritocracy” in free software communities.

    The dynamic you describe in context: “A meritocracy, where legitimacy and influence is derived from contribution” I would call a do-ocracy, where authority is derived from action and contribution, rather than a meritocracy, where it is said to be derived from intrinsic goodness (whether of people or patches). I think that “do-ocracy” more accurately reflects what you and I mean when we talk about this kind of community, and it neatly sidesteps the problem of who evaluates merit.

    That said, we live in the real world, where things are still much messier than “just do it”, and not all contributions are favored equally. We need look no further than the long-standing inflation of the value of code contributions compared to every other kind of contribution. As you rightly point out, co-development is a fundamentally social endeavor, and yet social contributions are rarely recognized according to their objective value.

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.