3 ms·
This is the way with any issue of public importance, which, as a capital-F Free Software project with a lengthy history and many contributors, GIMP has grown in
by mntmoss 7y ago
This is the way with any issue of public importance, which, as a capital-F Free Software project with a lengthy history and many contributors, GIMP has grown into. The software's functionality is commendable, and they have made some strides on UX as well. That makes it worth recommending, but for the parts that hold it back, of which the name is increasingly a major one.
When these issues come up, and there is a perception of gatekeeping behavior, protest is normal. The developers hold the power here. And developer arguments to avoid popular change tend to become more incoherent as the popularity of the software grows, because it positions them as both serving a popular interest(lots of users, open development) and not(private whims trumping popular ones). Developers on prominent products with many users generally are not following their fancy anymore; they are making their career. If they want to sully their career, dying on this hill is a way to do it.
- skybrian 7y agoSeems like at that point volunteering is no longer fun, and if you want people to put up with it, you need to pay them.
- _dps 7y ago> The developers hold the power here. They do not, this is exactly the point of free software. Anyone can fork it and release their fork under a different name. Don't want to do that work? Too bad. Want to force the developers to do it? Now which party is attempting to exercise power? The only thing the developers are doing is refusing to modify their free gift to the community to line up with other people's non-technical priorities. This is not an exercise of power — is it simply reminding people that free software contributors are not indentured servants.
- djsumdog 7y agoExactly. Someone unhappy with the name, but wants to contribute to the product, can fork the project with a different name and start putting all their patches in there. If their features are good, they might get backported to the other project. That person may continue to rebase off the original as well. Eventually you might have two packages in all the major distros and CI that helps keep both trees in sync. That really is the right way forward here. Or ... the person could just make a CI that pulls, applies a single script that renames and rebrands everything, and then rerelease packages. That's all they have to do .. and if it catches on, well then they've made a change without having to bother the original developers at all.