You get both the demanding users and the giving users, but the point is, the demanding users don't actually cost your open source repo anything. When it's a website, every user is money out of your pocket.
Demanding users absolutely do cost something -- time and attention at a minimum. Some users will go to great lengths to try to force you to engage with them. An open source repo does not prevent this either in theory or practice.
They actually don't. You can just ignore them. I get that people find them unpleasant. But "finding somebody unpleasant" is different from "someone costs you money."
No you can't, because they report bugs in the same place that all the other people do, they create spam accounts, they concern troll, they divert conversations onto their pet issues, they do everything people have done to irritate other people on the internet for ages. It's very well understood behavior to anyone who has used an internet forum in the past 20 years and also obvious there is no magical way to filter this all out. You're running the project or part of the maintainer team, YOU have to separate the wheat from the chaff, no magical algorithm or "trick" is going to do it for you.
This is before the fun part where, depending on the level of "personality" you're dealing with, you might end up getting a fun weirdo who becomes obsessed with you for a little while and makes life miserable for everyone involved. I know one person who was stalked on GitHub (before they let you ban people from interacting with you, a fairly recent feature) and this person would comment on literally EVERYTHING they did, but only in a "nice" and "helpful" tone. You can't tune that shit out so easily, I'm afraid.
To be fair you also get some lesser psychopaths'; the angry guy who reported his bugs, replied and demanded to be replied to via Lisp programs in quoted code blocks was a more memorable one.
> because they report bugs in the same place that all the other people do, they create spam accounts, they concern troll, they divert conversations onto their pet issues, they do everything people have done to irritate other people on the internet for ages.
What this is saying that if your "free software project" includes anything more than providing the source code for free online--in other words, if it includes things like a bug tracker, a discussion forum, etc., that you are actually paying attention to--then it's not just a "free software project" any more, it's more like a "free website", and has many of the same issues people are discussing here relative to the latter. And the solution would be much the same: your time and effort isn't free, so if you're giving it to the project, the project shouldn't be free; you should charge for it.
What I would consider "free software" is beside the point. I'm not trying to propose a new definition of "free software" or argue for some particular way of labeling projects as "free software". I'm just pointing out that if a project author decides to provide anything more in relation to their project than their source code for free online, they are taking on a potential burden in time and effort, and if the burden becomes too much for them to provide for free, they will either need to start charging for it, or stop doing it. The SSLPing project has taken option number two.
Love to see your email filter that separates messages from helpful users from demanding users.
If you can't automate this step, you have to read the insults, and pleading, and jerk-faced comments from the demanding users. Which takes time and energy.
My filter is my brain. I just... don't interact with people who don't seem worth interacting with.
And, look, that's not perfect and I'm not saying that it's not unpleasant. I'm saying that it's materially different from every person who uses your service costing you actual dollars. And if you can't see that, I honestly don't know what to tell you.
If you filter who can complain, you do not have to deal with those that you do not care about.
SAAS with free tier does it this way:
* To contact support via non-app method you need a PIN. PIN is displayed when you login into your paid account. Don't have a PIN? Can't connect to support.
* To contact support via app method your profile needs to be associated with a paid account. Don't have a paid account? Can't contact support via inapp
> No issue reports or PRs unless you’re also a paying user.
You'd turn down quality bug-reports and code-contributions in the name of blocking spam?
I doubt I'm the only one who would take strong objection to the idea of pay me so that you can work on my project.
Open Source software development can be made to scale to the level of the Linux kernel. I don't buy the idea that its principles need to be thrown out in the name of anti-spam practicalities.
> The users are treated like co-developers and so they should have access to the source code of the software. Furthermore, users are encouraged to submit additions to the software, code fixes for the software, bug reports, documentation, etc. [0]
Introducing a paywall to keep out those who wish to submit improvements to a project, is the antithesis of encouragement.
> I’d also pay that in a heartbeat as a user.
Not every Open Source contributor has money to give.
A better alternative might be for a forge website (GitHub or whomever) to implement a user-scoring system. Wikipedia uses this approach quite successfully, where only users with a certain level of 'credibility' are permitted to make changes to semi-protected articles. StackExchange/StackOverflow does something similar to avoid spam on 'highly active questions'. Even HackerNews does something like this, showing usernames in green for new accounts.
What the forge would actually do with the user-score, I'm not certain. It would be difficult to do anything without making the forge less welcoming to newcomers.
I don't agree that this is a "principle". Having free access to the source is IMO the only principle. As stated in the wikipedia article, the rest is just a "suggestion". I think there's plenty of room to evolve while maintaining the core principle of actually being open source. There already exists a lot of OSS that does NOT grant low investment contribution, and that's not always a bad thing.
The point, as I see it, is to raise the investment / friction required to contribute. You are less likely to pollute a project with inane comments if you're invested (not guaranteed, just less likely). I wouldn't recommend this for any / all OSS, but instead when you start getting tons of low value contributions. In fact you'll see a lot of issues on large OSS projects that I wouldn't even categorize as "contributions", but more like complaining or simply asking questions that are often already clearly documented. E.g. "Doesn't work! Fix please!"
We're seeing a lot of OSS projects simply close down their issue reporting because they don't want to deal with it. If there was an easy way to enforce investment / quality of feedback I think some of these project would probably keep their issue reporting open.
User scoring could potentially work too. It would be an interesting experiment. I think there's a lot of room to try things. For example, you could complement a paid model with an application process to gain free access (for those who can't afford it) as both would require user investment (money OR time).
> Having free access to the source is IMO the only principle
That doesn't sound right. The OSI have strong opinions about what licences qualify as Open Source licences, it's not enough to just let people see the source-code. [0][1][2]
> There already exists a lot of OSS that does NOT grant low investment contribution, and that's not always a bad thing.
Sure, it's possible for a software project to release under an Open Source licence while using a closed-shop (Cathedral) development process. An extreme example would be the id Tech 4 engine, which was originally closed-source.
We could say that Open Source has two meanings: one is about software licences, the other is about software development methodologies.
> raise the investment / friction required to contribute. You are less likely to pollute a project with inane comments if you're invested (not guaranteed, just less likely).
I agree that raising the barrier to entry will probably be effective in keeping out low-quality 'contributions', but likely at a cost to high-quality contributions.
Also, ideally there should be a proper answer to user-support. That is, support tasks should be properly separated from bug-reports, and there should be some kind of system for handling them, perhaps a community forum or perhaps the offer of paid support.
When someone inexperienced needs help, it's not great if there's no answer for them other than contempt. That's how we get angry trolls.
> I wouldn't recommend this for any / all OSS, but instead when you start getting tons of low value contributions.
I wonder what fraction of projects this applies to. When a project does something arcane that can act as a barrier against poor-quality comments, but of course it also acts as a barrier against interest in general. If a project does something broadly useful and is easily approachable, that's presumably when you're mostly likely to have trouble with an onslaught of poor-quality contributions.
> you'll see a lot of issues on large OSS projects that I wouldn't even categorize as "contributions", but more like complaining or simply asking questions that are often already clearly documented. E.g. "Doesn't work! Fix please!"
Right, there's certainly a skill to filing bug-reports and support-requests.
Incidentally I think GitHub does a poor job of separating the two, which may contribute to your problem (assuming you use GitHub).
> Linux as an example. They have a detailed process for reporting issues. You can't just one-line tweet an issue and expect it to receive attention
I think they're a good case-study for this.
They ask that you follow a pretty rigorous sequence of checks before awakening the high-priests of the kernel. Perhaps that's enough. Perhaps more projects should have a quick Before you open a ticket document.
I suspect their email-driven process might also strike a lot of people as, well, intimidating. Email is associated with serious communication using your real name. I suspect people will be more considered when using mailing lists.
I also suspect that if you use an email-driven forge like SourceHut, [3] that would greatly increase the average technical competence of those interacting with your project. It may also reduce the total number of people interacting with it, mind.
