> 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.