|
|
|
|
|
|
by adzicg
3583 days ago
|
|
|
> The time isn't useful just because it's volunteered. It has to be both volunteered and directed at effort useful depends on the target. something might be useful to you but not to other people. big part of successful product management is deciding on good market segments. as a casual user of a tool, you might not be in a segment that the project maintainers care a lot. annoying maintainers won't help at all if that is the case. learning about the code and fixing it will. |
|
|
When the project maintainers fail to prioritize the things that huge streams of users are +1-ing, I think that's a strong signal that the project maintainers just want to poke around their preferred aspects of the project, rather than address actual needs.
In that sense, they aren't actually "volunteering" time -- they are receiving the compensation of their satisfaction of poking around only the parts of the code they like. They aren't doing it "for" anyone but themselves, and it's this idea that all open source contributions are "volunteered" and are given infinity free passes from criticisms about prioritization that causes a lot of the trouble.
In order for the time to be "volunteered" it has to be directed at things that others are benefiting from. If few are benefiting and it's just a personal quirk, curiosity, or interest of some random developer -- who wants to tune out the +1 noise of people asking for things they actually need -- then that developer deserves zero praise or kudos for "volunteering" time or anything. There's no sense in which it's generous to fail to support aspects of a project that people need in order to instead support aspects of a project you personally happen to like.
I think a lot of the +1 streams are about this kind of tension. Developers saying, "leave me alone ... I'm already doing this 'for free' -- what more do you want." And then cranky users saying in reply, "But you're not doing anything 'for free' -- you're picking the parts that bring you personal satisfaction and then trying to argue that those are higher priority than the things project users rely on and need."