upvote

points

by latexr13 hours ago |
comments
upvoteby carlosjobim1 hours ago|
next
[-]
> 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.

reply
upvoteby predkambrij6 minutes ago|
parent|
[-]
My favourite is the advice I read from personal MBA. You send them to your competition :)
reply
upvoteby 11 hours ago|
prev|
next
[-]
deleted
reply
upvoteby DANmode13 hours ago|
prev|
[-]
> it’s much simpler to drive a hard line.

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

reply
upvoteby latexr13 hours ago|
parent|
[-]
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.

reply
upvoteby DANmode11 hours ago|
parent|
[-]
> 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..

reply
upvoteby hdgvhicv7 hours ago|
parent|
[-]
Why would you have to “review a pr or issue”?

You can choose to

Or you can choose to ignore them

reply
upvoteby DANmode7 hours ago|
parent|
[-]
All of them?

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

Are we talking about the same thing?

reply
upvoteby seba_dos15 hours ago|
parent|
[-]
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.
reply
upvoteby josephg4 hours ago|
parent|
next
[-]
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.

reply
upvoteby DANmode5 hours ago|
parent|
prev|
[-]
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.

reply
upvoteby seba_dos14 hours ago|
parent|
[-]
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.
reply
upvoteby DANmode4 hours ago|
parent|
[-]
> depending on how they behave

So, reviewing them.

Which takes time/focus.

reply
upvoteby seba_dos14 hours ago|
parent|
[-]
So don't do it when you don't want to.
reply