Skip to main content
SearchLogin or Signup

Hacking Technology, Hacking Communities: Codes of Conduct and Community Standards in Open Source

In recent years, the free/libre and open source software (FLOSS) and hacking communities have engaged in lively debates about diversity and inclusion in their ranks...

Published onAug 10, 2021
Hacking Technology, Hacking Communities: Codes of Conduct and Community Standards in Open Source
·

Abstract

In recent years, the free/libre and open source software (FLOSS) and hacking communities have engaged in lively debates about diversity and inclusion in their ranks. These conversations gained momentum when research showed that women’s rate of participation in FLOSS was shockingly low, even compared to academic computer science and industry. Participants questioned whether the commitment to “openness” in coding and technical activities extended to the communities themselves, and proposed changes to how their communities were governed. One change many communities instituted was to introduce codes of conduct, intended to formalize community standards for how people should behave when they collaborate. This case presents a 2015 example of an introduction of a code of conduct and the discussion surrounding it as a way to surface some of the tacit patterns in FLOSS communities. Communities continue to refine their values and how they wish to guide participation in coding and hacking.

Keywords: open source software; diversity and inclusion; community governance; gender; race; values in computing; codes of conduct

Christina Dunbar-Hester
Annenberg School for Communication and Journalism, University of Southern California



Author Disclosure(s): The material in this case study has been presented earlier in Christina Dunbar-Hester, Hacking Diversity: The Politics of Inclusion in Open Technology Cultures (Princeton: Princeton University Press, 2020). All quotations that appear here are taken from chapter 3.


In 2015, the code repository GitHub announced that it was adding a “code of conduct” for open source software projects that it maintained.1 Inspired by diversity statements and similar codes being adopted in other programming communities, the code was meant to signify that these projects were welcoming spaces, and to establish baseline expectations for how people there would treat each other. In the spirit of open source, GitHub would make its code available for other projects to adopt and reuse. GitHub’s proposal sparked vigorous discussion in hacking and open source communities among people who agreed and disagreed with codes of conduct. Why did GitHub feel the need to add such a code? Why was this change potentially controversial? This case study uses the GitHub example to focus on unspoken rules and assumptions that have guided open source communities, draw out some potential shortcomings, and discuss community efforts to institute changes as exemplified by the code of conduct.

“Hacking” is a mode of technical and cultural production. Many undertakings might now be considered variants of hacking, from modding cars to crafting to do-it-yourself projects. A more bounded meaning centers around computer programming. In its most expansive sense, hacking is a mode of engaging with technology: breaking technology down and building it up in a new form to gain skills, to explore, to create a new useful object, or as an expression of curiosity. Rather than focusing on the output—lines of computer code, picked locks, or other artifacts—we could consider hacking as a worldview. Participants in the free/libre and open source software (FLOSS) community apply this worldview to reinterpret copyright law, in which alternative licensing rules are applied to the writing and distribution of software. (Copyright is a means of assigning property rights to products of thought and fabrication.) “Open technology” simply designates porting the principles of FLOSS to hardware: “open” is the key term. For example, an Arduino is an open circuit board microcontroller, designed to be programmed with open source software. In their early days, free software projects of the 1990s were “experiments in coordination … [They were] exemplars of how ‘fun,’ ‘joy,’ or interest determine individual participation and how it is possible to maintain and encourage that participation … instead of narrowing the focus or eliminating possible routes for participation.”2 This meant that people who showed up to participate were responsible for cultivating their own routes to satisfaction: finding fun, joy, and interest in the projects. For hackers, cultural and technical artifacts should be left open to allow endless modification, reinterpretation, and re-fashioning toward purposes beyond those for which they were originally created.3

This sense of openness also relates to how FLOSS communities are governed: the projects were, in theory, open and available for interested parties to show up and plug in. But a fervent commitment to openness has led to some oversights, including a central contradiction in hacking and open source software communities. On the one hand, “openness” means that communities are (in theory) open to whomever shows up to participate. This perpetuates a notion that if some people are not there, it is because they do not wish to be, or they are unworthy of being included because they lack technical skills. Community members have claimed that they are satisfied by including the “best and brightest,” who self-select and prove their merits to the rest of the group.4 Norms of civility could vary across specific projects, but in practice the wider FLOSS milieu tolerated or even bred antagonistic interactions, such as “flame wars” (escalatory disagreements in public view).5 On the other hand, hackers have been evangelists for their mode of technical engagement; they believe that more people hacking will lead to the creation of more, new, and better technologies, and they would like to see their mode of engaging with technologies become more widespread. There is a potential tension between growing hacking communities and being “open” to all modes of interaction, including ones that might “turn off” newcomers.

This case presents FLOSS hackers who focused not on hardware or software, but rather on hacking itself. In the early years of the twenty-first century, as free software communities matured, they began to recognize that their contributor bases were overwhelmingly composed of men. A 2006 European Union (EU) policy report revealed that fewer than 2 percent of free software practitioners were women, which catalyzed attention to these matters.6 This was shocking to many people: even though computing education and workplaces in North America and Europe were known to be men-dominated, the rate of participation by women in FLOSS communities was even lower than in academia and industry. With increasing urgency, conversations turned toward including and supporting individuals defined as “others” in open source and hacking. The “rough consensus and running code” ethos that supported practitioners’ self-organization around technical production was reoriented to hack their communities. One common intervention was the introduction of codes of conduct, intended to formalize rules for how people should behave when they came together to collaborate on coding and hacking.

Challenging the Dominant Culture: Gender, Race, and Inclusion in FLOSS/Hacking

In a 2013 blog post, a woman wrote, “When trying to explain how hostile an environment the geek world can be, I’d tell people, ‘I’ve been attending cons [conferences] of various types since I was thirteen, and I have never, not once, been to a con where I wasn’t harassed.’” The author went on to describe attending a particular open source software conference for the first time, including her apprehension beforehand at entering a new community and her pleasant relief that the new conference experience was one where she “felt safe the entire time,” where “nobody made inappropriate sexual comments, touched me without my permission, or took creepy pictures of me.” In the post, she argued in favor of conferences adopting codes of conduct (CoCs), as this one had. While she did not attribute her positive experience solely to the code of conduct, she said it was useful for laying out rules and accountability for everyone in attendance; it also broadcast that the organizers of the event cared about the experiences attendees would have. She said that codes of conduct “tell me what the community’s standards are. They also tell everyone else what the community’s standards are, which is perhaps their biggest effect: telling people what behaviors are unacceptable can prevent problems from occurring at all.”

Her post was not unique. In the 2010s, agitation for codes of conduct was a major phenomenon within open-technology circles. Advocates for greater diversity in FLOSS and hacking insisted on the adoption of clear rules for comportment in various spaces where open-technology communities congregate (which spanned both online and offline spaces: Internet Relay Chat channels, mailing lists, user group meetings). Codes of conduct were controversial in various ways. Some people wondered whether they might provide a false sense of security and urged great specificity, including concrete steps for carrying out and enforcing policies; as one commentator wrote, “We cannot even be sure that anti-harassment policies are anything other than security theater.”

Substantially more criticism held that codes of conduct were unnecessary or detracted from the “real” focus of open source projects, or represented moral policing that critics found unsavory. Arguments about these topics are entirely too many to enumerate, but a fairly typical line of discussion occurred in reaction to GitHub’s proposed code of conduct in 2015. When it added a CoC, the open source community exploded with discussion, such as this comment thread on the site Hacker News:

Commenter A: Code of Conduct defines problems and could turn anything funny, innocent, etc. into an excuse to ruin someone’s life. 9 out of 10 times it’s someone who doesn’t program ([like Woman X or Woman Y7]) who will be attacking someone who actually contributes.
Commenter B: You seem to be continuing to operate under the assumption that only people who can code, are capable of contributing to a project. There are so many things that can be done to contribute to a project, that don’t involve writing a single line of code. Testing, evangelism, documentation, support, etc, etc. Why should attempting to improve the culture of a project, be any different?8

Many who opposed CoCs understood the conflict to hinge on whether an open-tech space should be more like a “clubhouse,” a freewheeling environment with a come as you are mentality, that welcomes all modes of expression, or more like a workplace, with a list of rules handed down by a human resources (HR) department and the attendant threat of punishment for perceived transgressions (as indicated in the line about “something innocent or funny being an excuse to ruin someone’s life”). They defended the former and pushed back against the latter.

First, and most saliently, in the comment thread above, there is conflict over gender. Commenter A invokes the full names of two women (here referred to as Woman X and Woman Y), both of whom had been subjects of prior controversy in open source communities. This commenter also suggests that these people, not being programmers, are less valuable to the community, and indeed represents them as distractions, detractions from and even threats to the “real” work of programming. The underrepresentation of women in open source overall has been found to be more nuanced; even before the 2006 EU study, scholars and practitioners recognized that while women were particularly absent in the work of coding, they were more present and yet rendered invisible in noncoding work, such as nongovernmental organization work that supported the development of FLOSS, documentation translation, book editing, teaching, and tutoring.9 So we should interpret this argument over “programming” (as invoked by Commenter A) versus “testing, evangelism, documentation, support, and improving the culture of the project” (as Commenter B writes) as informed by, if not reducible to, a conflict over the roles, presence, and relative value of men versus women in open source.

Communal tech spaces online or off have tended to retain a clubhouse come as you are ethos. Open-technology communities were spaces of refuge for their participants, spaces of sanctuary where “geeky” men could freely congregate. There, geeky men and boys were free to explore and celebrate technology without workplace rules, and without feeling constrained by pressure to conform to other stereotypes about masculinity. (Think of the difference between the computer “geek” and a football “jock” in a Hollywood movie, for example.) Even if gender was never mentioned in these spaces, they tended to be implicitly masculine. They were separate from the workplace (where HR could be watching), but also from “feminine” parts of homes: historically, men have been accustomed to carving out space in garages, basements, and ham radio shacks, where they are free to code and tinker without disrupting the domains of the home that have been constructed as feminine, like the kitchen, living room, and marital bedroom.10

As another commenter noted in a separate discussion about the CoC proposed by GitHub, “Back in the days [when] open source was the nerd elite [it was] super unwelcoming towards anyone that didn’t strive to excel at what they did. Not the most friendly environment, but it certainly pushed people to do their best in order to gain acceptance.”11 This comment illustrates how some open source members thought of themselves as a “nerd elite,” “striving for excellence”; it also draws attention to how tinkering with technology is tied to expert knowledge and potentially to elitism. And it hints at how this elitism may breed competitive dynamics in collaborative projects. People who could demonstrate technical “chops” and value for a project were welcomed and celebrated; people whose abilities were still in development would ultimately be welcome if they could learn, but they would possibly need to tolerate hazing along the way. (Many older coders recall being hazed while they were learning, indicating that this was a normal practice, if not a universal experience.) Though gender is not explicitly mentioned by this poster, to be comfortable with competitive displays and feeling unwelcome along a path to greater skill acquisition can mean being comfortable with masculine interpersonal styles, which are especially common in technical realms where virtuosity is prized.12 This does not mean that all feminine-identifying people are put off by such interactions, nor that all masculine-identifying people are comfortable with them, of course.13

The notion of a nerd elite also reinforces this as a space outside the mainstream. Originating as terms of insult, nerd and geek have been reclaimed as self-aware and even fond labels within these communities. The nerd elite refers to a community of people who have something in common with each other, but are set outside of a wider social milieu; they both reject and are rejected by “the mainstream.” (“Nerd elite” would almost be a contradiction in terms, except for the solidarity it offers among fellow outsiders.) Thus, a sentiment that a space for hacking is “our place” is a strong one and attachment to it is dear. The community is encoded with certain assumptions about who belongs there, and what sorts of behavior are anticipated, tolerated, and celebrated.

The commenter discussing the “nerd elite” also offered the provocative opinion that “if coding wasn’t one of the higher paying careers out there these days with relatively low entry barriers for those willing to learn, in an otherwise [sh*tty] job market, with startups being perceived as cool as well, there sure as hell wouldn’t be any women looking to get into it (except asians [sic], which were always pushed towards STEM careers by parents).” This underscores several notions that are key to understanding some of the churn, conflict, and outcry around diversity issues here. First, the commenter notes that the coding “clubhouse” was not only historically unwelcoming, but actually undesirable to outsiders; it is implied that this was a mutually satisfactory state of affairs for those both inside and outside the clubhouse.14 Second, women are the most obvious class of outsiders. Third, the commenter invokes race as well, implying that cultural and familial backgrounds of Asian women might have predisposed them to looking twice at programming even despite their outsider status as women or girls.15 The dominant cultural category of whiteness is not named, but in total this comment can be read as an indicator of white masculinity being prominent within open-source communities.16 Of course, there is a deep irony in the fact that those who found respite from a world in which they might feel excluded or persecuted would reproduce some of these dynamics in their own sanctuaries.

No Code of Conduct? (Are Online Spaces Different?)

People also pressed for a (somewhat paradoxical) “no code of conduct” policy for online spaces in the heat of ferment around GitHub’s CoC. In late 2015, someone wrote a script for a no code of conduct (NCoC) that could be added to the root directory of a project and described the NCoC concept in a Q&A page, “What is NCoC.” The page is more a defense of various traditional norms and values of open source than an exhortation to conduct open source projects without rules of any kind. In particular, it emphasizes that people’s political or social identity should be irrelevant in open source: “We don’t care if you’re liberal or conservative, Black or white, straight or gay, or anything in between! In fact, we won’t bring it up, or ask. We simply do not care.” This strongly echoes the famous and influential “Declaration of Independence of Cyberspace” penned by John Perry Barlow in 1996, which reads, “We are creating a world that all may enter without privilege or prejudice accorded by race, economic power, military force, or station of birth. We are creating a world where anyone, anywhere may express his or her beliefs, no matter how singular.”17 The author of “What is NCoC” furthers this parallel in the following statement: “If you limit yourself to participating in things that only have codes of conduct, then you’re limiting yourself as a human being on this marvelous place we call the internet. … The internet is a big place, you should prepare yourself to deal with it.”

The author did note that non-internet communications “Understandably are different. Often sane communities will have a CoC that is unique to their physical location, and/or event. … We are talking about the internet here, not physical meet ups, and that requires we do not care about the unimportant parts of how people talk.” In other words, the author defends online projects as spaces that transcend how social identity is lived offline. Though the author allows for differences in social position as having the potential to affect how people relate or communicate offline, the ideal is for none of this to matter in the realm of open source and online communication. Implicitly, none of this should matter at all (identity is part of “the unimportant parts of how people talk,” unlike code), but the author does not go so far as to claim this is actually true in real life. Instead, “the marvelous place we call the internet” is a place to experiment with and then practice leaving behind categories of social difference. Thus, it is perhaps unsurprising that the suggestion to add a bunch of rules to open-technology spaces has been met with dismay and even hostility, as it undercuts the fantasy that the internet is a space for social leveling. This fantasy had been borne out in some ways for the nerd elite, who found community in online association—the “fun” and “joy” of assembling together in shared interest and problem-solving. Arguably, their experience was one factor in their resistance to acknowledging and accommodating other kinds of experience and difference.

Advocates for codes of conduct, meanwhile, saw the issues rather differently. They were often people who have not experienced open-tech communities as spaces where one could join (online or offline) on an equal footing with other members regardless of social identity. This exchange, also from the 2015 Hacker News thread, begins with a familiar line of argumentation against CoCs:

Commenter C: The only thing this code of conduct does beside state the obvious (behave like adults) is the implied distrust expressed by introducing it in the first place: that without being nannied into proper behaviour, we would all act like vile animals. Generally I find such nannying deeply offensive.

The commenter held that codes of conduct are beyond unnecessary; indeed, they are presented as belittling and divisive. Another commenter then chimed in in favor of CoCs:

Commenter D: Have you guys missed the numerous controversial issues that consistently come up around this? I really don’t understand the viewpoint that these guys are just coming out with a rule book apropos of nothing except their desire to nanny and police people.
Is it possible that you’re a part of the class that, yes, doesn’t experience the negative aspects of the community, and thus has no empathy for those that do? …
… Personally I find that attitude an excuse to be callous and lazy. Actually taking the time to understand other people and their issues, truly trying to get outside of your own biases and experiences and put yourself in their shoes, is more impressive to me.18

Commenter D defended the idea that even if many people have never themselves experienced troublesome behavior in open source communities, reports from people who claimed they had should not be dismissed. The comment also leaves open the possibility that one person’s merely “not warm and helpful” experience in a given community might be experienced as extremely alienating to another person. This commenter raised the potential for differences in how participants are situated, and felt that CoCs may do some work to raise awareness and empathy levels about these differing backgrounds and experiences. Commenter C, meanwhile, argues for personal responsibility, equality among adults, and, implicitly, the right to self-determine and self-organize, without the introduction of “distrust.”

Though patently contentious, codes of conduct have gained momentum as one form of intervention into open-technology communities. Plainly, there is a spectrum of belief and practice concerning how to characterize, let alone solve, the problems these commenters identify and tussle over. Even when people are not arguing for free speech absolutism (including the right to be as “vile” as possible), how to open up the ranks of open technology to more people presents formidable challenges.

Hacking the Present and Future of FLOSS

At the origin of FLOSS and hacker culture, there was a tension between the individualized pleasure and agency that FLOSS had nurtured, versus longings for a collective and even progressive formation that is inclusive—one might say open—toward many different kinds of people.19 Over time, the tendency to overlook adversarial behavior that expanded the freedoms of some participants at the expense of others came to be viewed as too harmful to be allowed to persist. Codes of conduct were one proposal to hack the communities where FLOSS enthusiasts congregated to collaborate and build projects through code and electronics.

The contestations here, about making software and hardware communities more welcoming, more aware of off-putting behavior, and more aware of historical patterns of inclusion and exclusion, show technical communities in the throes of articulating their own values. In spite of the arguments that GitHub’s decision spawned, when GitHub changed its own rules to add a code of conduct, it was responding to conversations happening across FLOSS and hacking communities. More and more people were coming to believe that this sort of change was needed to make these spaces more welcoming, more self-aware, and more inclusive. At the same time, we might ask whether small “hacks” to the community standards for open source software groups can be effective for addressing persistent and larger-scale historical and structural inequalities.

Discussion Questions and Activities:

  • How would you define “community norm”? (What is an example?)

  • How might a “norm” be different from a formal rule? Why does this matter?

  • Why did open source communities introduce codes of conduct? What problems are they meant to solve, and are they effective? 

  • Review the GitHub Code of Conduct template here: https://github.com/probot/template/blob/master/CODE_OF_CONDUCT.md
    Do you think this is controversial? Why or why not? What changes would you make to this document? Are there other changes besides a code of conduct you might introduce in a software community to make it more inclusive or otherwise try to change behavior there?

  • Peer share: Can you think of examples from your own life and participation in school, work, or other settings that have parallels to the issues in this case? What kind of solutions do you think would be most effective, and why?

  • Do you think that changes like adding a code of conduct in an open source community will have effects in the wider society? Why or why not?

Bibliography

Benjamin, Ruha. Race After Technology: Abolitionist Tools for the New Jim Code. Cambridge, UK: Polity Press, 2019.

Callahan, Brian, Charles Hathaway, and Mukkai Krishnamoorthy. “Quantitative Metrics for Generative Justice: Graphing the Value of Diversity.” Teknokultura 13, no. 2 (2016): 567–86.

Coleman, E. Gabriella. Coding Freedom. Princeton, NJ: Princeton University Press, 2012.

Cowan, Ruth Schwartz. More Work for Mother: The Ironies of Household Technology from the Open Hearth to the Microwave. New York: Basic Books, 1982.

Daniels, Jessie. “Race and Racism in Internet Studies: A Review and Critique.” New Media & Society 15, no. 5 (2013): 695–719.

Douglas, Susan. 1987. Inventing American Broadcasting, 1899–1922. Baltimore: Johns Hopkins University Press.

Dunbar-Hester, Christina. Hacking Diversity: The Politics of Inclusion in Open Technology Cultures. Princeton, NJ: Princeton University Press, 2020.

Haring, Kristen. Ham Radio’s Technical Culture. Cambridge, MA: MIT Press, 2006.

Kelty, Christopher. Two Bits: The Cultural Significance of Free Software. Durham, NC: Duke University Press, 2008.

Jordan, Tim. “A Genealogy of Hacking.” Convergence: The International Journal of Research into New Media Technologies 23, no. 5 (2016): 528–44.

Lin, Yuwei. “Women in the Free/Libre Open Source Software Development,” in Encyclopedia of Gender and Information Technology, edited by Eileen M. Trauth, 1286–91. Hershey, PA: Idea Group, 2006.

Margolis, Jane, and Alan Fisher. Unlocking the Clubhouse: Women in Computing. Cambridge, MA: MIT Press, 2003.

Nakamura, Lisa. Digitizing Race. Minneapolis: University of Minnesota Press, 2007.

Nafus, Dawn. “‘Patches Don’t Have Gender’: What Is Not Open in Open Source Software.” New Media & Society 14, no. 4 (2012): 669–83.

Nafus, Dawn, James Leach, and Bernhard Krieger. Free/Libre and Open Source Software: Policy Support. FLOSSPOLS D16, Gender: Integrated Report of Findings. University of Cambridge, March 1, 2006. https://www.researchgate.net/publication/264799720_FLOSSPOLS_Deliverable_D_16_Gender_Integrated_Report_of_Findings.

Oldenziel, Ruth. Making Technology Masculine: Men, Women, and Modern Machines in America, 1870-1945. Amsterdam: Amsterdam University Press, 1999.

Reagle, Joseph. “‘Free As in Sexist?’: Free Culture and the Gender Gap.” First Monday 18, no. 1 (2013).

Wajcman, Judy. “From Women and Technology to Gendered Technoscience.” Information, Community and Society 10, no. 3 (2007): 287–98.

Comments
0
comment

No comments here