I’ve also done both, and I found both kinds of users in both situations. There have been cases on the commercial front where I just felt like giving customers their money back, even after years of having used the software, and told them to not come back. There’s a lot of entitlement and craziness from paying users too, and those are harder to ignore. With open-source it’s much simpler to drive a hard line.

My “favourites” are the ones threatening to abandon the tool, despite having never made a single positive contribution. On open-source that’s an easy laugh and a “good riddance”. On commercial cases it’s more frustrating and nuanced.

I disagree willingness to pay is that meaningful of a filter, in the cases I experienced. And it’s getting worse; many people are getting too impatient and act like everyone works for them specifically and only their needs matter.

> There’s a lot of entitlement and craziness from paying users too, and those are harder to ignore.

Somebody paying for your product is very strong signal. You know that such a person represents real world use cases for your product, and that their issues and feature requests are based on real world problems. Otherwise the chances are low that they would be paying for the software.

So helping them with what they want could mean that you've just tipped the scale enough for hundreds or thousands of people to become new customers.

And of course you should give them their money back to get rid of them if they're any kind of headache. Or tell them that their requested feature will be in the next versions, which is a new purchase.

> So helping them with what they want could mean that you've just tipped the scale enough for hundreds or thousands of people to become new customers.

Sure, if the request is reasonable and sensical. I entertain those and even help them formulate the request better if needed. That’s true of both commercial and open-source.

But I’m more talking about the users who demand features. Those who say the tool needs to have whatever idea they just thought of 2 minutes ago, despite no one else ever having asked for it and it not really making sense. Those users who only think of themselves and suggest features which require fundamental changes which would modify the behaviour for everyone, or the feature is in itself contradictory and there’s no way it could work.

My favourite is the advice I read from personal MBA. You send them to your competition :)

[deleted]

> it’s much simpler to drive a hard line.

But driving that line is a cost: to you, your volunteers, or your tokens(?).

There’s no cost to me to stop an entitled disruptive user with zero positive contributions from destabilising the project. No cost to my volunteers either. The opposite is true in both cases; removing that user is a net benefit and I’ve done so in the past specifically to protect the experience of the volunteers.

As for tokens, there have been exactly zero cases where someone has submitted LLM code to one of my repos that has been up to my standards and I have accepted it. Yes, I can say that with certainty. If I wanted LLM code I’d ask for it myself, having an intermediary in that process is worse than useless.

> There’s no cost to me to stop an entitled disruptive user with zero positive contributions from destabilising the project.

Having to spend time reviewing a PR or issue is “no cost”?

I’m not convinced yet.

> As for tokens

I did not mean LLM contributions…I meant using AI tools to automate the reviews of contributions and users you seem to think cost no time or attention, but I do..

Why would you have to “review a pr or issue”?

You can choose to

Or you can choose to ignore them

All of them?

Why are you on a platform open to accepting them in the first place?

Are we talking about the same thing?

Yes, all of them if you want to. It's 100% up to you whether and how you deal with other people and their contributions, and it's completely orthogonal to being FLOSS or using a git hosting.

The central freedom provided by opensource software maintainers is the fork button. Not the “merge pull request” button.

Git hosting provides discoverability and the ability to fork repositories. Everything else is an optional feature.

Then the thread feels a little tangential,

because you don’t have to “drive a hard line”, to do that,

you just draw it once (publish a no PR policy, don’t host on GH, etc),

and you shouldn’t be hearing from users.

That's just one way to do it. Even if you let them send you PRs or whatever, you can still act on them or not depending on how they behave, your available resources, health, mood or just whim. You don't owe anyone anything and "creating a community around a project" is not a goal you have to be striving for regardless of whether you take contributions or provide some user support or not.

> depending on how they behave

So, reviewing them.

Which takes time/focus.

So don't do it when you don't want to.