The amount of breaking changes in GNOME have traditionally been to a meme-worthy level, so I’m not sure what to make of this.
A diminishing number of veterans is doing an increasing share of the work.
Although recruitment is stable, newcomers don’t seem to be hitting their stride in terms of commits.
So the same people that used to experiment and change everything all the time now don’t do this anymore?
I think there’s a number of different aspects to this – since the introduction of GNOME 3.0, the project as a whole has become more consolidated around the idea of a consistent desktop environment, rather than, say, a desktop shell plus loose collection of apps, as GNOME 2.x was. This idea is driven all the way from how the Design Team handles everything from the HIG, the design of core parts such as GNOME Shell itself, down to the minutae of how “core” GNOME applications are maintained (there was some recent drama around Gedit).
That is to say, the scope of the project has increased dramatically, while autonomy has, in some ways, diminished. This has allowed for an increase in the rate of experimentation and iteration, especially around the UX of the Shell itself (which has changed quite a bit over the years, compared to GNOME 2.x). This has also led to issues with compatibility, mostly around GNOME Shell extensions (that I’m aware of, anyways), that has led to perhaps unnecessary frustration on the part of external contributors.
As a bystander and long-time user of GNOME, I think the situation here has led to a marked increase in quality of both core applications and the ecosystem as a whole – usable GUI applications that actually meshed well with the rest of the system, whatever that means, were pretty rare back in the day. Unfortunately, it also means the barrier to entry is higher for developers, especially if one is looking to make some sort of outstanding contribution.
That was a fascinating if somewhat depressing read. I keep considering dipping my toes more in the GNOME world but some of the issues raised there kind of remind me why I don’t.
I read through the thread, and other than some (admittedly abrasive) egos on both sides, I didn’t see much that was cause to be sad. What part of the interaction could have gone better, or were the abrasive egos the issue?
I don’t know what soc was referring to, but what stuck with me was when Gnome went to the bug tracker of Transmission (a popular bittorrent client) and opened a bug asking them to remove support for notification area icons, because they would not be displayed in gnome 3, so there was no need to keep them around:
Transmission has an option in the Desktop tab of the preferences to “Show Transmission icon in the notification area”. This should probably be removed.
In response, it was brought up that removing this would only benefit gnome 3 users and would be removing useful functionality for users of gnome shell, unity, and XFCE - on top of the fact that GTK had made many breaking changes to this API in the past as well, requiring many compile-time flags and different distributions. The response was:
I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I’m sorry that this is the case but it wasn’t GNOME’s fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.
It is my hope that you are a GNOME app
Thanks for bringing this issue up. I had never heard of this, but it seems like the Transmission/Gnome3 thing was a kerfuffle indeed.
I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I’m sorry that this is the case but it wasn’t GNOME’s fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry. It is my hope that you are a GNOME app
Indeed, out of context that feels tactless and unsympathetic. But let’s look at the previous comment in the chain [1]:
So now we can have three builds of Transmission that decide at compile time whether to use AppIndicator?, GtkStatusIcon?, or nothing at all, over such a stupid feature?
Removing it altogether, as you suggest, will hurt XFCE users.
I wish GNOME, Canonical, and everyone else involved would settle on one consistent API for this and stop fucking the app developers over.
In order for this ticket to move forward, I’d like you to tell me what change should be made to Transmission that will make it work properly, out of the box, on GNOME Shell, Unity, and XFCE.
In that light, we have to ask, what should Gnome do? Should Gnome consult other DEs before shipping its features? Then the Gnome project loses its autonomy. Should Transmission conform to the whims of the 3 DEs? Then Transmission loses its autonomy. The problem is, each of these are independent projects with different users, goals, and ideas. Gnome does not want to be beholden to Ubuntu/Unity, XFCE does not want to be beholden to Gnome, and Transmission does not want to have to dance around 3 DEs, in which case, who budges? Why should it be Gnome in this case? If anything, this thread just shows why “worse is better” is the eventual shakeout of loose coupling in the open source world; it’s because the lowest common denominator is what wins when you have multiple actors with only occasionally concordant desires and goals.
And remember, if the authors of Transmission felt that this change in Gnome was not supporting, they could have simply closed the bug and not worked on it. In the Gedit case linked above, Gedit is considered part of “Gnome core” and so Gnome feels greater pressure to make it fall in line, but Transmission could just ignore this change in API and wait for Gnome3 to land and then make the changes gradually or not at all without much pushback.
That was a long time ago – it still gets brought up because, while it was a long time ago, the Gnome project still regularly treats other developers, and users, with condescension and snark.
XFCE may not be the most famous project but I find it really hard to believe the person who posted that didn’t know what it was or what it did. Even assuming it were so, when a developer is voicing concerns about their users’ environment, you can’t just wave your hand and make them go away. Just because you don’t know what something is or does doesn’t make it go away for everyone else.
Should Gnome consult other DEs before shipping its features? Then the Gnome project loses its autonomy. Should Transmission conform to the whims of the 3 DEs? Then Transmission loses its autonomy
That was way too long ago for me to remember the technical details of that discussion, status icons and systrays have always been a bit of tarpit on Linux DEs, but as far as I recall, a third option – consult with application developers – would’ve likely helped…
If, for whatever reason, you come up with your own API or your own way of doing something, that’s great. But if you want other people to start using it, opening a bug asking for the removal of an application feature just because that feature doesn’t really work with your new thing – even though it works everywhere else, and it worked fine with the API you’re deprecating! – is probably not the most elegant way to go about it.
Unlike a lot of people here, I think Gnome is doing interesting things (certainly more than “Windows 98 stomping on a human face, forever”), and enable others to do so too, but…
It feels like they’re on the cusp of achieving some great innovation of holistic vision, but they aren’t quite there yet. Lots of things like the applications that feel Gnome native aren’t in sufficient qualities or complexities. Maybe this is hard to achieve when don’t control as much of the platform as possible, hence why Gnome wants things like “is your application a Gnome application?”, Flatpak, Wayland giving the compositor more control, etc.
The outlook of designers in the Gnome project looks paternalistic. This doesn’t really mesh with Free Software types, hence why that type of people don’t like that. I wonder if design is an inherently paternalistic/dictatorial field anyways, which might explain why there are so few designers in FLOSS.
I really wish the author would have made a CSV of the data (or published the Sqlite DB they obtained by dumping the data themselves.) I’m much more comfy in Python (and to some extent Julia) for data analysis, and I’d love to throw an AR model at this and see what we can learn. Of course, here I am, demanding more work for free from an already FOSS contributor ;)
The amount of breaking changes in GNOME have traditionally been to a meme-worthy level, so I’m not sure what to make of this.
So the same people that used to experiment and change everything all the time now don’t do this anymore?
I think there’s a number of different aspects to this – since the introduction of GNOME 3.0, the project as a whole has become more consolidated around the idea of a consistent desktop environment, rather than, say, a desktop shell plus loose collection of apps, as GNOME 2.x was. This idea is driven all the way from how the Design Team handles everything from the HIG, the design of core parts such as GNOME Shell itself, down to the minutae of how “core” GNOME applications are maintained (there was some recent drama around Gedit).
That is to say, the scope of the project has increased dramatically, while autonomy has, in some ways, diminished. This has allowed for an increase in the rate of experimentation and iteration, especially around the UX of the Shell itself (which has changed quite a bit over the years, compared to GNOME 2.x). This has also led to issues with compatibility, mostly around GNOME Shell extensions (that I’m aware of, anyways), that has led to perhaps unnecessary frustration on the part of external contributors.
As a bystander and long-time user of GNOME, I think the situation here has led to a marked increase in quality of both core applications and the ecosystem as a whole – usable GUI applications that actually meshed well with the rest of the system, whatever that means, were pretty rare back in the day. Unfortunately, it also means the barrier to entry is higher for developers, especially if one is looking to make some sort of outstanding contribution.
That was a fascinating if somewhat depressing read. I keep considering dipping my toes more in the GNOME world but some of the issues raised there kind of remind me why I don’t.
I read through the thread, and other than some (admittedly abrasive) egos on both sides, I didn’t see much that was cause to be sad. What part of the interaction could have gone better, or were the abrasive egos the issue?
Gnome is certainly a project I would never want to get involved in, based on the people alone.
Could you elaborate? I’ve never really looked, but am curious.
I don’t know what soc was referring to, but what stuck with me was when Gnome went to the bug tracker of Transmission (a popular bittorrent client) and opened a bug asking them to remove support for notification area icons, because they would not be displayed in gnome 3, so there was no need to keep them around:
In response, it was brought up that removing this would only benefit gnome 3 users and would be removing useful functionality for users of gnome shell, unity, and XFCE - on top of the fact that GTK had made many breaking changes to this API in the past as well, requiring many compile-time flags and different distributions. The response was:
Thanks for bringing this issue up. I had never heard of this, but it seems like the Transmission/Gnome3 thing was a kerfuffle indeed.
Indeed, out of context that feels tactless and unsympathetic. But let’s look at the previous comment in the chain [1]:
In that light, we have to ask, what should Gnome do? Should Gnome consult other DEs before shipping its features? Then the Gnome project loses its autonomy. Should Transmission conform to the whims of the 3 DEs? Then Transmission loses its autonomy. The problem is, each of these are independent projects with different users, goals, and ideas. Gnome does not want to be beholden to Ubuntu/Unity, XFCE does not want to be beholden to Gnome, and Transmission does not want to have to dance around 3 DEs, in which case, who budges? Why should it be Gnome in this case? If anything, this thread just shows why “worse is better” is the eventual shakeout of loose coupling in the open source world; it’s because the lowest common denominator is what wins when you have multiple actors with only occasionally concordant desires and goals.
And remember, if the authors of Transmission felt that this change in Gnome was not supporting, they could have simply closed the bug and not worked on it. In the Gedit case linked above, Gedit is considered part of “Gnome core” and so Gnome feels greater pressure to make it fall in line, but Transmission could just ignore this change in API and wait for Gnome3 to land and then make the changes gradually or not at all without much pushback.
[1]: https://trac.transmissionbt.com/ticket/3685 for the entire contents of the thread
That was a long time ago – it still gets brought up because, while it was a long time ago, the Gnome project still regularly treats other developers, and users, with condescension and snark.
XFCE may not be the most famous project but I find it really hard to believe the person who posted that didn’t know what it was or what it did. Even assuming it were so, when a developer is voicing concerns about their users’ environment, you can’t just wave your hand and make them go away. Just because you don’t know what something is or does doesn’t make it go away for everyone else.
That was way too long ago for me to remember the technical details of that discussion, status icons and systrays have always been a bit of tarpit on Linux DEs, but as far as I recall, a third option – consult with application developers – would’ve likely helped…
If, for whatever reason, you come up with your own API or your own way of doing something, that’s great. But if you want other people to start using it, opening a bug asking for the removal of an application feature just because that feature doesn’t really work with your new thing – even though it works everywhere else, and it worked fine with the API you’re deprecating! – is probably not the most elegant way to go about it.
+1000000
-5 me-too?? C’mon bois!!
Unlike a lot of people here, I think Gnome is doing interesting things (certainly more than “Windows 98 stomping on a human face, forever”), and enable others to do so too, but…
I’m a daily user of GNOME and Fedora, and I like Red Hat, but I wonder if we shouldn’t be worried that half of the contributions come from Red Hat.
I really wish the author would have made a CSV of the data (or published the Sqlite DB they obtained by dumping the data themselves.) I’m much more comfy in Python (and to some extent Julia) for data analysis, and I’d love to throw an AR model at this and see what we can learn. Of course, here I am, demanding more work for free from an already FOSS contributor ;)
The analysis in the comments adds better context to the post.
Meta: the flickering favicon on the page is madness