What is hacker culture?
Nov. 29th, 2015 12:00 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Eric Raymond, author of The Cathedral and the Bazaar (an important work describing the effectiveness of open collaboration and development), recently wrote a piece calling for "Social Justice Warriors" to be ejected from the hacker community. The primary thrust of his argument is that by calling for a removal of the "cult of meritocracy", these SJWs are attacking the central aspect of hacker culture - that the quality of code is all that matters.
This argument is simply wrong.
Eric's been involved in software development for a long time. In that time he's seen a number of significant changes. We've gone from computers being the playthings of the privileged few to being nearly ubiquitous. We've moved from the internet being something you found in universities to something you carry around in your pocket. You can now own a computer whose CPU executes only free software from the moment you press the power button. And, as Eric wrote almost 20 years ago, we've identified that the "Bazaar" model of open collaborative development works better than the "Cathedral" model of closed centralised development.
These are huge shifts in how computers are used, how available they are, how important they are in people's lives, and, as a consequence, how we develop software. It's not a surprise that the rise of Linux and the victory of the bazaar model coincided with internet access becoming more widely available. As the potential pool of developers grew larger, development methods had to be altered. It was no longer possible to insist that somebody spend a significant period of time winning the trust of the core developers before being permitted to give feedback on code. Communities had to change in order to accept these offers of work, and the communities were better for that change.
The increasing ubiquity of computing has had another outcome. People are much more aware of the role of computing in their lives. They are more likely to understand how proprietary software can restrict them, how not having the freedom to share software can impair people's lives, how not being able to involve themselves in software development means software doesn't meet their needs. The largest triumph of free software has not been amongst people from a traditional software development background - it's been the fact that we've grown our communities to include people from a huge number of different walks of life. Free software has helped bring computing to under-served populations all over the world. It's aided circumvention of censorship. It's inspired people who would never have considered software development as something they could be involved in to develop entire careers in the field. We will not win because we are better developers. We will win because our software meets the needs of many more people, needs the proprietary software industry either can not or will not satisfy. We will win because our software is shaped not only by people who have a university degree and a six figure salary in San Francisco, but because our contributors include people whose native language is spoken by so few people that proprietary operating system vendors won't support it, people who live in a heavily censored regime and rely on free software for free communication, people who rely on free software because they can't otherwise afford the tools they would need to participate in development.
In other words, we will win because free software is accessible to more of society than proprietary software. And for that to be true, it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background.
Up until this point, I don't think I've made any controversial claims. In fact, I suspect that Eric would agree. He would argue that because hacker culture defines itself through the quality of contributions, the background of the contributor is irrelevant. On the internet, nobody knows that you're contributing from a basement in an active warzone, or from a refuge shelter after escaping an abusive relationship, or with the aid of assistive technology. If you can write the code, you can participate.
Of course, this kind of viewpoint is overly naive. Humans are wonderful at noticing indications of "otherness". Eric even wrote about his struggle to stop having a viscerally negative reaction to people of a particular race. This happened within the past few years, so before then we can assume that he was less aware of the issue. If Eric received a patch from someone whose name indicated membership of this group, would there have been part of his subconscious that reacted negatively? Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection? We don't know, and it's unlikely that Eric does either.
Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.
When people criticise meritocracy, they're not criticising the concept of treating contributions based on their merit. They're criticising the idea that humans are sufficiently self-aware that they will be able to identify and reject every subconscious prejudice that will affect their treatment of others. It's not a criticism of a desirable goal, it's a criticism of a flawed implementation. There's evidence that organisations that claim to embody meritocratic principles are more likely to reward men than women even when everything else is equal. The "cult of meritocracy" isn't the belief that meritocracy is a good thing, it's the belief that a project founded on meritocracy will automatically be free of bias.
Projects like the Contributor Covenant that Eric finds so objectionable exist to help create processes that (at least partially) compensate for our flaws. Review of our processes to determine whether we're making poor social decisions is just as important as review of our code to determine whether we're making poor technical decisions. Just as the bazaar overtook the cathedral by making it easier for developers to be involved, inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code, but also in terms of the ability of the project to meet the needs of a wider range of people.
The fight between the cathedral and the bazaar came from people who were outside the cathedral. Those fighting against the assumption that meritocracies work may be outside what Eric considers to be hacker culture, but they're already part of our communities, already making contributions to our projects, already bringing free software to more people than ever before. This time it's Eric building a cathedral and decrying the decadent hordes in their bazaar, Eric who's failed to notice the shift in the culture that surrounds him. And, like those who continued building their cathedrals in the 90s, it's Eric who's now irrelevant to hacker culture.
(Edited to add: for two quite different perspectives on why Eric's wrong, see Tim's and Coraline's posts)
This argument is simply wrong.
Eric's been involved in software development for a long time. In that time he's seen a number of significant changes. We've gone from computers being the playthings of the privileged few to being nearly ubiquitous. We've moved from the internet being something you found in universities to something you carry around in your pocket. You can now own a computer whose CPU executes only free software from the moment you press the power button. And, as Eric wrote almost 20 years ago, we've identified that the "Bazaar" model of open collaborative development works better than the "Cathedral" model of closed centralised development.
These are huge shifts in how computers are used, how available they are, how important they are in people's lives, and, as a consequence, how we develop software. It's not a surprise that the rise of Linux and the victory of the bazaar model coincided with internet access becoming more widely available. As the potential pool of developers grew larger, development methods had to be altered. It was no longer possible to insist that somebody spend a significant period of time winning the trust of the core developers before being permitted to give feedback on code. Communities had to change in order to accept these offers of work, and the communities were better for that change.
The increasing ubiquity of computing has had another outcome. People are much more aware of the role of computing in their lives. They are more likely to understand how proprietary software can restrict them, how not having the freedom to share software can impair people's lives, how not being able to involve themselves in software development means software doesn't meet their needs. The largest triumph of free software has not been amongst people from a traditional software development background - it's been the fact that we've grown our communities to include people from a huge number of different walks of life. Free software has helped bring computing to under-served populations all over the world. It's aided circumvention of censorship. It's inspired people who would never have considered software development as something they could be involved in to develop entire careers in the field. We will not win because we are better developers. We will win because our software meets the needs of many more people, needs the proprietary software industry either can not or will not satisfy. We will win because our software is shaped not only by people who have a university degree and a six figure salary in San Francisco, but because our contributors include people whose native language is spoken by so few people that proprietary operating system vendors won't support it, people who live in a heavily censored regime and rely on free software for free communication, people who rely on free software because they can't otherwise afford the tools they would need to participate in development.
In other words, we will win because free software is accessible to more of society than proprietary software. And for that to be true, it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background.
Up until this point, I don't think I've made any controversial claims. In fact, I suspect that Eric would agree. He would argue that because hacker culture defines itself through the quality of contributions, the background of the contributor is irrelevant. On the internet, nobody knows that you're contributing from a basement in an active warzone, or from a refuge shelter after escaping an abusive relationship, or with the aid of assistive technology. If you can write the code, you can participate.
Of course, this kind of viewpoint is overly naive. Humans are wonderful at noticing indications of "otherness". Eric even wrote about his struggle to stop having a viscerally negative reaction to people of a particular race. This happened within the past few years, so before then we can assume that he was less aware of the issue. If Eric received a patch from someone whose name indicated membership of this group, would there have been part of his subconscious that reacted negatively? Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection? We don't know, and it's unlikely that Eric does either.
Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.
When people criticise meritocracy, they're not criticising the concept of treating contributions based on their merit. They're criticising the idea that humans are sufficiently self-aware that they will be able to identify and reject every subconscious prejudice that will affect their treatment of others. It's not a criticism of a desirable goal, it's a criticism of a flawed implementation. There's evidence that organisations that claim to embody meritocratic principles are more likely to reward men than women even when everything else is equal. The "cult of meritocracy" isn't the belief that meritocracy is a good thing, it's the belief that a project founded on meritocracy will automatically be free of bias.
Projects like the Contributor Covenant that Eric finds so objectionable exist to help create processes that (at least partially) compensate for our flaws. Review of our processes to determine whether we're making poor social decisions is just as important as review of our code to determine whether we're making poor technical decisions. Just as the bazaar overtook the cathedral by making it easier for developers to be involved, inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code, but also in terms of the ability of the project to meet the needs of a wider range of people.
The fight between the cathedral and the bazaar came from people who were outside the cathedral. Those fighting against the assumption that meritocracies work may be outside what Eric considers to be hacker culture, but they're already part of our communities, already making contributions to our projects, already bringing free software to more people than ever before. This time it's Eric building a cathedral and decrying the decadent hordes in their bazaar, Eric who's failed to notice the shift in the culture that surrounds him. And, like those who continued building their cathedrals in the 90s, it's Eric who's now irrelevant to hacker culture.
(Edited to add: for two quite different perspectives on why Eric's wrong, see Tim's and Coraline's posts)
Can we all be on Team Not Evil?
Date: 2015-11-30 09:37 pm (UTC)Broadly speaking, Brendan Eich didn't have it too bad as a target of the Two Minutes' Hate. He's apparently still working, and he didn't, so far as I know, suffer credible threats to his safety.
But. Describing someone who held beliefs about politics and engaged in the political process to act on them as "using political violence" is problematic. Are the seven million Californians who voted for Prop 8 to be made pariahs? Is President Obama, who held the same opinion back in 2008, to be met with violence, because, after all, having an opinion on marriage policy with which you disagree is violent, right?
(This should go without saying, but I'm in object-level agreement here; Proposition 8 was wrong. That doesn't mean that people who were on the other side of the issue from me should be punished.)
The stance you have against mobbing and harassment sounds very nice, but I question how sincere you are about it when it doesn't seem to apply to people on your side of things.
Re: Can we all be on Team Not Evil?
Date: 2015-11-30 11:34 pm (UTC)The majority of people who voted for Prop 8 were stating their opinion. Brendan spent money in an attempt to change people's opinion. I think that's a qualitative difference. But, more to the point, most people who voted for Prop 8 weren't then seeking leadership in an organisation with a hugely diverse community. If Brendan was willing to vote to deny rights to one set of that community, why should other minorities within it trust him not to do something similar to them later?
But that's not really what you were asking. On that front, Brendan deliberately used his resources to encourage amending the state constitution to remove rights from a specific set of citizens. If he'd voted for a larger set of rights to be removed (eg, forbidding homosexuals from owning property or being allowed to vote), I suspect you'd be ok with the analogy to violence. People are going to draw the line at different points along the spectrum of rights that could be removed.
Yes, drawing the line somewhere is important.
Date: 2015-12-01 07:37 pm (UTC)Okay, then are the roughly thirty-two thousand people (http://projects.latimes.com/prop8/results/?name=&employer=&amount_min=&amount_max=&city=&state=CA&zip=&position=Support&search=Search) who donated in support of Proposition 8 to be made pariahs? Or just ineligible for jobs which involve leadership in an organization with a broad customer base? (You know, you can search by employer there. Will you be attempting to get a purge going? There are university employees in there--are they making a hostile environment for their students? Better to be safe, right?)
Your position, then, is that voting wrong is okay (how generous), but donating wrong is a social crime. I'd guess that volunteering for a bad cause is in the latter category too, right? Are yard signs out, or do you have to volunteer actual time to be a bad person?
You say that "People are going to draw the line at different points along the spectrum of rights that could be removed." And yes, if Eich had voted for or donated money in support of rounding up gay people and putting them in camps somewhere, I'd think he wasn't fit to be part of polite society. But he didn't. If he'd eaten babies, people would also call for his ouster, but I think that kind of counterfactual misses the point.
I can't help but think that this is an attempt to criminalize (in the court of public opinion, at least) disagreement. Do you remember 2008? This was an open question! We're supposedly a pluralistic society; we should be able to disagree, even about things that matter, without being subject to purges and ex-post-facto decisions like this.
Re: Yes, drawing the line somewhere is important.
Date: 2015-12-01 11:21 pm (UTC)It's also not unreasonable to hold people to a higher standard for a leadership position in a company and community that explicitly wants to be inclusive and that has significant participation from people who value that inclusiveness. We can ideally seek out people who are in the "unusually less so" category, and at the very least rule out people in the "unusually more so" category.
Are you eliding some history?
Date: 2015-12-01 11:37 pm (UTC)You know who else opposed same-sex marriage at the time (https://en.wikipedia.org/wiki/Public_opinion_of_same-sex_marriage_in_the_United_States#Demographic_differences)? (More so than the rest of the country, that is.) Old people! Rural people! Black people! Religious people! Southerners! People who never went to college!
Those people aren't well-represented in the Bay Area techie bubble. I'm sure it sends a message to them when someone who holds their sort of belief, even privately, is drummed out of said bubble.
Re: Yes, drawing the line somewhere is important.
Date: 2015-12-02 11:52 am (UTC)Widespread opprobrium doesn't make something wrong.
Date: 2015-12-03 01:57 am (UTC)And on that note, you know who else was the subject of widespread international opprobrium? Anita Sarkeesian! I hope that you don't conclude from this that she should have been bullied into silence and we should be happy about it because 'that's how the world works'.