You make claim after claim, and I think they do need substantiating evidence. After all, I find it highly unlikely that if he were even 10% as bad as you make it sound he would be the head of one of the most successful projects - especially since everybody working with him does so voluntarily. There would have been breaks long ago. The fact that the Linux kernel held together under the original author loudly speaks against assumptions of "bad interpersonal skills" on the side of Linus.
See what I already wrote. This is like marketing research - what do you believe, what people tell you or the data about what they actually do? Because the data say what I already wrote. So you might as well interpret this as "Linus is a very humble guy" and have better support from the data.
Or, alternatively, you can believe that a really mean person who doesn't care about others and behaves badly still managed to hold the kernel developers together. Sure, a single or even a few discontent developers can't easily fork the kernel - but if there would really have been a problem even a tenth as large as claimed by some (and I've never seen any of them actually having had any personal contact with Linus) they would long ago have forked. See node.js/io.js, OpenOffice, and other prominent examples for what happens when developers are not satisfied with the project's leadership.
I don't understand what this has to do with refuting the original claim:
> Ultimately I think Linus's contributions to Software are pantheon, but he should not be looked to for imitation or lessons. His lessons for success are detrimental to the vast majority of software engineers.
You're not supplying any examples others can learn from or benefit from imitating, you're just asserting they must exist.
Uhm... this is again backwards. I'm not making any claims - I'm responding to others who do. And I did (still) provide evidence: The Linux kernel project itself. Instead of individual anecdotes or some carefully selected email or sentences taken out of context I point to the whole project as the final outcome measurement. See what I wrote?
I won't argue with your main point, but a fair share of kernel devs are probably not working there voluntarily, since they write kernel code for their employer.
I'd expect that most devs capable of writing reasonable Linux kernel code would not have difficulty finding employment somewhere else doing something else.
But this is backwards! You don't become a kernel developer by being assigned to the job by your employer. Instead, employers hire people who are kernel developers. Source: I myself contributed a teensy tiny bit to the network stack loooong ago (2.4 kernel), and I worked with real kernel developers when I worked at one of the major Linux companies and for them with large (mostly US) software companies.
