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.
> “ 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.”
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 :)
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.
> Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features
This is a bizarre viewpoint. The creator/developers of an open source project usually has a far better understanding of the bugs, missing features, etc of their project. They've spent months to years thinking about it. They understand the technical restrictions that result in various tradeoffs. Users making feature requests rarely have the full picture or understand the technical tradeoffs at play, unless they implement or fix their issue themselves.
Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc.
Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to.
In addition, if a user feels like they're spending enough time to "put work into documenting issues/features" that they're net losing time after the savings of being able to use the project (vs implement it all themselves), then they should neither file issues nor use the project at all.
> Then why are they open source?
Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about.
In fact, if you listen to maintainers, the vast majority don't want that crap.
Projects can be open source because "information wants to be free", or "I want my users to be able to fork it, they have rights", or "I hope someone learns from this", or "I want people to contribute code (but not dumb issues)".
For the most part, an open source project wants attention from a group of people - people who find the project useful already, and who are willing to not incur a maintenance burden.
Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain.
> Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.”
No, it's not more reasonable for users to complain unless the maintainer asks users to complain. If the maintainer has a contributing.md or a page on their site that says something like "please send me poorly thought out feature requests, hate mail, and entitled bullshit", then yes, users can do that.
Otherwise, the user should indeed take it or leave it. If the maintainer has a contributing.md saying "I might accept PRs", the user can absolutely discuss implementing a feature with the maintainer.
The default, if there's no documentation about expectations, is that it is 100% take it or leave it.
You seem to think that all open source projects are like RHEL, where a huge company runs it and all users pay thousands of dollars for support.
In that specific case, yes it's totally fine for users to send support emails describing issues they ran into.
The majority of oss projects are not that. The majority are some dude who hacked something out and hopes other people like it too. If other people like it, cool. That does not give other people a reasonable right to expect that person to actually do any serious maintainership of it.
That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something).
I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint?
Your viewpoint seems quite foreign to the maintainers I've met, and I'm curious what has shaped it.
My perspective has largely been shaped by maintaining OSS projects, talking to other maintainers, and reading secondary sources on the free software ethos.
> The creator/developers of an open source project usually has a far better understanding of the bugs, missing features, etc of their project. They've spent months to years thinking about it.
This is a bizarre point of view. The maintainer has only spent time thinking about it from the point of view of their lone preferences and opinion. Users come from all walks of life and are in the weeds with many use cases or blocking issues or bugs that the maintainer would never realize or think of if it weren’t for the free effort gifted by users reporting bugs and requesting features. It’s far more bizarre for you to assert maintainers are in the best position to judge over and above users.
> Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc.
This is exactly backwards.
> Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to.
No they should lobby the maintainer to prioritize it for the existing project. Forking and doing it themselves should be an extremely uncommon fallback or hobbyist special interest, not at all a default.
> Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about.
> In fact, if you listen to maintainers, the vast majority don't want that crap.
You seem to have some mix of a superiority complex / poor attitude towards users of OSS. It sounds extremely obvious that you aren’t suited to be a FOSS maintainer if you harbor these biases against users. Have you considered taking your projects down? It might be a benefit for all parties to not have to experience this anger / belittlement issue from you.
> Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain.
Nope, the internet doesn’t work that way. If you want to post your software project for passive consumption, people absolutely have every right to complain about it. You don’t have to listen but they absolutely have full justification to provide their take on the thing you published.
> That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something).
It has nothing to do with being “entitled” to anything, for either party (users or maintainers). And this doesn’t matter if the maintainer is RHEL or some random guy that can spend max one hour a month on a project.
> I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint?
Given the vitriol in your comments and especially the really abusive language you use to sweep the entire class of FOSS users under an umbrella of being completely stupid and dimwitted compared to maintainers, I do not for one second believe you genuinely want to engage in discussion or debate whatsoever. If I shared my own personal experiences managing FOSS projects for two past employers, I think you will just find excuses to unfairly dismiss it, make sniping replies and take various pieces out of context as you have so far.
I agree we probably won't get anywhere constructive and your decision is respectable. However, I disagree that you are being interpreted negatively. You are being negative - it's not an interpretation, it is just the unquestionable property of your communication and the substance of your comments, especially insulting towards users of FOSS projects. There's no matter of interpretation, it just is negative.
Likewise, I don't believe I am speaking negatively or uncharitably at all. I think I have responded in good faith and with due self-reflection and that my comments are fair reflections of what you are communicating. Looking back, I don't see anything I'd change or any place where I wasn't engaging with polite, good faith responses to your negative comments.
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.