After reading “Community Power Part 4: The GNOME Way“, unlike the other articles of the series, I was left with a bittersweet taste in my mouth. Strangely, reading it triggered some intense negative feelings on me, even if I fundamentally agree with many of the points raised there. In particular, the “The Hows” and “In Practice” sections seemed to be the most intense triggers.
Reading it over and over and trying to understand the reason I had such strong reactions gave me some insights that I’d like to share. Perhaps they could be useful to more people, including to the author of article.
I think one of the misleading aspects of the article is the extensive usage of “we” and “us”. I’d like to remind the reader that the article is hosted on a personal blog, and thus its content cannot be taken as an official statement of the GNOME community as a whole. I’m sure many members of the community read this “Community Power” series as “Tobias’ interpretation of the dynamics of the community”, but this may not be clear to people outside of this community.
In this particular article, I feel like the usage of these plural pronouns may have had a bad side effect. They seem to subtly imply that the GNOME community think and act on a particular way – perhaps even contradicting the first part of the series – which is not a productive way to put it.
On Nuance And Bridges
The members of the GNOME community seem to broadly share some core values, yes, and these values permeate many aspects of daily interactions in varying degrees. Broad isn’t strict, though, and there actually is a surprising amount of disagreement inside the community. Most of the times, I think this is beneficial to both personal and collective growth. Ideas rarely go uncontested. There is nuance.
And nuance is precisely where I think many statements of the article fail.
Let’s look at an example:
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.
If I take the individual ideas, they make sense. Yes, contributing to GNOME Shell itself, or apps themselves, is almost always a good idea, even if it takes more time and energy. Yes, Shell extensions fill in the space for very specialized features. So, what’s the problem then?
Let me try and analyze this backwards, from how I would have written this sentence:
Shell extensions aren’t always the best route. If a particular feature is deemed important, contributing to GNOME Shell directly will have a much bigger impact. Contributors are encouraged to share their ideas and contribute upstream as much as possible.
Writing it like this, I think, gives a stronger sense of building bridges and positive encouragement while the core of the message remains the same. And I think that is achieved by getting rid of absolutes, and a better choice of words.
Compare that to the original sentence. “Niche” doesn’t necessarily convey a negative meaning, but then it is followed by “if you want to have real impact […]“, implying that niche equals unsubstantial impact. “Your time is better invested” then threateningly assumes the form of “stop wasting your time“. Not only it seems to be an aggressive way of writing these ideas, but it also seems to put down the efforts of contributors who spent time crafting extensions that help the community.
It burns bridges instead of building them.
The “traditional desktop” is dead, and it’s not coming back. Instead of trying to bring back old concepts like menu bars or status icons, invent something better from first principles.
These are certainly bold statements! However, it raises some questions:
- Is the “traditional desktop” really dead? I’m sure the people using Windows and Mac outnumber people using GNOME by many degrees of exponentiality. Or perhaps was Tobias only thinking about the experience side of things?
- Is it really not coming back?
- Are old concepts necessarily bad? Do they need to be reinvented?
I am no designer or user experience expert, evidently. I’m just playing the devil’s advocate here. These are unsubstantiated claims that do sound almost dogmatic to me. In addition to that, saying that a tradition is dead cannot be taken lightly. It is, in essence, a powerful statement, and I think it’s more generally productive to avoid it. Perhaps it could have been written in a less threatening and presumptuous way?
Let’s try and repeat the rewriting exercise above. Here’s my take:
GNOME’s focus on getting out of the way, and creating meaningful and accessible interfaces, conflicted with many elements that compose what we call the “traditional desktop”, such as menus and status icons. We set ourselves on a hard challenge to invent better patterns and improve the experience of using the desktop, and we feel like we are progressing the state of the art of the desktop experience.
My goal was to be less confrontational, and evoke the pride of working on such a hard problem with a significant degree of success. What do you, reader, think of this rewritten sentence?
To conclude this piece, I’m honestly upset with the original article that was discussed here. Over the past few years, I and many others have been working hard to build bridges with the extended community, specially extension developers, and it’s been extremely successful. I can clearly see more people coming together, helping the platform grow, and engaging and improving GNOME. I personally reviewed the first contribution of more than a dozen new contributors.
It seems to me that this article comes in the opposite direction: it puts down people for their contributions; it generates negativity towards certain groups of the extended GNOME community; it induces readers into thinking that it is written on the behalf of the GNOME community when it is not.
Now that it is already out there, there is little I can do. I’m writing this hoping that it can undo some of the damage that I think the original article did. And again: despite using “we” and “us” extensively, the article is only the Tobias’ personal interpretation of the community.
20 thoughts on “On Building Bridges”
Boy you hit the nail on the head here. Writing in the passive-aggressive way Tobias writes just encourages people like me who disagree with him to also become confrontational. I genuinely use and need certain GNOME extensions which make me more productive but which would never be accepted into core GNOME. And while I get that themes are just optional, is it really that hard to have a theming API? Or an extension API? Even if it changes it would be more stable than monkey patching. But that’s all that’s available because it’s a passive-aggressive way of saying they don’t like it.
At this point, any kind of API is limiting the possibilities.
Currently extensions are simply patches to GNOME Shell that are hot-applied, and thus are literally capable of modifying the ENTIRE shell without limits. Creating an API will only limit the possibilities for developers, and possibly create discomfort for some.
Regarding custom stylesheets… that’s a much more complicated problem. Thinking realistically, in my opinion, an API for custom colors is the most that could be achieved. Still I don’t know if it’s something they’d want to implement at some point. The problem is that, as GTK uses CSS to define its appearance, applications become highly dependent on the system stylesheet, and if you change it just like that, everything that makes use of custom styles or even custom widgets is broken. As you’ll notice, it’s still a major downgrade from what “GTK theme” developers are doing today.
Uh, no, for extension developers.
Did you read my answer? Currently, extension developers have complete freedom when developing, because they can take any part of the shell code and modify it. If you create an API, you cut them off from that freedom and you stick them to whatever the API says, which for many will be a shame.
Still, if you really want to push the idea of having a stable API, then you should approach #extensions:gnome.org and chat it up with the rest of the extension developers 🙂
Actually yes, it is incredibly hard to have a theming API, which is why not a single mainstream platform has theming on the level of GTK CSS stylesheet. (outside of dark mode, accent colors, and accessibility features) For such an API to work correctly, it would have to be either very limited or incredibly broad.
Furthermore, the problem with theming isn’t as much as a technical, but the expectation that applications should have their styling overriden by the system.
An “Extension API” is also not a weekend project by any means. It would have to be designed – which inherently means some features would have to be excluded from that formal API, it would have to be implemented, and extension devs would have to basically rewrite every extension to utilize such an API.
It might be tempting to say “Just write an API!” but simply formalizing and officially supporting hacks without thinking whether we should even have these or if there’s a better way to do it instead wouldn’t exactly solve everything and might create more problems.
Your article resonated with me, the overall theme of the series I like, but several things just didn’t feel right:
Not even subtly, as a casual Planet Gnome reader, it gave me the impression “this is what “Gnome” thinks.
And the shell extensions thing. Without shell extensions (or something equivalent), I wouldn’t use Gnome. I would use KDE, and grumble a lot. From a non-coder’s point of view, extensions are perfect: they give me the power to add the functionality I want, and not add the stuff I don’t need. I disagree with people who say “it should be part of the shell”. Why? I don’t want unused code on my system. This is (almost) perfect.
Wow, living in an ivory tower much? I personally love the way Gnome does things. I agree with “the philosophy”, but I also live in the real world. I wished I had no status icons, but I have to use legacy apps. So I need the stupid icons. I’m probably not alone.
And last the theming thing. Here I go back and forth. “System-wide theming is a broken idea.” That was a good post, and I see the writers points. But a light / dark switch is something both needed and expected in this day and age. The (coming) Elementary OS implimentation is the best way doing things, from a user’s perspective.
In (not really) short,
agree what you wrote, thanks for your writing (and coding on Gnome TODO),
I agree with you in all your points absolutely. Bridge buildig is essential, in special for open source projects like Gnome.
I agree here; I think Gnome’s on the cusp of interesting desktop design (I have my qualms, echoed by others above, but I respect it) by doing their own thing, but the way some in the community phrase it feels alienating in a “with us or against us” way that makes it less about the design or how it benefits people. It makes people outside of Gnome “inside baseball” feel like an other – doesn’t matter open culturally GUADEC is.
Thank you for writing this post. I think what you write makes perfect sense. When I read that article, I also felt the same way you did, and to be fair it did make me angry.
What made me angry is the lack of nuance, as you say. Nuance is something that is precious and valuable, as it is creative, as opposed to imperative. In a blog post about the community, speaking through diktats is absolutely counterproductive and polarizing.
Was it a provocation? If it was, it once again reinforced the idea that GNOME people live in ivory towers and do not care about you, which is very wrong and toxic. By now, this sad stereotype has become the norm and I think it hurts the GNOME (and opensource) community very much.
Anyway, thank you for writing this and for raising this point.
I presume my previous post was a bit too confrontational towards the issues. I apologize if my wording was unprofessional or even vitriolic, but I’d had that rant bottled up for a while.
I’ll put it simply: There’s a 17 year old issue in Gnome that’s never been resolved (GTK #233/original #141154) because the Developers keep trying to design a “one size fits all” by committee “Universal Solution”, when neither the former nor latter exist. No matter what shall be done, something is going to break someones Spacebar Heater. (XKCD #1172)
This is something that could be solved in minutes with some code reuse or a simple thought process change, and alas it is unresolved for reasons which appear to fall outside of logic and into middle management.
(Example solution: Make Nautilus stub file chooser. Call it Helm. Saves on making new code, can be compartmentalized or made optional.)
XDG desktop portals solve this problem. If apps support the portal it means you don’t have to use the default GTKFileChooser, you can use whatever file chooser you want. So someone could feasibly try to use KDE’s, or even Nautilus as their file chooser without necessarily changing an app itself. There was a post on Reddit r/gnome a month ago about this.
While possible, your easy solution creates a circular dependency (gtk depending on nautilus depending on gtk…) and makes gtk depending basically on the whole gnome stack.
If a problem is 17 years old the solution is probably not so easy.
While that may be, I just wanted to make it clear that there have also been solutions passing them by for 17 years. There are components of other file browsers they could ask nicely to quietly implement or examine to cleanly patch in. Dependency free, even.
Can you imagine a scenario where in the 17 years, various people didn’t chime in along the words of, “Well, why don’t we see how Xfe or Thunar does it?” or “Hey, here’s some new code, wouldn’t “this” work?”
Just this one simple visual design issue should have been closed and resolved with a complete resolution in at most, a month to account for bureaucratic theatrics.
The alternative is to set off some napalm and see who’s willing to rebuild from a zero point. I’m not sure there are too many people willing to start fresh with GTK4.
GNOME is a project and an organization. The software is used by upwards of thousands per day. This isn’t some glorified passion project with two people eking out code.
Let’s imagine that GNOME calls all the coders into a conference and announces a code jam to fix this. Will there be a successful collaboration? How many of them will actually be coders? And how many will be willing to COLLABORATE?
“Tobias” doesn’t seem like the type. And what good is a football team if your midfield hogs the ball or kicks away from his team?
Another thought: A code bounty; A reasonable amount so that everyone involved gets a reasonable compensation, half now half, upon completion with a set time limit for said completion.
Set time would be negotiable with the premise that they “show their work” and give a heads up if they find the issue takes longer to complete.
Your notion of what GNOME is or does does not match reality, and I believe would benefit from reading the other 3 parts of Tobias’ series.
LikeLiked by 1 person
I don’t know what Gnome “is”. That’s part of the overarching communication problem here. If I point a line from Gnome to various projects, would they fall under the same umbrella?
Where does Gnome end, and GTK begin? Should they be treated as one and the same, or as very separate cordoned off buildings with no man’s land between them? Is Adwaita Gnome’s special thing and should be treated as sacrament, or is it like a garden for everyone to sow upon?
There are many things which appear to be inextricably associated with Gnome. So what’s the scope?
You’d be able to derive answers to these questions after reading the other 3 parts of Tobias’ series, I’m sure.
LikeLiked by 1 person
I agree with you! I believe that Tobias’ biggest mistake on this series of article was the selection of words, it felt agressive and it is redacted in a way it feels a message from GNOME and not from a single developer.
A person that has not read the previous articles but this one will enhance their negative perspective on GNOME, the exact same beliefs the series aimed to debunk.
In light of this and more recent events, I have a suggestion to you to avoid similar communications blunders in the future. You could create an official GNOME blog where every post is subject to the same peer review process as code is before it is posted. This is what we do for the Mixxx blog ( https://mixxx.org/news/ ) so we know everyone is on board with the way information is being communicated to the outside world. I think this could avoid situations where contributors with controversial opinions come across as speaking for the whole GNOME community when the community isn’t completely in agreement.
Technologically it works really nicely in our setup because we use a static site generator and Netlify automatically deploys the blog post when it is merged to the website code repository, though you could use whatever technologies you want to implement this.
Thanks for this post, it makes me proud to be a GNOME user! Tobias’ blogpost (and often his comments in general) generally make me angry. Perhaps the community does need provocation, but so far his words seem to have just increased warring and splits rather than moved the community into a positive direction, as far as I can tell…?
I tried to leave the following comment on https://blogs.gnome.org/tbernard/2021/07/13/community-power-4/#comment-19209 but the blog’s comments were closed, which is odd as it let me start typing out the comment in a comment reply box etc…: