Community Power Part 4: The GNOME Way

In the first three parts of this series (part 1, part 2, part 3) we looked at how power works within GNOME and what that means for getting things done. We got to the point that to make things happen you (or someone you’ve hired) need to become a trusted member of the community, which requires understanding the project’s ethos.

In this post we’ll go over that ethos, both in terms of high level values, and what those translate to in more practical terms.

Values and Principles

GNOME is a very principled project, and there’s a fair amount of writing on this topic already.

Allan Day’s “The GNOME Way” (2017) is a great starting point, but I’d also recommend Havoc Pennington’s classic “Choosing our Preferences” (2002), and Emmanuele Bassi’s “Dev v. Ops” (2017). I’ve also written about some aspects of this in the past, including “There is no Linux Platform (2019)”. For some broader historical context also check out Emmanuele’s excellent History of GNOME podcast.

To give you an overview though, here’s my personal bullet point summary. It follows the same structure as the development process laid out in part 2 based on what areas specific values and ideas apply to. It’s not meant to be comprehensive, but rather give you an idea of the way people inside the project think.

The Why

Base motivations that inform everything we do.

  • We believe in software freedom as an inclusive, accountable model for producing technology in the commons.
  • Our software is built to be usable by everyone. We care deeply about user experience, accessibility, internationalization, and support for a diverse range of hardware.
  • Software should be structurally and aesthetically elegant, both in terms of underlying technology and user interface.

The What

What kinds of things we think are worth pursuing, and (just as important) what kinds of things should be avoided.

  • Third-party apps are the best abstraction to extend the core system with additional functionality. This is why we put a huge amount of work into empowering third party app developers to build more and better apps.
  • Every preference has a cost, and this cost rises exponentially as you add more of them. This is why we avoid preferences as much as possible, and focus on fixing the underlying problems instead.
  • Similarly, there is a direct relationship between how vertically integrated a product is and how cohesive you can make it. Every unnecessary variable you eliminate across the stack frees up time and energy, and creates opportunities for features you couldn’t otherwise build.
  • People’s attention is precious. We pride ourselves in being distraction free.

The How

Useful rules of thumb around how we go about making things.

  • We don’t do hacks. Rather than working around a problem at the wrong layer of abstraction, we believe in going to the root of the problem and fixing it for everyone, even if that means digging into lower layers (and ends up being far more difficult as a result).
  • We see design holistically, rather than as an isolated thing the design team does. It’s not just about functionality and aesthetics, but also underlying technology, and what to build in the first place. Even if you’re not contributing on the design team, developing an affinity for design will make you a more effective contributor.
  • Looking at relevant art is important, but simply copying the competition doesn’t usually produce great results. We have a proud history of inventing new paradigms that are better than the status quo.
  • As a general rule, start from the user experience you want and then go about building the technology necessary to create it, not the other way around. However: This is not an excuse for bad engineering or pursuing ideas that are conceptually impossible (e.g. multi-protocol chat clients).
  • Defer to the Expert. Everyone has different areas of expertise, such as user experience, security, accessibility, performance, or localization. Listen to the people most experienced in a given domain.
  • Design is all about trade-offs. Be wary of hard and fast rules that only look at one part of a problem (e.g. “vertical space is at a premium, therefore…”), and instead try to balance various concerns in a way that works well overall.

In Practice

Some of the above principles are quite abstract, so what do they translate to when actually building software day to day? Here are some examples of how they apply to real-world questions.

  • App developers should do their own packaging. It’s the only way to do it sustainably at scale.
  • Flatpak is the future of app distribution.
  • The “traditional desktop” is dead, and it’s not coming back (Note: I’m talking about Windows 95 era UI patterns here, not desktop vs. mobile). Instead of trying to bring back old concepts like menu bars or status icons, invent something better from first principles.
  • System-wide theming is a broken idea. If you don’t like the way apps look, contribute to them directly (or to the platform style).
  • Shell extensions are always going to be a niche thing. If you want to have real impact your time is better invested working on apps or GNOME Shell itself.
  • “Filling the available space” is rarely a good goal by itself, and an easy way to design yourself into a corner.

All of the above is of course my personal perception, and you’ll find variations on these ideas depending on who you talk to. However, in my experience most of them are shared fairly consistently by people across the community, especially given our informal structure.

Now that we’ve covered how things get done, by whom, and why, you’re in a great position to start making your mark. In the next part of this series we’ll look at practical first steps for contributing.

Until then, happy hacking!

6 thoughts on “Community Power Part 4: The GNOME Way”

  1. Thank for your post :)

    I would be cautious about “Choosing our Preferences” (2002). The path of doing automatically the right stuff to avoid a preferences is right and also not bloating the software until it becomes unmaintainable and lose it’s intentional purpose. On the other side, missing required preferences stimulus for concurrent forks which not get merged back and instead split the developers, testers and community. A fork with the intention of learning or being merged back is worth every effort, but a fork which splits away with the aim of never being merged back is likely something to worry about. Of course there are always people and feelings involved, too.

    The missing preferences for “Do not suspend on lid close”, because people have different reasons to close the lid. And the transparency of the terminal, which is now maintained for years with extra patches and favoured by many users. By the way, Windows Terminal offers now also transparency – a thing GNOME did many years before. Why we need the tweak tool for the font settings, that is a hidden setting for non-expert users.

    One lesson I take from this old post is – five competing clock applets are not needed, if there is one which does the task properly and offers the appropriate preferences. Not all imaginable preferences, but the needed ones. I understand and accept that I need an extension to move the clock to the right-hand side – it is a special thing. On the other hand, the beginning of the week is “for me” on Monday*. Evolution accepts my opinion, GNOME not.

    And some things should be just tune-able for testing purposes and as mere fallback, out of sight-line for most users and easily reset-able.

    A suggestion from me would be a permission style switch per website like “Webcam Access” for JavaScript in Epiphany. It reduces load and increases battery runtime. You can use well designed websites without JavaScript for example Amazon. And this permission panel is already in place. Firefox tries to fight this with a internal “Task Manager” where you can see which websites creates a lot CPU-Load :(

    * Europe and ISO-8601 consider the same. And there a lot of people with a favor of Saturday. There is no right or wrong, because it is a preference.

  2. old concepts like menu bars or status icons, invent something better from first principles.

    This is definitely true, the bad side of this is that (for the status icons side), sadly, no viable design concepts to replace them have been defined in the past 10+ years leaving users without features they seem to appreciate (according to popularity)

    1. There is a fairly well-documented solution, but it’s multiple APIs with a clear purpose, not a new API for companies to get free publicity by making their logo persistently visible ;)

      But even if we had a new “add my logo to the top bar” API, people would not port their apps to it until we phase out support for the old one, so if apps will have to be ported anyway might as well port to something sane.

      If Ubuntu had dropped status icons when we did it upstream 4 years ago, apps would have adapted to a status icon free world by now. Realistically, solving this just depends on you guys. The sooner you drop the old API, the sooner this stops being a problem for everyone.

  3. > Shell extensions are always going to be a niche thing.

    Not quite sure I follow what you mean there. In what sense of “niche” are extensions like Dash to Panel or Dash to Dock niche things?

    1. Shell extensions are niche in the same way Firefox extensions are. They’re a separate, optional thing you need to know about and install from a special website.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.