Hey folks,

Apologies if this has been shared here before. It's a very interesting paper by a UC Berkeley grad student about the homogeneity of FLOSS communities. It's super-articulate and smart, and there is lots here that's relevant to us.

Thanks to Kat Walsh for sharing this with me :-)

Thanks, Sue

http://littlegreenriver.com/stuffs/Outreach-Diversity-FOSS.html

"Suck It Up, Princess": Outreach and Diversity in FOSS Communities

Karen Rustad

May 13, 2011

Introduction

The development and proliferation of free and open source software (FOSS) is a well-loved example in the academic literature, used to explain the phenomenon of decentralized, gift-economy, post-industrial "barn-raisings" and situate them as viable modes of production (Kollock 431-2). While FOSS has been well analyzed from technical and economic standpoints, there is surprisingly little sociological or anthropological work on the people who belong to the FOSS community and contribute to FOSS projects. Who it is that builds these crucial underpinnings of the information economy likely has significant implications for what kinds of software get built, who can use it, and any number of other downstream social and economic effects.

Massive volumes of ink and bits have been spilled documenting the demographics of open source software contributors and lamenting the hugely disproportionate lack of women and non-white people among them. Surveys of FOSS projects have found that women make up, at best, 5 percent of FOSS contributors; a more likely figure is around 2 percent (Ghosh). For many FOSS contributors, these figures are unfortunate but immutable constants; within the community there is skepticism that they can be improved much, if at all. Most FOSS communities see themselves as meritocracies; many participants honestly believe that all that matters with regard to whether you can join or gain status within the community is whether or not you produce smart ideas and good code. As the current chair of the Python Software Foundation, Jesse Noller, writes,

I truly, fundamentally believe that OSS is is the perfect proof that anyone and everyone can contribute to something. Why? Code and projects are blind – or if they aren’t, they should be. They don’t care if you’re a sentient ham sandwich, they don’t care if you don’t have the proper schooling, how old you are, the color of your skin, or your religious beliefs. They don’t care where you are located or what you did before you contributed something. They just care about what you have contributed – doc patch, code patch or feature. That thing you have submitted should be able to stand on its own merits, regardless of anything outside of that atomic change. (Noller)

Consistently with this perspective, most FOSS developers attribute the lack of diversity in FOSS to women and other groups simply not being interested in contributing (Krieger 16). This purist meritocratic outlook is noble in some respects, but it ignores or even masks the realities of community politics, nasty flamewars, bias incidents – all the messy human factors that even geeky, avowedly-rationalist FOSS developers are heir to and which have real effects on who chooses to work on FOSS and who does not.

Clearly part of FOSS' diversity problem is inherited from the larger technology community; only 20 to 30 percent of tech industry workers are female, and women's share of undergraduate computer science majors has dropped from 20 percent to as low as 12 percent (Krieger 4, Stross).1 However, even that low proportion is almost an order of magnitude higher than FOSS's share of women. Additionally, FOSS also has disproportionately few South Asian contributors, despite the fact that this group is actually overrepresented in the tech industry as a whole (Laroia, "Diversity"). Clearly, therefore, there exist barriers to diversity in FOSS that are not simply the same issues plaguing CS departments and technology companies in general, but are unique to the FOSS community.

Particular sexist incidents within the FOSS community, such as FOSS conference presenters including pornographic images in their slide decks2, the head of the Free Software Foundation declaring that it was a sacred duty of community members to relieve "women who have never used EMACS" of their "EMACS virginity"3, and cases of nonconsensual groping and sexual assault at FOSS conference after-parties4, are fairly well-documented (Aurora). Such incidents are often cited as the reason for why so few women are active in FOSS. However, people typically would only encounter such explicitly sexist attitudes and incidents once they were already involved in FOSS; such incidents certainly could turn off new female contributors and make them leave the community, but it seems unlikely that they would affect their rate of initial entrance into FOSS so dramatically as to be the only factor at work.

Less well explored is implicit sexism in how open source projects systemically attract and retain new contributors (or, more accurately, usually fail to). In this paper, I argue that unintentionally sex-biased mechanisms of "recruitment" in themselves may account for FOSS' demographic imbalances.5 If so, this suggests that the recent wave of new outreach efforts to improve the experience of first-time contributors and provide clearer entry points into FOSS may have the side effect of remedying the community's diversity problem. I focus mainly on sex bias because that disparity has the greatest amount of relevant coverage and commentary within the FOSS community. However, the goal is to point out unacknowledged obstacles and filters in FOSS recruitment that would likely account for some amount of underrepresentation of racial, ethnic, linguistic, discipline-based, and other minority groups as well.

Why do FOSS contributors get involved?

It may be a surprise that a majority – about 54 percent – of FOSS contributors benefit materially from their participation in the FOSS community (Ghosh). Eighteen percent of FOSS contributors are paid to administrate FOSS; almost 16 percent are paid to develop it. FOSS developers also benefit indirectly from their FOSS participation; almost 18 percent of contributors report getting a job because of their FOSS experience.

Much academic literature and research in motivations and organizations is devoted to the distinction between intrinsic and extrinsic motivations. Specifically, intrinsic motivations apply to "activit[ies] undertaken for one's immediate need satisfaction. Intrinsic motivation 'is valued for its own sake and appears to be self sustained'" (Osterloh & Frey 539). Extrinsic motivation, on the other hand, applies to activities that "satisfy [participants'] needs indirectly, especially through monetary compensation" (Osterloh & Frey 539). These two forms of motivation do not typically mix evenly; experiments have found that introducing extrinsic motivators into a primarily-intrinsically motivated activity reduces participants' levels of intrinsic motivation. This effect, called the "crowding out" effect, is sometimes so severe that the addition of extrinsic motivators actually lowers participants' overall motivation levels (Osterloh & Frey 541-2). One might expect that the external rewards that many contributors now receive for working on FOSS software, then, would reduce the amount of intrinsic motivation within the community.

Nonetheless, FOSS contributors' motivations remain primarily intrinsic and appear to be "un-crowded-out." Ghosh et al's 2002 survey found that the number one reason developers get involved with FOSS was to learn and develop new skills, selected by almost 80 percent of respondents. About one-third of respondents join FOSS to "participate in a new form of contribution"; almost half participate to share their knowledge and skills; thirty percent are motivated by the ideological belief that software should not be a proprietary good (Ghosh). Extrinsic motivational factors are significantly less widely held; only 23 percent of respondents joined FOSS to improve their job opportunities, and only 4 percent join to make money (though this figure jumps to 12 percent as a reason to remain a contributor) (Ghosh). It appears that FOSS contributors start out nearly universally as volunteers, then eventually either find paid FOSS-related work or notice benefits from their FOSS experience in their job search generally. Given the continued importance of intrinsic motivational factors among experienced FOSS developers, extrinsic rewards for FOSS work do not appear to crowd out their initial motivations. Research specifically into the motivations of contributors to the Apache Software Foundation's web server project, Jakarta project, and XML project (all free software) support this conclusion; being paid to work on Apache did not affect contributors' intrinsic motivations, yet did increase their level of contribution as well as their status motivations to contribute (Roberts).

How are FOSS contributors typically recruited?

Most current FOSS contributors underwent a slow progression from "newbie" to recognized contributor with commit access to a given FOSS project. This traditional mode of recruitment is uncoordinated and almost entirely passive on the part of the project, yet appears regularly in retrospective accounts of how current developers got involved (Bolton). First, the individual is exposed to a given software project, prompted by their need for a given piece of software for school, work, or personal use. The individual may also be exposed to free software generally, perhaps through a work such as Richard Stallman's Free Software, Free Society or the GNU Manifesto. The individual uses the software and perhaps lurks on the software project's mailing list. After a period of time – often years – the individual finds a bug in the software or finds that they have a need that the software does not quite meet. Given sufficient motivation and technical savvy, the individual writes a patch of the software to "scratch their itch" and sends it to the project's maintainer. If the patch meets the project's standards and the project maintainer agrees that it is an improvement, he or she eventually integrates the patch into the official version of the software. After a few repetitions of the itch-patch-submission cycle, the project maintainer is likely to decide that the individual is trustworthy and useful enough to merit commit access for the project. While technically speaking, the individual has been a "contributor" to FOSS ever since they wrote their first patch, typically it is only at this point that the individual is formally recognized as being part of the FOSS project's community.

While most current FOSS contributors got involved through this traditional decentralized, depersonalized "recruitment" process, FOSS projects are starting to develop and use more modern, interventionist methods of recruiting new contributors. For example, Ubuntu has organized special "hug days" (bug-triaging days) where they explicitly ask for help from potential contributors on their mailing list and make sure that their IRC channel is staffed with veteran developers to assist new people.6 In spring 2011, FOSS outreach project OpenHatch partnered with desktop FOSS projects such as GIMP and Vidalia to create "Build It" days – special events where a given project invites new contributors to get involved and provided special advice and assistance in getting the software built on their computers (so that they would have the necessary development infrastructure set up and working so they could change the software and write patches later).7 FOSS-related conferences typically offer "sprints" – a couple days of the conference, usually taking place after the official talks and sessions, for participating projects to spend coding and recruiting new members from the conference attendees.8 Sometimes FOSS projects will organize in-person meetups and hackathons on their own as well. These in-person hacking sessions provide a clear, focused space for development and community-building.

Some large FOSS projects also have explicit mentorship programs and support groups, intended to help get new contributors involved and make the community more welcoming. Some groups, such as Debian Women and Ubuntu Women, are specifically targeted at helping minority populations get a foothold in FOSS.9 10 Others, such as Fedora Mentors, are broadly targeted to new contributors of all sorts.11 Both sorts of mentorship programs have varying levels of success, depending on how many willing, energetic mentors they can attract and how effectively they make potential mentees aware of their existence.

Finally, likely the most formalized entry point into FOSS development to date is Google's Summer of Code (or GSoC) program. GSoC gives students stipends to spend the summer working on improvements for a particular FOSS project. Since 2005, GSoC has brought together over 4500 successful students and over 3000 mentors (Google). While GSoC has been highly successful in generating open source code and giving students real-world programming experience, its record on integrating new contributors into the FOSS community is more spotty. In 2006, at least, only 30 percent of GSoC participants continued to contribute to their mentoring organizations' projects after the end of the summer (Kerner). The proportion of continuing contributors varied widely from project to project, however, and there is some thought that practice and advice on how to mentor well might increase this figure; to that end, for the 2011 batch of GSoC participants FOSS veterans Donnie Berkholz, Lydia Pintscher, and Kevin Smith posted a list of dos and don'ts for GSoC mentors on Google's open source blog.12

The additional structure and formalism of GSoC appears to attract contributors who would otherwise have been too intimidated to get involved in FOSS. As current co-maintainer of FOSS project Drupal and 2005 GSoC alumna Angela Byron stated in an interview:

I held a...strong belief that everyone who actually worked on open source software was really smart and that I, being only a lowly community college student, couldn't possibly participate on that level. [...] Then...one of my instructors told me about Google Summer of Code (GSoC), a program which provides stipends to students to work on open source projects over the summer. This poked a tiny little hole in the "you must be THIS smart to contribute" wall I had built up in my head, because I figured, hey, they know I'm a student so they must know I don't know everything yet... So I figured I would apply and see how it went. (Druckman)

Even despite uneven success in helping students build enduring relationships to the FOSS projects they work on over the summer, by creating a clear, concrete entryway into FOSS development and making it clear that that entryway is not just for the best and brightest but for anyone seriously interested in helping write code, GSoC's structure has helped contributors join FOSS who would not have otherwise been motivated or successful under the community's tradition of benign neglect in recruitment. Through GSoC and other recent, more-proactive innovations in FOSS recruitment, many projects are discovering, in a nutshell, that "there are people waiting to be included, who are just, not, and if we simply ask them, they would join." (Laroia, "Get") What assumptions are embedded in current FOSS recruitment practices?

Typical passive methods of FOSS recruitment filter the pool of potential contributors in three main ways, each with implications for why women or other minorities would be less likely to get involved.

1.) Homogeneity Through Friend Networks

An individual's initial contact with FOSS often happens person-to-person, via a friend, sibling, or classmate.13 Stereotypically, first FOSS contact looks like two teenagers hacking on a PC in the basement, and one of them suggesting that they install Linux for fun. Given FOSS's existing gender and ethnic makeup, the teenager making the suggestion is almost certainly white, male, and geeky; because "birds of a feather flock together," and young people's friendship networks tend to be homophilous on gender and ethnic dimensions (among others), the second teenager probably shares these characteristics (McPherson, Smith-Lovin, & Cook). Similar effects occur later on as well, in contexts such as FOSS user groups or meetups: "One of the largest reasons our meetup groups are less than five percent female, in a technology world where 20 to 30 percent of the people are female,...is we invite people to the meetup group who we know and our friends are probably people like us" (Laroia, "Get"). Homophilous diffusion of FOSS naturally helps perpetuate its current demographic monoculture.

2.) Requisite Time, Confidence, and Previous Exposure

Most FOSS projects have poorly-written, incomplete documentation. A significant number have virtually no documentation at all. Since the FOSS community is dominated by developers (with few managerial types, technical writers, designers, or other sorts of stakeholders that typically contribute to software within firms), projects both lack sufficient volunteers with the appropriate skill sets to write good documentation and tend to underprioritize documentation writing and other non-coding parts of their project. As Gina Trapani notes,

[I]nterface design [along with other non-code contributions] doesn't get nearly the respect and prioritization it should by typical OSS engineers. [..] The solution isn't simply getting more designers and UX experts involved in open source, it's something much more difficult: changing community values around those skills. Miliano writes:

For a designer to contribute to an open source project, there would have to be developers committed to implementing the work, to work on “polish” and “froofy things” instead of “real features” and other “important things.” That’s a hard nut to swallow, and what volunteer project owner will ask all their volunteer contributors to, please, stop working on your pet projects within this codebase and let’s actually cut features and work on UI and usability and design?

[...] The key here is to prioritize design and usability upfront, rather than accept a mess of software with plans to slap a pretty veneer on afterwards. (Trapani)

Recently there have been a few initiatives to make good, complete documentation an integral part of FOSS development, most notably the Read the Docs project.14 However, the need for this project and the fact that it stands out prove the poorly-documented rule.

Poor documentation drastically narrows the pool of potential contributors to a given FOSS project in three ways. First, it selects for highly motivated people with a lot of free time. Figuring out how to download, satisfy dependencies for, modify, build, and push patches for a given piece of software is far more frustrating and takes far longer if the steps for how to do so are vague, erroneous, or incomplete. This disproportionately filters out potential female contributors because most women have significantly less leisure time than men. On average, male undergraduates have more than twice as much free time as their female counterparts (Heeter). This gap continues into adulthood; while seven out of ten parents believe that child care duties should be distributed equally between parents, moms report being the primary caregiver two-thirds of the time (Dunnewind). Women also "spend about three to seven times as many hours as men on cleaning and laundry tasks" (Dunnewind). With women disproportionately taking on the "second shift" of running dual-income households, they are less likely to have the time and energy to pursue hobbies such as FOSS development.

Second, poor documentation selects for people who are highly confident in their technical skills, irrespective of their actual ability. Getting involved in a FOSS project for the first time, especially one without good documentation, is an act of faith. Without help and support from veterans of the project, there is no guarantee that a new contributor's flailing efforts to get their dev environment working will ever pay off in the form of improvements and patches. This is especially true if it is one's first time contributing to a project. Veteran developers may not be familiar with the specific technologies or packages used by a new project that they want to work with, but because they have gone through the build process successfully before, they are more likely to have faith that they will figure it out eventually. In the absence of effective documentation or mentorship, new developers must substitute experience with sufficient bravado and confidence in their own technical capabilities to believe that sooner or later, "when things go wrong, you can solve it" (Buckland).15

Men are more likely to have this critical level of "bravado" than women. Women hold themselves to a higher standard than men, particularly in science and technology matters. In a study of gender and self-assessment using a fictitious spatial reasoning skill, Correll found that "women and men held different standards for what constituted high ability... [W]omen believed they had to earn a score of at least 89 percent to be successful, but men felt that a minimum score of 79 percent was sufficient" (Hill 65). Women also rate their abilities lower than equivalently-talented men do. (Hill 61) As software engineer Jean Hsu writes,

When I walked by a departmental career fair, I paused to look at some of the companies I might want to apply for next semester, and [Professor Li] told me to sign up for some interviews for that day. I said I didn't feel prepared and wanted to wait a semester until I felt like I had more of a basic foundation. He turned to a professor next to him and said "Jean doesn't know how good she is." He probably would not remember that exchange, but for me his support was eye-opening. I realized that while I did decide to major in CS fairly late in the game, I really was good at it, and my harshest critic was really myself. (Hsu)

Having high standards for themselves may push women to succeed – indeed, by some measures women actually do better than men in required science and technology-related classes. (Hill 21)

However, the accompanying erosion of women's confidence in their abilities also closes many doors. High-achieving women in academic and technical fields often also struggle with "impostor syndrome," denigrating or explaining away their achievements as luck or accident rather than daring to attribute them to their own abilities and hard work. (Kanazawa) While both men and women can suffer from impostor syndrome, it appears to be more common among women. This pervasive feeling of being an "impostor," "fraud", or "wannabe" makes people be less willing to put themselves forward, feeling that they are not qualified, by eg: not applying for jobs, promotions, and other employment opportunities; not submitting papers to conferences or journals; disclaiming or understating their experience/skill when speaking or writing; or nervousness about talking to others in their field, especially if those others are perceived as highly skilled/experienced" (Geek Feminism Wiki, "Impostor")

The confidence gap between men and women does not simply result in harmless humility – it affects women's willingness to take risks and the career paths that women eventually choose. As Correll found,

boys were more likely than their equally accomplished female peers to enroll in calculus [and and choose a college major in science, math, or engineering] not because boys were better at math but because they believed that they were better at math. [...] If girls do not believe they have the ability to become a scientist or engineer, they will choose to be something else. (Hill 61)

Thus, it is likely that the confidence gap between men and women, particularly in relation to self-assessed technical ability – could filter out many potential female contributors as they quickly become discouraged when first attempting to work on a FOSS project or, believing themselves not "l33t" ("elite") enough, never try to get involved in the first place. The reason for Angela Byron's delayed entry into FOSS contribution bears this hypothesis out:

I've been interested in free software ever since I first heard the term back in 1995, back when I completed my first successful Linux installation... I became a fierce advocate of open source alternatives among my family and friends, and I was totally "that person" in school... However, I held an equally strong belief that everyone who actually worked on open source software was really smart and that I, being only a lowly community college student, couldn't possibly participate on that level. So I would silently cheer these people on, [...] wistfully hoping that one day, far into the future, maybe after I had 30 years of experience or something, I could someday join their ranks. [...] Once I got to "this side" of the contributor wall I realized how silly the mythos I had in my head about open source contributors was. While there are indeed very Einstein-level smarties out there contributing to open source, most of them are just people like me... (Druckman)

Women are also more likely than men to see their talents and intelligence as fixed, unmutable values. Linda Babcock and several colleagues developed a survey and scale to measure individuals' positions on a "turnip" to "oyster" spectrum – whether one's attitude better resembled "you can't get blood from a turnip" (a fixed, accepting mindset) or "the world is your oyster" (a flexible, opportunistic mindset) (Babcock & Laschever 19). They found that women were 45 percent more likely than men to score on the "turnip" side of the scale (Babcock & Laschever 20). This attitude differential likely stems from differences in how girls and boys are taught in school:

Girls, who develop self-control earlier and are better able to follow instructions, are often […] told that we are "so smart," "so clever, " or "such a good student." This kind of praise implies that traits like smartness, cleverness and goodness are qualities you either have or you don't. [O]n the other hand, […] just trying to get boys to sit still and pay attention is a real challenge for any parent or teacher. As a result, boys are given a lot more feedback that emphasizes effort (e.g., "If you would just pay attention you could learn this," "If you would just try a little harder you could get it right.") (Halvorson)

Thus, when women encounter an obstacle, they are more likely to see it as an inexorable sign of their own incompetence, while a man encountering similar obstacles is likely to be "trained - intensely trained - to fail and select retry, that is to say, to iterate" and to approach them "as interesting, eminently achievable, potentially fun exercises with a confidence borne of past successes" (Tycho, qtd in Scientist Carrie). Social and developmental psychologist Carol Dweck's research into what she calls "fixed" versus "growth mindsets comes to similar conclusions (Dweck & Leggett, 1988; Blackwell et al., 2007; Dweck, 2006, 2008; cited in Hill 47) . This difference in perspective drastically affects one's well-being and chances of success.

If you've internalized the message that not immediately mastering something means you aren't "good" and "smart" -- that tricky [puzzle] is just miserable and demoralizing. Even if you finally manage it, it feels like a hollow victory. Your repeated failures just prove how stupid you are and how terrible you are... (Scientist Carrie)

If a person with this attitude and low self-confidence in their technical abilities is unable to get their chosen FOSS project running on the first or second try, they are likely to conclude that they are simply not smart enough to participate and give up rather than (in order of usefulness) blaming the erroneous or incomplete project documentation, dispassionately experimenting to try and figure out the project build "puzzle" on their own, or asking for help.

Finally, poor documentation selects for people who have contributed to other FOSS projects and are already familiar with the various trappings thereof. If you ask people what knowledge is necessary to work on a given open source software project, they usually focus on what languages and libraries the project's code is written in or with. In truth, familiarity with a project's programming language is only a tiny sliver of the knowledge that is necessary in order to contribute code, and much of that knowledge is tacit – "acquired and stored within individuals," uncaptured in writing and thus nontransferable (Osterloh & Frey 539). Common hidden prerequisites include comfort using the command line, knowledge of bash commands, ability to effectively use common version control systems, familiarity with bug trackers, and so forth. Additional tacit knowledge covers how, exactly, these tools are expected to be used in a given project (e.g. separating out different changes into separate branches and patches, marking bugs with the appropriate level of severity and tagging them with the right people, code styling conventions, etc.). Veterans of a given project are likely to underestimate the difficulty of getting up to speed with the array of tools their project uses because they are so used to using them – they may have even helped choose what infrastructure to use for the project in the first place.

To be fair, it would be a lot of work for each project to write project-specific tutorials and style guides to cover all this background knowledge. But many projects do not effectively acknowledge all their hidden prerequisites or link to others' tutorials and resources for each of them; much of their project's tacit knowledge could be made more explicit, but simply has not been. Thus, the most likely new contributors to a given FOSS project are likely to have already contributed to a different FOSS project with similar infrastructure and prerequisites, shrinking FOSS's potential recruitment pool and reinforcing FOSS's existing demographic profile.

3.) Assertiveness, Persistence, and a Thick Skin

Without formalized recruitment and mentorship procedures or a pre-existing relationship to a current contributor, new FOSS participants must be willing from the very beginning to "put themselves out there" – initiate their own participation on faith that their contribution is wanted and needed, ask "stupid" questions of unknown veteran developers, nag project leaders to review their patches, defend the merits of their approach to a problem on mailing lists, and so forth. All of these activities may be challenging for shy people in the best of circumstances; for a new contributor with no trusted contacts within the project and less than perfect confidence in one's own technical savvy, such alienating, intimidating environs are likely to lead to them running away or never trying to contribute in the first place. As one contributor to Debian, a FOSS project notorious for being especially prickly, recounted,

In 2004 or so, I saw Debian as the cool kids' club, that awesome project that I wished I could be a part of. By 2006, I managed to get over myself, read the New Maintainer's Guide, and find a way to get involved. As of mid 2009, I am a full-blown Debian Developer. I have real ultimate power. But I sometimes do still feel hesitation akin to "Imposter Syndrome". [...] In the past year of being a Developer, one thing I've seen is that other contributors ask me privately for help. Rather than blast the public lists like debian-mentors [a list intended to help new contributors], they email or IRC private-message me, or SMS me, or find me at a Linux Users Group event. I'm lucky to know these people, and they're lucky to have me as a safe person to ask questions of. [...] [At the "Debian for Shy People" session,] I asked, "How many of you have someone you can ask embarrassing questions of?" Of the forty people crammed into [the room], two people raised their hands. One person put it plainly, "I don't know anyone else who does Debian." (Laroia, "Debian")

Since becoming a Debian Developer, Laroia has gone on to be extensively involved in improving FOSS outreach. Without others in the community to safely ask questions of, and a developer environment that is indifferent or even hostile to newcomers, it is easy for potential contributors' shyness to prevent them from getting involved for years, or ever. Women are especially likely to be limited by this sort of anxiety. Linda Babcock's research found that women score significantly higher than men on a scale of "negotiation apprehension", with two and a half as many women as men feeling "a great deal of apprehension" about negotiating (Babcock & Laschever 114). Her surveys found that "[w]omen felt particularly uneasy about scenarios involving work or activities in which they felt less expert than men (such as getting their car fixed). [...] Men associated words such as exciting and fun with negotiation far more than women, who were more likely...to choose words such as scary" (Babcock & Laschever 114). In describing their experience of negotiation, "women were more likely to pick metaphors such as going to the dentist" (Babcock & Laschever 114). Research has found that this increased anxiety makes it less likely that a woman will go through with a negotiation interaction (Babcock & Laschever 115).

Most of the apparent unfriendliness of FOSS projects is unintentional. However, to some degree it appears that these characteristics have become a point of pride for FOSS developers and users.16 The obscurity and difficulty associated with using or contributing to their software is taken as an indicator of high intelligence and hacking skills; in the worst cases, this unfriendliness becomes a form of hazing, where you prove that you belong in the FOSS community by demonstrating that you know how to deal with its most alienating elements.17 After Vitorio Miliano wrote that closed-source/non-free software has more female contributors than FOSS because it has a friendlier culture, he received this reply: "So [women] have to be spoonfed? What makes them so goddamn important if they haven’t proven they’re willing to contribute?" As Miliano notes, this attitude is precisely the problem:

What you see as spoon-feeding is what normal men and women [...] see as proper, instructive socialization. “Hi, welcome to the community, here’s a housewarming present, here’s how things work, we could really use some help over here and I’d love to show you how to work on it[...]” When you volunteer your mortgage payments and your children’s educational future and your commuting time to move into a neighborhood, the neighborhood welcomes you and shows you the ropes because now you’re all in it together. With open source, you’re also volunteering your time and knowledge and effort, but there’s no welcoming committee, no backyard barbecues, just a bunch of unappreciative keeping-up-with-the-Jones’, where if you don't have the internal motivation to contribute, you won’t last. (Miliano)

Normal humans like to be welcomed. Recruitment processes for any number of other communities and collaborative efforts – university students, churchgoers, Habitat for Humanity volunteers – typically include elements to orient new members and help them become useful. Yet, for various reasons, such efforts are drastically undervalued and neglected by most FOSS projects. Feeling like an outsider – being the only woman, non-coder, or other minority member in the room, on the email list, or in the IRC channel – only exacerbates unwelcoming or hostile infrastructure.

It is important to note that none of these assumptions or "filters" affects women or any particular group exclusively. There are plenty of people, men and women, who would otherwise be fantastic FOSS contributors who do not do so because they are busy, unsure of their technical prowess, shy, and/or discouraged by a project's seemingly-hostile atmosphere. It is also important to make clear that despite the dismal statistics, the FOSS community is not devoid of female contributors and project leaders; these "filters" are not absolute in their effects. My point is merely to show that women (and presumably other minority groups) tend to be disproportionately affected by these flaws in FOSS recruitment. On the flip side, this also means that women and minorities represent the greatest growth potential for outreach in the FOSS community; if FOSS were to go from 2 percent women to 50 percent women (or even just 20 percent women), that change would not merely make FOSS's demographic calculations more equitable but would also signal huge community growth as well, with thousands of new contributors coming "off the sidelines" (Laroia, "Get").

Conclusion

Ultimately, most FOSS projects are not good at attracting new contributors of any sort. Sandeep Krishnamurthy's survey of active FOSS projects found that the median number of developers for a given project was just 4; the mode was one solitary developer (Krishnamurthy). With such a small contributor base it does not take much for a FOSS project to fail. Open source software veteran Karl Fogel estimates that as many as 95 percent of FOSS projects die on the vine (Fogel 12). Indeed, FOSS community members use the rather-morbid "bus factor" – how many key developers would have to get hit by a bus to make the project shut down – as a metric for the sustainability of a project; unfortunately, many projects, even ones with an extensive user base, have bus factors of 1 or 2.

Recruitment of and outreach to new contributors are key to a FOSS project's long-term survival. However, at present the myriad obstacles to initial FOSS involvement mean that nearly everyone who does manage to join the community comes from the extreme, rarefied end of the bell curve in several dimensions – not just gender or ethnicity, but also things like personality and skill set.18 Each incident or obstacle may on its own not be particularly troubling, but cumulatively they result in community monoculture and stagnation. "As the psychologist Virginia Valian writes in her book Why So Slow: The Advancement of Women: 'It is unfair to neglect even minor instances of group-based bias, because they add up to major inequalities'" (Babcock & Laschever 8). Without conscious effort to recognize and fix these molehills in FOSS recruitment and culture, they multiply to become mountains.

Fortunately, not all FOSS communities are unaware of these barriers and the "terror and frustration and vanishing" they cause (Laroia, "Get"). Dreamwidth, a fork of the code that runs blogging service LiveJournal, is notable as one of very few FOSS projects whose contributors are majority-female, with a substantial proportion of gay, trans, and genderqueer contributors as well. This is not an accident; as a project founded by women, Dreamwidth proactively prioritized inclusion and diversity from the very beginning. Its diversity statement, beginning simply with "We welcome you," is extraordinary by any measure and unique among FOSS projects.19 Dreamwidth's "Getting Started" page for new developers states "If you're totally new to programming and/or contributing to Open Source projects, don't worry! We'll walk you through the process" – a friendly "Don't Panic"-esque notice that encourages even less-experienced coders to get involved.20

Another example of an unusually friendly FOSS project is ThinkUp, a social media-based brainstorming application headed by Gina Trapani and Anil Dash. In an interview, Dash explained why diversity was such a priority with ThinkUp:

It's really important to me that we have this open source project that's had remarkable early success and our lead coder is a woman, and she's out, and we have prominent developers in our community who are gay, who are women, who basically don't look like every other open source app out there. Essentially, that inclusiveness isn't just the goal of the crowdsourcing, but of the technology development itself -- because we all build our cultural assumptions into the tools we make. [Diversity] was a prerequisite. Absolutely essential. [...] It was more about what I saw as the failings of the tech industry where people would excitedly say, "You can get people to contribute to an open source app just by giving them t-shirts!" And the choice of t-shirts are men's medium or large. (Scola)

While diversity on gender, sexual orientation, and other typical socioeconomic dimensions was certainly a priority, the ThinkUp founders have explicitly stated that they see diversity in a more expansive way: "We encourage contributions not only by women, but open source newbies and non-usual suspects of all stripes: designers, user experience experts, writers, students, and enthusiastic users" (Trapani). ThinkUp does not have the prominent diversity statement that Dreamwidth does; its front page declares that the project "Welcom[es] All Developers!", but doesn't explicitly talk about sex, gender, race, etc.21 However, it succeeds in recognizing that "it's the small things that count" in creating a welcoming environment (Stewart). For instance, the top of ThinkUp's code repository and developer website states, "Welcome! You are a programmer! The ThinkUp project eagerly welcomes new contributors from all communities, even if you don’t think of yourself as a programmer. (Yet!)".22 This statement immediately defuses potential contributors' self-doubt, uncertainty about their help being wanted, and imposter syndrome symptoms, encouraging them to continue reading and get involved.

Defining a FOSS project's internal culture around friendly inclusion from the beginning is one way to avoid these problems; however, that does not give us much of a strategy for how to improve long-standing FOSS communities. Fortunately, a new generation of FOSS outreach programming has recently developed in two major FOSS communities and already such programs appear to be making huge differences in terms of both diversity and community growth generally. In 2009, two women in the San Francisco-area Ruby meetup group, unhappy with how few women attended the meetup, put on a free one-day workshop to teach "women and their friends" the basics of programming in Ruby on Rails, a popular language and platform for writing web applications (Mei).23 That single workshop soon became a wildly-popular series of workshops, collectively called Railsbridge, hosted for free in the offices of San Francisco-based Web 2.0 magnates like Twitter and Pivotal Labs.24 Consistently all sixty or so seats in a given workshop fill up within 24 hours of the event announcement. It turned out that there were hundreds of women, many already working in the tech industry in nontechnical positions, who had a thirst for learning to program but had not found such a friendly, welcoming environment in which to try. Many of these women continued their study of Ruby in book club-like meetings with other attendees as well as at hackathons hosted by the SF Ruby meetup group; a number have gone on to teach or assist with future Railsbridge workshops. The workshops and their aftermath did not just recruit new female members into SF Ruby directly:

When the Ruby people brought in more women to the integrated community of their meetup group, they noticed that other women who didn't attend their workshops would start attending the meetup group. And what they were doing was undoing the self-reinforcing demographic problems. By having new people who represented a different demographic group, they would bring in their friends! (Laroia, "Get")

As a result, within a year the SF Ruby meetup group went from 2 percent female to 18 percent female (Mei). Other Ruby enthusiast groups are now attempting to clone the Railsbridge curriculum and run their own workshops across the country.

Railsbridge's efforts have also inspired enthusiasts of another open source programming language, Python, to do similar outreach. In February 2011, three members of the Boston Python meetup group, Asheesh Laroia, Jessica McKellar, and Ned Batchelder, organized a one-day workshop for women and their friends following a similar curriculum as Railsbridge, only teaching a Python-based set of technologies. The workshop was well attended and apparently successful (Laroia, "Get"). After Laroia spoke at PyCon (the main Python language conference) later that year about the workshop and FOSS outreach generally, attendees from several other Python user groups – in Minneapolis, the Bay Area, and Montreal, Canada – were inspired to run similar events, which have come to be known as PyStar workshops, in the following months.25 Given how new PyStar is, it is not yet clear if it will have the same community-building, diversity-increasing effects in the Python community as Railsbridge had in the Ruby community, but so far the signs are promising.26

Vitorio Miliano believes that the problems with dominant modes of FOSS recruitment are inseparable from the problem of sexism in FOSS:

I believe the problems with open source not being able to handle non-programmers in their projects is the same problem as the rampant sexism: open source culture is not feminist. Feminism is fundamentally about equality for everyone, not just women, and designers of any gender are just as alienated as women programmers, because it’s not an equally welcoming environment. There’s no perceived value in open source for mentoring, facilitation, disciplining of unruly users, training of newcomers or non-technical users, etc., which are needed to support both designers of any gender and women in any role. (Miliano)

Fortunately, the contrapositive of Miliano's argument appears to also be true: making FOSS more accessible and friendly in general appears to have the side effect of also making it more diverse. As FOSS-centered conference talks on outreach (such as Asheesh Laroia's PyCon lecture) and success stories from other projects' recruitment initiatives circulate, hopefully more FOSS projects will be turned on to the importance of being welcoming, concrete, and proactive in their handling of new contributors, "shy" or otherwise (Laroia, "Get"). Many members of the FOSS community have a certain allergy to the word "feminism" and are not especially motivated to address diversity issues for their own sake. As these new outreach ideas and practices spread, though, the incentive structure may be in place for FOSS projects to "accidentally" diversify their demographic makeup as they grow without having to grapple with that "f-word".

Footnotes

1: A selection of theories of why there are fewer women/minorities in tech: less socioeconomically advantaged kids are less likely to have had a personal computer in the 1980s (Restructure!) and the average age of first having one's own computer is significantly higher for girls than for boys (Krieger); computer science department culture is less appealing to women (Margolis & Fisher, 2002); and repeated failure is part and parcel of coding and boys are better taught to handle failure than girls (Scientist Carrie).

2: http://geekfeminism.wikia.com/wiki/CouchDB_talk

3: http://geekfeminism.wikia.com/wiki/EMACS_virgins_joke

4: Recent account of one such assault (trigger warning): http://blog.nerdchic.net/archives/418/

5: In this paper, I use the term "recruitment" loosely to describe the ways in which new contributors become involved in FOSS. However, it should be noted that most FOSS projects do not actively "recruit" in any traditional sense of the word (e.g. athletic recruitment). At best, projects seek to make it less difficult for outsiders to submit patches or other contributions; the "recruitment" interaction is almost always passive on the part of the project. This arguably may be a weakness of FOSS communities and contribute to FOSS projects' low overall survival rate. Notably, the new wave of FOSS outreach is significantly more proactive than previous efforts.

6: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-August/000605.h...

7: https://openhatch.org/blog/2011/april-build-it-week/

8: Example: http://us.pycon.org/2011/sprints/

9: http://women.debian.org/home/

10: http://ubuntu-women.com/

11: http://fedoraproject.org/wiki/Mentors

12: http://google-opensource.blogspot.com/2011/04/dos-and-donts-of-google-summer...

13: A number of stories of users' first encounters with Linux can be found at https://bbs.archlinux.org/viewtopic.php?id=15691&p=1 and http://www.hackerthreads.org/Topic-32787.

14: http://readthedocs.org/

15: See especially the distinction made between "category A" people and "category C" people in the lecture, starting about fifteen minutes in: http://www.youtube.com/watch?v=hE7l6Adoiiw.

16: The title of this paper came from a comment made by a longtime FOSS developer at PyCon 2010 to a woman who was listing factors that, to date, had made her hesitant to get involved in FOSS, as mentioned in this blog post: http://jackdied.blogspot.com/2011/03/pycon-detritus.html. While in this case the jibe appears to have had a positive, proactive effect (it got under the woman's skin, with the end result that she now contributes to FOSS) the attitude behind such comments is telling.

17: At PyCon 2011, I was asked half-jokingly, "Why can't these people [women, etc.] just read the docs and figure things out on their own? That's how I got involved!" Whether this mentality is simply reflective of a lack of understanding of how other people learn and participate or symptomatic of a sort of hazing ritual, this attitude seems fairly widespread.

18: For instance, some commentators both in and outside the FOSS community suggest that participation in FOSS may select for people on the autistic spectrum, with various associated personality traits. However, to date there has been no medical or psychological work to confirm or refute such a link. See discussion in Krieger et al, p. 14-15.

19: http://www.dreamwidth.org/legal/diversity

20: http://wiki.dwscoalition.org/notes/Dev_Getting_Started

21: http://thinkupapp.com/

22: https://github.com/ginatrapani/ThinkUp/wiki/Developer-Guide

23: The "women and their friends" stipulation was meant to make it clear that the workshop was female-friendly without being exclusive, as well as to aid in recruitment: if you were a woman, you could attend automatically; if you were a man, you could attend, but only if you found a woman in your life who was interested in attending and would then bring you as her guest. This gave interested men an incentive to find a female friend or colleague who might be interested in learning to program and encourage them to attend the workshop. Roughly speaking, about a quarter to a third of Railsbridge attendees have been male.

24: More information on the workshops and related activism can be found at http://workshops.railsbridge.org/.

25: More information on the workshops can be found at http://pystar.org/.

26: Women's attendance of the Boston Python meetup jumped from about 2 percent (1 out of 50) in January, before the Boston Python workshop, to about 16 percent (11 out of 55) in May. http://www.asheesh.org/note/community/boston-python-meetup.html

Works Cited

Aurora, Valerie. "The Dark Side of Open Source Conferences." 1 Dec 2010. http://lwn.net/Articles/417952/ Accessed 13 Apr 2011.

Babcock, Linda and Sara Laschever. Women Don't Ask: Negotiation and the Gender Divide. Princeton University Press. 2003.

Bolton, Nick. "How did you get involved with your open source community?" Stack Overflow. 5 Apr 2009. http://stackoverflow.com/questions/718107/how-did-you-get-involved-with-your... Accessed 11 May 2011.

Buckland, Richard. "Lecture 1: Higher Computing." Lecture, University of New South Wales. 16 Mar 2008. http://www.youtube.com/watch?v=hE7l6Adoiiw

Druckman, Katherine. "Angela Byron on Drupal 7." Linux Journal. 24 Feb 2011. http://www.linuxjournal.com/content/interview-angie-byron-drupal

Dunnewind, Stephanie. "How can moms and dads achieve equality at home?" The Seattle Times. 8 May 2004. http://seattletimes.nwsource.com/html/living/2001922984_dadhelp08.html

Fogel, Karl. Producing Open Source Software. O'Reilly Media. 2005.

Geek Feminism Wiki. "Impostor Syndrome." http://geekfeminism.wikia.com/wiki/Impostor_syndrome Accessed 4 May 2011.

Geek Feminism Wiki. “Incidents.” http://geekfeminism.wikia.com/wiki/Category:Incidents Accessed 16 Mar 2011.

Google. "Google Summer of Code." 2011. http://code.google.com/soc/

Ghosh, Rishab Aiyer et al. “Free/Libre and Open Source Software: Survey and Study.” International Institute of Infonomics. 2002. http://www.flossproject.org/report/index.htm.

Halvorson, Heidi Grant. "The Trouble With Bright Girls." 1 Mar 2011. http://www.huffingtonpost.com/heidi-grant-halvorson-phd/girls-confidence_b_8...

Heeter, Carrie. "Girls game less because they have less free time, study." 24 Jul 2009. http://www.physorg.com/news167660240.html

Hill, Catherine et al. "Why So Few? Women in Science, Technology, Engineering, and Mathematics." AAUW. 2002.

Hsu, Jean. "My Experiences as a Female Software Engineer." 17 Jan 2011. http://www.jeanhsu.com/2011/01/17/my-experiences-as-a-female-software-engine...

Kanazawa, Satoshi. "The Imposter Syndrome." Psychology Today. 26 July 2009. http://www.psychologytoday.com/blog/the-scientific-fundamentalist/200907/the...

Kerner, Sean Michael. "Was Google's Summer of Code a Boon or Bust?" InternetNews.com. 22 May 2006. http://www.internetnews.com/dev-news/article.php/3607711

Kollock, Peter. “The Economies of Online Cooperation: Gifts and Public Goods in Cyberspace.” Chapter 9 in Communities in Cyberspace, Kollock and Smith, eds. 1999.

Krieger, Bernhard, James Leach, and Dawn Nafus. "Free / Libre / Open Source Policy Support (FLOSSPOLS): Integrated Report of Findings (Gender Strand) ." Cambridge: University of Cambridge. 2006. http://www.flosspols.org/

Krishnamurthy, Sandeep. "Cave or Community? An Empirical Examination of 100 Mature Open Source Projects." First Monday. 3 Oct 2005. http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1477/...

Laroia, Asheesh. "'Debian for Shy People': What's next." 10 Aug 2010. http://www.asheesh.org/note/debian/post-shy.html

Laroia, Asheesh. "Diversity in Free Software: South Asians as an example." 18 Dec 2009. http://www.asheesh.org/note/debian/indians.html

Laroia, Asheesh. “Get new contributors (and diversity) through outreach.” Lecture, PyCon 2011. 11 Mar 2011. http://pycon.blip.tv/file/4880711/

Margolis, J., and Fisher, A. Unlocking the clubhouse: Women in computing. Cambridge: Massachusetts Institute of Technology. 2002.

McPherson, Miller, Lynn Smith-Lovin, and James M. Cook. "Birds of a Feather: Homophily in Social Networks." Annu. Rev. Sociol., Vol. 27, p. 415-44. 2001.

Mei, Sarah. "Moving the Needle: How SF Ruby Got to 18%." Lecture, SCALE 8x. 19 Feb 2010. http://www.sarahmei.com/blog/2010/02/20/scale-8x-slides-posted/

Miliano, Vitorio. "Designers and women in open source." 17 Mar 2011. http://vi.to/designers-and-women-in-open-source.html

Noller, Jesse. "On Contribution." 5 May 2011. http://jessenoller.com/2011/05/05/on-contribution/

Osterloh, Margit and Bruno S. Frey. "Motivation, Knowledge Transfer, and Organizational Forms." Organization Science, Vol. 11, No. 5, p. 538-550. Sep - Oct 2000.

Restructure! "If you were hacking since age 8, it means you were privileged." 26 Jul 2010. http://restructure.wordpress.com/2010/07/26/if-you-were-hacking-since-age-8-...

Roberts, Jeffrey A., Il-Horn Hann, and Sandra A. Slaughter. "Understanding the motivations, participation, and performance of open source software developers: A longitudinal study of the Apache projects." Management Science. 2006.

Scientist Carrie. "Why don't girls play video games? or, a fail blog." 26 Apr 2011. http://scientistcarrie.blogspot.com/2011/04/why-dont-girls-play-video-games-...

Scola, Nancy. "An Interview with Anil Dash, Director of Expert Labs." techPresident. 2 Apr 2010. http://techpresident.com/blog-entry/interview-anil-dash-director-expert-labs

Stewart, Rebecca. "It's the Small Things That Count." 13 May 2011. http://blog.theleadingzero.com/?p=235

Stross, Randall. "What Has Driven Women Out of Computer Science?" The New York Times. 15 Nov 2008. http://www.nytimes.com/2008/11/16/business/16digi.html?_r=1

Trapani, Gina. "Designers, Women, and Hostility in Open Source." 23 Mar 2011. http://smarterware.org/7550/designers-women-and-hostility-in-open-source

Sue Gardner Executive Director Wikimedia Foundation

415 839 6885 office 415 816 9967 cell

Imagine a world in which every single human being can freely share in the sum of all knowledge.  Help us make it a reality!

http://wikimediafoundation.org/wiki/Donate