There is a specific behavior pattern of anti-contribution that I've seen
a lot on the mailing list (geda-user)  of our predecessor (pcb). The simplified
model of the setup is this:
<ul>
	<li> there is a developer, D, who spent dozens or hundreds of hours
	     understanding a problem, finding a solution to it and/or implementing
	     related code
	<li> there is an user, U, who has spent 5 minutes trying to understand
	     the same problem
	<li> most often U did not read any related (or even referenced)
	     documentation, article or writeup beyond the headline
	<li> most often U did not read <b>any</b> code
	<li> most often U generally has zero understanding on the goals D is
	     trying to achieve
	<li> sometimes U is not even a potential user of the feature in question
</ul>
Still, what U does is:
<ul>
	<li> makes strong, public statements about how exactly the solution to
	     the problem should look like
	<li> and/or makes strong, public statements about how D's approach to the
	     problem is totally wrong
	<li> insists on being helpful, while not willing to invest any time
	     on understanding the problem or doing any part of the actual work.
</ul>
<p>
<b>This behavior is not tolerated in the pcb-rnd community.</b> After a few
warnings, U gets suspended or banned.

<h2> Rationale </h2>
<p>
The economy of pcb-rnd is rather simple. There are two assets that make the
project go forward: strategy and time invested. Strategy is decided by the
lead developer (Igor2). Time is invested by a lot of people: developers,
power users, users.
<p>
The project goes forward only if:
<ul>
	<li> 1. enough time is invested so that thinds are actually get done;
	<li> 2. it has a good strategy (so it is focused and is heading in a clear
	     direction, not just "happening randomly").
</ul>
<p>
If you want to help the project, <b>you need to contribute your time.</b> -
that is the only way to fulfil rule 1. To also comply with rule 2, it does
matter how you spend your time: most of the contribution needs to be
focused in the direction the project is going.
<p>
That means random strong opinions are not helping the project at all. As
geda-user@ showed, quite the opposite happens: if there are only a few loud,
but useless "insistors" (U above) appear, that easily can demotivate existing
developers (D above) and the project dies.

<h2> What U must accept (and economy of contribution) </h2>
<p>
You can have an opinion about anything. You can share your opinion. But
your opinion alone can be worthless. Everyone has them, anyone can have
hundreds of opinions for free. Adding value to a project needs investment.
An opinion that is not result of investment, is not adding to the project.
What can make your opinion worth <i>anything<i> is a product of how much
time you have invested in understanding/solving the problem before wording
your opinion and how much it is in line with the project strategy.
<p>
Remember: if it took 15 seconds of reading/research to form your
opinion, it will take 15 seconds for everyone else too to get to the
same level, so it is probably not worth even typing an email about it.
This is simple economy: you can't make invaluable opinions (that are
available for free for anyone) valuable without investing (time) in it
first. No investment means no value. No value means noise, just waste of
your and our resources. By pressing a no-value opinion,  you are not
helping the project, but set it back by stealing resources from
more useful things.
<p>
If you are U, and you keep insisting on something that is clearly
against project strategy, and/or not backed up with investment (at least
the minimum reasonable time understanding the problem first), you will
get a few warnings and eventually get suspended or banned.

<h2> Notable exceptions </h2>
<p>
In a few rare occassions "time invested" can be substituted with something
else that is not freely available for everyone immediatly. This is most often
just a different form of time investment: resources that you have already
invested in the past. Typical exampels:
<ul>
	<li> the project needs some knowledge you already invested a lot of time
	     learning, in the past (e.g. you know details of a non-trivial file
	     format, you spent hundreds of hours implementing a few versions of
	     something we are about to implement now so you can share how different
	     designs will or will not work)
	<li> you have access to some exotic, not-cheaply-available-for-everyone
	     device (e.g. you have a g-code capable router you can use for testing
	     pcb-rnd exports with minimal time investment from your side)
</ul>