> 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.
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.
[0] https://en.wikipedia.org/wiki/Open-source_software#Open-sour...
[1] https://opensource.org/licenses
[2] https://opensource.org/osd
[3] https://sourcehut.org/