[plaguepilled]

A preface: I use GNOME and KDE on separate devices. I have tried i3 and intend to return to it when graced with more time to customise it. Importantly, I used GNOME before GTK3 happened.

I mention the above as preface because I see these kinds of posts on this website a lot and they are very misleading, and I believe I have the credentials to explain why.

If you skim the original article you could be forgiven for thinking that it is a well researched and justified piece of writing, but I would like to challenge that. In particular, I note that a lot of 'evidence' for the claims of GTKs downfall are hinged in the author's preexisting expectations (and bizarre tangents - who gives a shit about title bars one way or another in a conversation about software maintenance? Scope pls).

One very revealing assumption by the author is the idea that a major release of a community project such as GTK3 should be free of bugs. This seems very obvious to an end user. 'Of course a major release should be stable! What are you saying? I need my servers to be reliable so I can feed my kids! Not everyone lives in fantasy land like you, plaguepilled!'

But there are actually two assumptions being made here. The first is that major releases of FOSS should be free of bugs and not corrected with time, and the second assumption is that this is no harder to accomplish than for a commercial entity.

However, crucially, the open source software community has had a huge shortage of maintainers for at least a decade now. Look up your favourite utility, then look up the team supporting it: often it is one person who is very, very over it. This can contribute to the phenomenon of fixes that come after the major release, not with it.

In fact, this single fact can explain why major projects that 'weren't broken' seemingly 'choose' to self sabotage. The GNOME team are not stupid. They are heavily under-resourced. The same can be said for KDE and even the Linux kernel teams. If that bothers you, it is far more productive to actually contribute your time to fixing the issue than simply describing it while waxing lyrical about how all these modern devs have simply 'lost the way'.

But I am here to contend that the idea of flawless FOSS is itself bizarre. Wealth inequality is a major issue in 2022 and proposing that the existing body of skilled software engineers should provide enterprise level software, consistently, without pay, is insane. If you care about software support and are not paying, and you do not yourself write FOSS software, you are at best a hypocrite, and at worst attempting to exploit people.

I am a fan of FOSS and want it to be better, but this article is not the way to that future.

[lelanthran]

> If that bothers you, it is far more productive to actually contribute your time to fixing the issue than simply describing it while waxing lyrical about how all these modern devs have simply 'lost the way'.

I agree with that sentiment in principle. In fact, I advocate the same myself.

However, playing the devils advocate, all an individual non-core developer can do is try to smooth out the rough edges.

If the complaint is "you removed this option", it doesn't matter if the complainer provides a patch to put it back - the powers in charge of that project already have the code (it was there before they removed it, after all), so providing a patch to add it back in is pointless.

The non-bug complaints in general (still devils advocate) are not that the software is missing a feature, it's that the direction it is going (or has gone) in is alienating the existing users.

[plaguepilled]

Thanks for responding. I can see your angle but I don't think I agree. I'll try to respond in good faith but let me know if I've made a misapprehension.

In regards to the topic of user base alienation: I do think it is an important metric to keep track of, but whether it should be prioritised is contextual. In the case of GNOME, they have frequently made a point that accessibility is a large focus for them. Accessibility is not the same as making their core user base familiar with their software.

Said another way, I believe that making an argument that even with their limited resources, GNOME are not sufficiently servicing their users is ignoring the purpose they wish to serve. Their goal is not to minimise change - that is more in line with xfce, i3, or even DWM.

In contrast, I believe attending to existing users is important for KDE, because their core goals are centred on choice. Therefore, it would be antithetical to their goals to restrict choice.

To summarise my angle, alienation is sometimes important, but not here. It would be more expected if GNOME were better staffed (and so extended scope and service guarantees), which brings me to my next point.

You made an interesting point about how a cranky individual that lamented the loss of a feature would not be able to 'change' the upstream attitude. This is true, but it slightly misses what I am trying to say. I am not advocating for the submission of singular patches in response to singular grievances.

Instead, what I am suggesting is that people who are interested in the survival of projects become involved with the long-term (or even just the mid term) running of the project.

This will not only give them greater influence in how the software is written, it will also mean that, as I alluded to before, scope and service can expand.

Being involved with a project also means you will become better informed on how the code base operates. With that knowledge, you could more easily maintain a fork of the project that supports your chosen feature.

Is that a lot of work? Yes - which returns to my original point. Regular contribution is a huge difference that unhappy people should earnestly consider. It may require contributors to go along with decisions they don't like, but with time comes practice, then experience, then trust, then influence.

Or, in a sentence: you can improve these projects in the way you see fit if you take the steps required.

[RedShift1]

> Or, in a sentence: you can improve these projects in the way you see fit if you take the steps required.

Well yes, but actually, no. If upstream denies or ignores your pull requests, you're dead in the water. Just try and make a pull request to bring back a feature that Gnome or GTK dumped a few years prior.

[throwaway82652]

> If upstream denies or ignores your pull requests, you're dead in the water

No, this is very wrong. You can maintain a fork. You can do that while maintaining positive relations with them to see if eventually they do decide to take the PR.

Of course nobody wants to do that because it's a lot of work. So what's really happening here is you're trying to play hot potato with a feature that nobody wants to maintain, not even you. I sympathize, I also have patches sitting around in various projects that went nowhere. There just isn't enough time in the day for unpaid volunteers to look at every patch.

[plaguepilled]

Thanks for commenting: I sort of agree, as this sort of feeds into my point.

The 'meta-argument' I was making is that delivery requires coordination, and the more you deliver the more work it is.

That's all well and good, but on a singular level I agree that simply throwing a patch request without doing the due diligence won't get you far.

[lelanthran]

> Or, in a sentence: you can improve these projects in the way you see fit if you take the steps required.

When the one and only step is "hard fork the project", that's not really an easy one.