7 ms·
Your comment misunderstands the point of some most software. Yes, some open source software (like Red Hat Enterprise Linux) is run by a company and has an expe
by TheDong 6y ago
Your comment misunderstands the point of some most software.
Yes, some open source software (like Red Hat Enterprise Linux) is run by a company and has an expectation of support.
The vast majority of free software, from the GNU tools like gcc to the linux kernel to clang, does not have that expectation.
All free software has a license that lets you fork it (by definition)... and that's where your reasonable expectations should end.
If you think the maintainer isn't doing a good job working on the right issues or maintaining the project, that's not the maintainer's problem. That's your problem. If you have the abilities to fork it and implement those changes yourself (realizing the maintainer does not have to incorporate those changes of course), go for it. If you can't, well, your expectations are totally wrong.
If a maintainer actively looks for "fame" or actively pushes more people to use their software, that does not mean they have to provide support. That does not mean they have to live up to some standard you've made up in your head.
They should make a reasonable attempt to uphold any specific promises they make, but that's about all they owe people, and if they promise to build a feature, then burn out, that's okay too really.
- mlthoughts2018 6y ago> “ If you think the maintainer isn't doing a good job working on the right issues or maintaining the project, that's not the maintainer's problem. That's your problem.” This is backwards. The maintainer is expecting attention and users. By alerting the maintainer to issues, I would be helping them (using my own extra effort, eg bug reports, feature requests). The nuclear option for a user is to just throw their hands up, not even try to lobby the maintainer to make better choices, and quit using the project. The nuclear option for a maintainer is to completely ignore the user base whose attention they need and whose efforts on bug reports or whose frustrations give them free labor to understand their projects fault points and fix them, and instead say, “you’re not paying me with money, only with attention, time and effort, so I owe you nothing” (as if owing was any part of any of it) and ignore their feedback. Either side can go for the nuclear option. But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports, etc. before “going nuclear” and gainsaying everything with “you don’t pay me in the form of currency so I owe you nothing.”
- mmmrk 6y ago> The maintainer is expecting attention and users Do they? The projects I maintain I do so for myself and work. > By alerting the maintainer to issues, I would be helping them Do you? I need to weight the time and effort to understand your issue against my potential gain from it. > The nuclear option for a maintainer is to completely ignore the user base whose attention they need Odd, I don't need attention for my projects. > as if owing was any part of any of it You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor". > But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)
- mlthoughts2018 6y ago> Do they? Overwhelmingly yes. > Do you? Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features. Users have to weigh up their own time and priorities too, so for users to give up their free time to put work into documenting issues / feature needs, that is a bunch of free labor given to the project maintainer. Any maintainer who sees bug reports or feature requests as a time drain instead of free product research is completely wrong. > Odd, I don't need attention for my projects. Then why are they open source? > You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor". No, I never said anything like that, in fact I said the opposite. Maintainers are perfectly free to ignore users if they want. It would just mean it’s reasonable for users to see that as a shitty owner and express frustration about it. Maintainers don’t owe anyone anything, and I never said otherwise. But it’s perfectly legitimate for users to express frustration over badly managed FOSS projects, neglected feature requests, etc. In other words, “if you don’t like it, leave” is unjustified, and users should express frustration. It doesn’t mean a maintainer is going to listen, but that’s beside the point. The original comment I replied to proposed that users are ingrates or should possibly be banned if they “complain” - that if they have a problem, it’s not the maintainer’s problem. These are just wrong attitudes. Maintainers aren’t obliged to do anything. Irrelevant. Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.” > If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :) No, this is up to the users to decide, as they actually use the project. Users decide if filing a bug report, asking for a feature, or pushing back on a roadmap is needed, because it stems from the problems they experience as users. Of course the maintainer doesn’t have to care or even read it, but that would be horrendously undiplomatic of the maintainer, and users would have every justification to express frustration about it.