Well, it is efficient if you want to minimise the number of people who aren't star programmers with hard heads and don't care how many star programmers with man

Well, it is efficient if you want to minimise the number of people who aren't star programmers with hard heads and don't care how many star programmers with manners you turn away. If your supply pool is big enough, you will have great success. Hypothetically though - would it be that much better if Linus et al. were turning away people politely with words like "this code doesn't meet our standards of quality because X Y Z" instead of "your code is shit, see X Y Z"? Also, for people at the lead, you need those who can say "no", know when to say "no", aren't going to compromise just because the patch was sent by so-and-so and won't hold back from saying where they see a problem. You also want them to be good at communicating with people in a civil manner. The two are unfortunately orthogonal qualities. It seems to me that we should first take the people who are definitely good enough in the engineering aspect to understand and lead the project, then select the best communicator, rather than seeking someone with a best average score at engineering and communicating. You might get impolite people at the top, but you will guarantee the project won't get worse.