Earlier quoted context omitted.
Kalium, you bring up the strongest point in favor of defending and using verbally abusive language. I've been through military basic training, and such language is routinely used because it is quite effective at communicating error by breaking down mental resistance and barriers to correction. In that case, the potential for emotional harm is outweighed by the net reduction in the probability for physical harm on the…
I agree, there are other methods to accomplish the same thing without the toxic side effects. That is not in question. The question is if those methods produce superior outcomes, as a lack of the side effects in question does not by itself represent a superior outcome. Remember, the goal of an open source project is useful code. A friendly and emotionally supportive community is only desirable if it aids in achieving…
I concur that open source projects' primary and over-arching goal is and should be to produce good code.
When the leader of a project freely (though not so frequently in this case) uses verbally abusive language, that has the strong effect of limiting the diversity of potential contributors to the project.
I'm willing to assume that a more diverse project tends to be a project that will produce better code.
In this particular case, bad code wasn't included in the project. The abusive language did nothing to stop merge of bad code.
So did verbally abusing this developer somehow cause his/her future contributions to be of higher quality? I don't know the answer to that.
Or perhaps did this verbal abuse generally raise everyone else's code quality, because they didn't want to become a victim as well? Perhaps.
One thing I am certain of, though, is that such choices artificially and severely limit the possible side of the contributor pool, and that's bad.