Disclaimer: The opinions expressed in this article are the writer’s own and don’t necessarily reflect those of Linux User & Developer magazine or Imagine Publishing Ltd.
As the developer of an independent Linux file and desktop manager, one gains a multifaceted perspective on everything from GUI issues and the general user experience, continuing through UI toolkit APIs and theming, down to low-level kernel APIs for device and file system support, and their incumbent issues. Yet I find I’m not the only one walking these moodily lit, disparate corridors. In tracking down assorted breakages and malfunctions in my own software, I have been surprised to repeatedly encounter the same developer footprints spread across many of these areas. It turns out that these developers, and developer teams, have often been directly responsible not only for the breakage I’m investigating, but for issues affecting a large swathe of Linux users and developers.
This narrative begins not quite at the beginning, but with a recent experience addressing problems in GTK+ version 3. GTK (originally the GIMP Toolkit, as it was written for development of the GNU Image Manipulation Program) is one of the two most popular interface frameworks in Linux (the other being Qt). While GNOME is one of the most well-known users of the (originally community-developed) GTK project, there are many other projects based on GTK, including the LXDE and Xfce desktop environments, Claws Mail, AbiWord, Chrome, Firefox, Midori, Pidgin and many more. Yet GTK’s independence is challenged by the fact that GTK is now developed and maintained by the GNOME Foundation. Red Hat is the biggest corporate contributor to the GNOME project and to its core dependencies – 11 of the top 20 all-time GNOME committers are current or past Red Hat employees. Other influential contributors to GNOME include Google, IBM and Intel.
In its latest releases, intrinsic problems with GTK’s development along with a growing culture of enforced conformity from GNOME developers have presented a challenge in producing stable, flexible software outside of GNOME. Many developers feel that with the advent of GNOME 3, GTK has become deliberately developed as a GNOME-only tool, to the exclusion of its other applications. Clem, a member of the Linux Mint distribution’s development team writes, “GTK 3 isn’t a reliable API. Maybe it should be called libgnome instead… I genuinely get the feeling that GTK 3.4 is developed for GNOME 3.4, that it doesn’t really matter if it breaks things and that we’re not supposed to use it outside of GNOME.” [Fig 1]
With GTK 3, the application programming interface (API) for GTK was changed, meaning applications written for GTK 2 need to be ported to continue using it, a time-intensive process. While in some cases API breaks are sometimes necessary, it seems in this case that GTK/GNOME developers made no effort to limit breakage. Further, popular GTK application development tools like Glade were thrown into disarray, with distributions such as Debian abruptly discontinuing support of GTK 2-compatible Glade versions, leaving GTK application developers stuck for support. [Fig 2]
Developers who do address the formidable task of upgrading to GTK 3 face the next hurdle: wild breakage of third-party themes with almost every minor GTK release. This has independent theme developers screaming. Spending many hours creating GTK 3 themes, they are horrified to discover that all of their work is rendered obsolete just weeks later with the next GTK 3 release, requiring them to start from scratch rewriting their themes. As GTK 3 theme developer ‘half-left’ comments, “Upstream is impossible to work with and GNOME 3 has become a complete mess in regard to third party theme making.” [Fig 3] Another GTK 3 theme developer reflected, “…It’s such a pain to develop a GTK 3 theme. It’s always broken. I have a version of my theme for GTK 3.2, one for GTK 3.4, one for GTK 3.6… For GTK 3.4, it was so broken that I had to code it again from the beginning. Days and days of wasted time and frustration. And almost no documentation.”
No time for compatibility
When I confronted Benjamin Otte, Red Hat’s developer in charge of GTK 3’s theming support, on this issue, he responded with complete disregard. “GTK doesn’t swim in extra developers that are happy to spend their time ensuring compatibility with rarely used themes. I decided the time was better spent implementing new features than caring about other themes,” writes Otte. Theme developers responded that the “rarely used themes” he refers to are hugely popular, representing many hours of volunteers’ time, and have already been downloaded many hundreds of thousands of times.
Benjamin Otte continues, “All the theme authors participating in GTK development (read: not you) agreed that it’s better to keep their themes up to date if in exchange they get new features than keeping with the status quo.” Who are these “theme authors participating in GTK development”? Exclusively Red Hat’s corporate customers. In the same conversation, GTK developer Emmanuele Bassi clarifies: “The GNOME standard theme (Adwaita) is updated each time something changes – and GTK+ is updated each time a new requirement is put forward by the theme authors for GNOME and Windows (and Mac OS).” In other words, these theme authors are dictating changes to GTK development, while independent theme developers are having their work broken wilfully by these same changes, and are receiving virtually no support or documentation. Nonetheless, Benjamin Otte expresses his deep appreciation for compatibility: “After those decisions were made, no time was spent on even thinking about compatibility.”
A threat to the brand
What does this theme breakage amount to? It means that many tens of thousands of Linux users will experience app breakage, memory leaks and other serious issues almost every time they update their systems. Theme and app developers will be (and are being) inundated with inexplicable bug reports and continuous breakage of their work, requiring many hours to isolate the problems and to repair and rewrite themes. To put it in another perspective, hundreds of thousands of man-hours are being wasted by Otte’s approach with almost every update to GTK.
The origin of these surprising positions toward theme stability become more clear when we take a look at the GNOME team’s goal for creating brand presence and identity for their ‘product’ at all costs to usability. In reviewing comments made by GNOME developers in the course of GNOME 3’s design, it’s clear that they view themes and other customisations as a threat to their brand’s visibility. GNOME 3 designer Allan Day wrote, “Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design. We’ve fought long and hard to give GNOME 3 a consistent visual appearance… The point is that it decreases our brand presence… I really think that every GNOME install should have the same core look and feel.” [Fig 4] GNOME developer William Jon McCann concurs, “I agree with Allan. I am really concerned about this effort to encourage and sanction themes and extensions… The issue is not whether extensions may be useful. The issue is whether they will be harmful to our larger goals.”
Can’t fix? Won’t fix
Suddenly, the complete abandonment of a responsible, accessible theming API by GTK developers begins to fit into a larger picture. Yet themes aren’t the only area where GNOME developers are in conflict with users and other developers. They seem to be on a veritable rampage removing popular features, creating breakage and even trying to have features removed from non-GNOME apps. Many believe that Red Hat is aggressively pushing GNOME into the lucrative tablet market, which requires a much simpler interface than a desktop, and are therefore abandoning support of desktop users. Received via my email, a long-time GNOME contributor (who wishes to remain anonymous) writes, “This situation was very common during GNOME 3 updates. Lots of removed features, no dev communication, no consideration for users… with GNOME 3, devs have gone too far and I didn’t want to be treated this way… It was clear to me that I would never use GNOME again.”
Bug reports for GNOME 3 are littered with users requesting restoration of removed options and extensions. These are quickly closed as ‘WONTFIX’ by GNOME developers, with trite replies such as, “we finally decided there’s no use for an editable toolbar in Nautilus,” and “There are currently no plans to reintroduce the location bar… as the cluttered interface has been simplified for 3.0.” GNOME users are dismayed with the latest version of Nautilus (3.6) removing many popular features, including Compact View, Type Ahead Find, New File Templates, Application Menu, Go Menu, F3 Split Screen, Tree View, Bookmarks Menu and the backspace shortcut to return to the parent folder – all now gone. [Fig 5] Extensions and applets are on the chopping block too. GNOME developer Bastien Nocera writes, “We’re not designing a desktop for people who like to choose their own terminal emulators”, and William Jon McCann writes, “I think one of the most important cases against applets (as they are currently defined in GNOME) is that they are extremely detrimental to the Identity of the product… So, one of the many very exciting things about GNOME Shell is that for the first time we may have ability to really shape the user experience and form an identity for the GNOME platform.” Exciting for him perhaps, but likely not what excites users.
Beyond just GNOME apps and tools being stripped of options, Red Hat employee and lead GNOME developer William Jon McCann was caught opening a bug report on the independent Transmission BitTorrent client telling the developers that its panel notification feature should be removed. Why? Merely because GNOME 3 no longer supports a panel: “Transmission has an option in the Desktop tab of the preferences to ‘Show Transmission icon in the notification area’. This should probably be removed.” Transmission developer Charles replied, “So now we can have three builds of Transmission that decide at compile time whether to use AppIndicator, GtkStatusIcon or nothing at all… Removing it altogether, as you suggest, will hurt Xfce users.” McCann replied, “I guess you have to decide if you are a GNOME app, an Ubuntu app, or an Xfce app unfortunately… And I have no idea what Xfce is or does, sorry. It is my hope that you are a GNOME app.” Charles’s reply to this: “*speechless*”.
Can we really and seriously believe that William Jon McCann, described as one of the main driving forces behind the concepts of GNOME 3, doesn’t know what Xfce is? What are the consequences of having a large corporation like Red Hat (perhaps with strong influence from the ultra-wealthy Google) in control of widely used open source projects like GNOME and GTK, with its teams of developers routinely altering their APIs in unpredictable, erratic ways and offering no real support to independent projects using their libraries? It’s clear that with the advent of GNOME 3, GNOME has become a corporate product solely created for and controlled by Red Hat.