3 ms·

If you really want a feature, I agree with you. You shouldn't have to learn how to code to prevent a feature that many people are using from being removed. Reg

If you really want a feature, I agree with you. You shouldn't have to learn how to code to prevent a feature that many people are using from being removed. Regardless, given the attitude shown in the bug, do you really believe if somebody provided a patch, it would be accepted? And do you really expect people to become core maintainers in every project they want features to not be removed from? That sounds ridiculous to me. Gnome can decide whether to have a feature or not. But, as a very popular open source project, they should respect their users enough to gather their input and take it into consideration. At the very least, they should communicate well enough that users can make informed decisions before a feature is yanked from under them.

cbhl 13y ago
To be honest, I don't believe that if someone provided a patch, it would be accepted. I also don't "expect people to become core maintainers in every project they want features to not be removed from". But I also believe it is crazy to believe that simply using a piece of free software gives you any right to dictate the feature set of that software. One, the freedoms granted by free software include the right to modify and redistribute code. If you want to re-add a feature, fork the code. If the community sides with you, you will become the de-facto upstream. Two, just because a user is vocal doesn't mean his/her incentives align with those of the developer. If the developer is working in his/her own time, he might prioritize things that are important to him, like, say, porting the terminal emulator to Wayland, or keeping only features s/he cares about. Or, perhaps the developer is being influenced by an external body or benevolent dictator. I also find your "users can make informed decisions before a feature is yanked from under them" comment confusing. Presumably a user could always downgrade the package, or use source control to build an older version, if the missing feature is indeed mission-critical. If this risk is really unacceptable, they can make an informed decision to not upgrade, or to purchase a support contract. It seems to me that the developer's communication skills are reasonably adequate, so I don't object to continuing to use gnome-terminal. I assume that the people who approved them becoming a developer would feel that way too.

cbhl 13y ago

To be honest, I don't believe that if someone provided a patch, it would be accepted. I also don't "expect people to become core maintainers in every project they want features to not be removed from". But I also believe it is crazy to believe that simply using a piece of free software gives you any right to dictate the feature set of that software. One, the freedoms granted by free software include the right to modify and redistribute code. If you want to re-add a feature, fork the code. If the community sides with you, you will become the de-facto upstream. Two, just because a user is vocal doesn't mean his/her incentives align with those of the developer. If the developer is working in his/her own time, he might prioritize things that are important to him, like, say, porting the terminal emulator to Wayland, or keeping only features s/he cares about. Or, perhaps the developer is being influenced by an external body or benevolent dictator. I also find your "users can make informed decisions before a feature is yanked from under them" comment confusing. Presumably a user could always downgrade the package, or use source control to build an older version, if the missing feature is indeed mission-critical. If this risk is really unacceptable, they can make an informed decision to not upgrade, or to purchase a support contract. It seems to me that the developer's communication skills are reasonably adequate, so I don't object to continuing to use gnome-terminal. I assume that the people who approved them becoming a developer would feel that way too.