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