Great analysis. Theo is always up front on this sort of stuff which is commendable.
"Anyone who ever told you that swear words have no place in technical discussion is right. They're right, and sadly, they're part of the problem because they miss the point. The sterile word placement that's supposed to support an argument makes any true motivation indistinguishable from all the hired bullshit.
[...]
However, when someone starts swearing in technical discussion, showing emotion, that's a strong indicator that I'm about to receive wisdom. Wisdom is earned the hard way, and it is permanent, not like some statistically shaky performance benchmark that we'll all forget about next week."
I feel the same - I'd rather have people feeling passionate about their work and use swear words, than work with polite non-personalities that don't give a fuck.
If someone does swear (and as it goes, I'm fine with swearing for emphasis and swear way more than I feel I should) they need to be aware that some people find it offensive and that if they don't moderate their behaviour it may be taken very personally which can result in barriers between colleagues and / or low morale.
You can choose to say that that's the person reacting's problem but if you do so you need to be aware of the price that comes with (that they're working in an environment with which they're not completely comfortable which is unlikely to get the best out of them). The alternative is that the swearer moderates themselves (with which they in turn may not be comfortable).
Obviously the better you know your colleagues the more leeway you have. If you've built up trust and togetherness overtime you can get away with anything but even then you need to consider what happens when new people join the team.
But ultimately this is about people and where it's about people there are no absolutes - what works for one group will be kryptonite for another.
For me two thoughts come out of this:
1) Yes they've been productive the way they work, but have they been more or less productive than if they'd been just as right but a little less confrontational?
Research generally doesn't show confrontation to be the most productive approach for most people. Is their style productive, or is it unproductive but they get away with it because they're so good that people will put up with it?
You say that the best course of action if you want to avoid Theo's ire is not to write bad code, but how many people have taken another approach? The one that springs to mind is not working with him and how much talent does the project miss out on because people just steer clear? I know plenty of very smart programmers who simply don't go near projects where the culture and personalities are like that. Bad behaviour towards others (even when you're right) limits the available pool of skills.
2) I can live with the arsehole geniuses but others who aren't as able often use the likes of Jobs or Theo to justify their own poor, destructive behaviour. For me at least, that doesn't work - if you're going to be as big a dick but you're not as good as them you're basically just a dick and if the day eventually arrives when the IT industry doesn't have a massive skills shortage, those people will cease to be tolerated.
People matter. The way software makes them feel matters. Code smell and related concerns are best conveyed in profoundly human ways. Fuck it. Say it like you mean it.
And he's quite right. This is a class of bug that should not exist or, at least, be restricted to the OSs where "malloc() performance is bad enough" to justify using their own implementation. Memory management is a non-trivial problem.
A secure library should be defensive in coding style and implementation, not sloppy. It should have defaults that err on the safe side, not the fast side, if you have to choose.
If you refuse to understand the reasons for engineering, conceptual integrity, and discipline in writing code that needs to be readable (read: dull and boring), then I don't know what to say.
We want to incite more people to audit and contribute to these projects, not the other way around. Insult the engineering, not the engineers. Or, alternatively, don't insult and propose improvements.
Prepare for some OSS heresy: in many projects, contributions are overrated.
Why? Presumably, the author is the one who feels the most joy/pain of what they've made. They're the ones who've had to grow and prune the code over time. They're the ones who've had to respond to features breaking their mental model sometime. They're the ones trying to make a cohesive abstraction. On crappy projects, the users shoulder more and more of this burden because the author did not.
I've had good luck with contributions in OSS (both making and accepting), but I realize a majority of them are "this isn't working for me, so I added this" without sitting down and considering it's effect on the entire design. I hate rejecting contributions, but if they compromise the project's modeling of the problem, or code quality, then it's for the better.
OSS lends itself to feature creep, just like commercial software. The marketing side of OSS rewards this, by incentivizing you to make more commits (such traction!) and accept changes from everyone (because, community!). New and shiny is a horrible heuristic to use when evaluating infrastructure (read: lots of OSS).
How they express it is a reflection of their character, but they will let you know when you screw up. Theo was extremely tact given the enormous impact of this bug.
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c?...