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