> 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.
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.
> 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.
> 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.
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.