I just read Rusty Russell’s recent blog post about code written by assholes and Jacob Kaplan-Moss’s response. I’ll summarize Rusty’s point as “You don’t have to like assholes or agree with them, you just have to work with them in open source,” and Jacob’s point as, “No, I don’t have to work with assholes, and if we all worked together we could make it unacceptable to be an asshole in open source.” (Hacker News discussion here.)
At one time, I fully subscribed to the dogma that the only way to create high-quality, well-designed, reliable systems code (open source or not) was to be assholes to each other. But I’ve come to disagree with past-Valerie about the necessity of assholes for a number of reasons, starting with existence proofs to the contrary: successful well-designed projects run by non-assholes like Python and Perl.
Take just one argument for the necessity of assholes: Public humiliation is required for high-quality code. If you will be publicly mocked and humiliated for posting bad code, you’ll work harder on finding and fixing your bugs, and the overall code quality will go up. Sure, fear makes you review your code more – but is this the best way to create high-quality code overall? Are the costs higher than the benefits?
Research has shown over and over again that people experiencing fear are less creative in problem solving and less likely to find the optimum solution. Fear makes you more careful in your work, but it also makes you less willing to take risks, try new ideas, and make progress. Fear might be a good way to run a maintenance-mode project, but not one that needs active development and new ideas.
The more I look at the arguments for why assholes are necessary to good code, the more I have to wonder if some form of Stockholm syndrome is at work. As open source developers, our careers are to some degree hostage to project leaders. If project XYZ has an abusive leader, you either have to keep working on that project with that leader, or make a significant and risky career change. Change the leader or their behavior? Not really an option. There’s no manager or HR department to go to to deal with abusive fellow “employees” in open source, and it’s hard to move to a project far enough away not to work with that person but still be in your area of expertise. It’s a tough choice.
What I do know is that a lot of open source developers in asshole-heavy projects are unhappy with the current situation. Is it possible to change the social norms of these open source projects without lowering code quality? My guess is that the answer is yes, but only time will tell.
Update: People keep recommending “The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t” by Robert Sutton. I haven’t read it, but it sounds promising enough that I bought a copy and will read it this weekend.