[rapind]

> You'd turn down quality bug-reports and code-contributions in the name of blocking spam?

Absolutely I’d “risk” it. Even a negligible amount like $10, would reduce the noise significantly. I’d also pay that in a heartbeat as a user.

> I don't buy the idea that its principles need to be thrown out in the name of anti-spam practicalities.

What “principles” are you referring to?

[MaxBarraclough]

> What “principles” are you referring to?

Those of Open Source software development:

> 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.

[0] https://en.wikipedia.org/wiki/Open-source_software#Developme...

[rapind]

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).

You mentioned 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. https://docs.kernel.org/admin-guide/reporting-issues.html#st...

[MaxBarraclough]

> 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.

[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/

[rapind]

Great points and discourse. Cheers!