It's funny because I was just reading Gladwell's Outliers and his section on culture and airline crashes seems particularly relevant here. Here's a quote analys

It's funny because I was just reading Gladwell's Outliers and his section on culture and airline crashes seems particularly relevant here. Here's a quote analysing the Korean Air flight 801 crash: """ FIRST OFFICER: Don't you think it rains more? In this area, here? The first officer must have thought long and hard before making that comment. [...] Among Korean Air flight crews, the expectation on layovers used to be that the junior officers would attend to the captain to the point of making him dinner or purchasing him gifts. As one former Korean Air pilot puts it [...] "the captain is in charge and does what he wants, when he likes, how he likes, and everyone else sits quietly and does nothing." [...] So when the first officer says, "Don't you think it rains more? In this area, here?" we know what he means by that: Captain. You have committed us to visual approach, with no backup plan, and the weather outside is terrible. You think that we will break out of the clouds in time to see the runway. But what if we don't? It's pitch-black outside and pouring rain and the glide scope is down. """ The plane crashes not because of any individual error, but rather because the culture aboard the plane is weak in a tragically important area plane flight: communicating errors. So imagine my surprise when I see this post on the bug tracker: "Ehsan, are you going to be able to pick this up again? If not, let's find a new owner." In an open source project, you don't pay people in money. They're paid in intrinsic motivation. For that reason, it can be very dangerous to do things that would be commonplace in a business. For example, pulling someone off a task and reassigning it to someone else. I would read that post as "Ehsan, can you fix this or should I assign it to someone else?" And I would read his reply as "No, I don't think I can without extra help". But no help comes, because the discussion is wrapped in social code to avoid appearing incapable or ordering someone around, neither of which are really acceptable in an open source project. I suspect that this represents a general trend, and much of the reason why good design has come so late to the picture for Linux, when it seems to fall so naturally out of everything Apple touches. The culture in open source is a kind of loose-knit collective individualism, which means leadership in open source looks a lot like gardening: your main function is to tend the soil and stop the plants from strangling each other. But design necessarily requires autocratic leadership - a person or persons whose vision for the product subsumes the priorities of any individual working on it. As a thought experiment, imagine if everyone's favourite ex-Apple CEO was faced with this bug. I can't help but imagine him kicking in someone's door and screaming "Why isn't it fixed? What do you need? Don't understand XBL? Here's the guy who writes the event handler. Neither of you are leaving until it's done. Namaste." That's a good way to lose contributors, but it would get the bug fixed. I don't think Mozilla would necessarily be a better organisation with more screaming but, like Korean culture has a characteristic failure mode (problems that would have been impolite to fix), open source has its own characteristic failure mode: a problem that would have been solved if someone cared enough.