> I think it’s a mistake to broadly think of open source maintainers as vendors of free software, whose “job” is to make their users happy.
I can think of prominent projects that try to position themselves as "the one true FREE X and everyone should use it" - certainly implicitly, and certainly in the tone of their outreach. I think it's a mistake for open source projects in that mould to think of their users as ungrateful sods.
> Complaining about missing features is like coming into someone’s house and criticising their furniture.
I mean... yes? If you've invited me into your house and then decided that the sofa needs to move to its true home half-way up the stairs while I'm trying to climb them to get to the bathroom, then yes, that's your call, and yes, I'm going to point out that it's both brain-dead idiotic as a general idea and deeply inconvenient not just to me personally but to anyone else you might have over for dinner. You might, on hearing that feedback, decide that the living room is a better place for it after all. You might decide that the sofa is actually more comfortable at a 45 degree angle, and that nobody should be using the bathroom anyway, including you. I leave it to you to decide what the better outcome here would be.
> Maintainers can do what they want.
As I said. It doesn't mean that dismissing people who functionally can only contribute feedback from their own experiences is a smart move.
> The most important button on GitHub isn’t “create issue”. It’s “fork”. Use it to fix your own problems.
Did you miss the bit where "users" and "potential developers" doesn't overlap much? I can think of one project where I'm certainly capable of doing this - I've contributed the odd patch in the past - but keeping pace with the rate of change in the underlying project is completely impossible given the time available. And that includes rate of creation of new things to fix, so it's not just merge issues. That takes me out of the pool of "potential developers". Fundamentally it's unreasonable to expect people to keep up with major projects where there are several people employed to work on it full-time, especially where there are multiple projects this could apply to that I might need to track. That doesn't put requirements on the upstream projects other than not to gaslight users into feeling bad that they can't do this.
> When “users” and “potential developers” don’t have overlap, the developers often feel pressure to act as unpaid customer support reps.
The problem is often not the developers themselves. Successful projects attract hangers-on with an itchy defend-the-project-from-all-comers trigger finger. Now they aren't contributing to the meat of the project directly either, but because they have a self-identity tightly wound with the project they appear to perform a useful function in reducing noise and are tolerated in the community. The problem is that they reject at least as much signal, and anyone whose first interaction with the community is a supercilious dismissal from one of these types is just going to back away and never return.