Inclusions+Exclusions

Who gets to call themself a hacker? Even if definitions were clear, which they are not, the rules for who gets included or excluded from any particular group of hackers are rarely clear. “You are a hacker when another hacker calls you a hacker”—this was once a famous way of determining who’s in and who’s out. But that restriction is guaranteed to reproduce uniformity not diversity. In the last decade, multiple groups of hackers have fought to open the hacker door and let in more and different kinds of people. What used to be a fight over how stuff should be done has become a fight over who gets to be part of the team. Once debates were about the programming language hackers use (pff, they only write in “C”!), the type of software engineering they are assigned to do (they are routing algorithm specialists, don’t you dare ask them about security systems!), has come to include searing and long overdue debates about inclusions and exclusions of various kinds: about sex and gender, about race and ethnicity, about heroes and abusers and bias and harassments.

The dream of meritocracy persists though: hackers are to be accepted and included by proving to the rest of the team that they can indeed fix, build, break or maintain a piece of hardware or software, despite all odds, prejudices or stereotypes. For some critics, the existence of this dream is the problem—a conceit that must be exposed, punctured, and eradicated. For others, the aspiration is worthy and the point is to topple barriers to bring the ideal a bit closer to reality.

Although there is no consensus about how to deal with the problem of exclusions, many now recognize the problem and agree to tackle it. This section is devoted to showcasing examples of how hackers have come to diagnose and expose exclusions and their attempts to build more inclusive spaces and projects.