You are here

Ten easy ways to attract women to your free software project

The gender inequality among developers and supporters of free software is stunning. Less than 2% of us are women, according to studies conducted for the European Commission. Why? The evidence says we're driving them away. There are even some pretty good published guidelines on how not to drive them away. What's missing is a practical implementation strategy: here I present ten relatively simple changes in how you run your project, to make it more attractive to would-be contributors—especially women.

Yes, there is a problem. Data from [1]

There's a lot of research on this subject, and if you are interested in a deeper understanding of the problem, then you'll want to go and read some of the notes. The FLOSSPOLS[1] study is particularly informative, and although long, it is well structured, and has good summaries. Val Henson wrote an excellent HOWTO[2] on the behavioral issues, which I highly recommend you read. A lot has been written about how big the problem is, the factors that are probably contributing to the problem, and even some broad social and political ideas about solutions.

To put it very briefly, the studies conclude that there is no dearth of women interested in computer science, nor women capable of doing it well, and there are excellent reasons why women should be involved for their own benefit and for the benefit of the community[1]. But the community's process is exceedingly male-centric and hostile to anyone who doesn't fit that mold—a problem confirmed by the few pioneering women who do participate[2-9]. The recommended solutions primarily involve intentional cultural changes that need to happen to avoid the hostility and make the field more accessible.[1,2]

I'm going to assume that you're already sold on the value of inviting more women into our community, or at least committed to stopping the things that drive them away. But what are you going to do about it? As a free software project leader or founder, you make a lot of fundamental design decisions about how you're going to run your project. And that's where I think that change needs to start: make one project friendlier. Then another, and so on.

In my opinion, the key is the technology problem. Online society is a product of its participants, but also of the landscape artificially created by the software that we use in our production process. That toolchain has been crafted almost entirely by men, and unconsciously, for men and their social needs. Women's needs have been ignored, if not actively derided. And surprise, surprise... they don't show.

It's time to fix that. Here's a list of ten not-so-difficult process decisions to make in laying out a new project, or to adopt in an existing one. Nine of these ten suggestions do not involve any special treatment for women (the tenth does, but only in a trivial way). Making your project friendlier and more open to new contributors will attract some men as well as women. But it is women who will benefit the most from these changes[10].

1 Use forums instead of mailing lists

"When asked about the large gender imbalance in FLOSS [free software] development, many women relate stories about harassment or other inappropriate treatment at a FLOSS meeting or in a FLOSS newsgroup. Since most FLOSS projects aren't affiliated with a company, university or other accountable body, civilized behavior isn't enforced." —— Michelle Levesque/Greg Wilson[5]

"Just knowing that there is one other person in the group who is willing to publicly disagree with the 'bad apple' will help immensely, and will make women more willing to stay." —— Val Henson[2]

A web-based forum typically provides much better ability to moderate and maintain community behavioral standards. Like a campus security phone, the mere existence of a "Report to moderator" link deters most serious abuses, and other features create a friendly and inviting atmosphere which encourages good behavior (Credits: Brian Schulman/CC-By-SA 2.0, Terry Hancock/CC-By-SA 3.0)

Reasons

Badges and ranks afford a better understanding of how representative any poster is

Signatures and avatars provide a form of graphical self-expression more comfortable for women than the sorts of posturing and crowing behaviors that fill this role for men

Out of channel communications allow "meta" conversations to happen without disrupting the forum: you don't have to post to counter a flame, you just vote it down or report it to a moderator

Things like gender status and dating information can be communicated in profiles, by those who want them, and ignored by those who don't, eliminating the motivation for talking about it in a thread

The absolute number one problem with women joining free software projects is that, from square one, they have to put up with jerks. If you're on the job, you put up with jerks, because you have to. But would you do that to yourself, just for fun? No. And most potential contributors—especially the new ones and the ones you most want—are here for the fun.

Val Henson's "HOWTO Encourage Women in Linux"[2] pretty much covers the behavioral issues and what needs to change, but it says little about how to make these changes happen. As a leader, you need a way to set community standards and enforce them. Despite a certain "Wild West" charm some of us feel about the libertarian environment of internet text forums, no one seriously needs to tolerate flame wars. They are not constructive, and you can always argue the same points in a civilized tone.

So ban the jerks and put the fun back in for everyone. Mailing list software is lousy at moderation options, so don't use it! Set up a web forum in your CMS, on your server, or use a paid or free forum hosting service. Have the conversations there: for users and developers.

Forums are a lot of fun once you get used to them, and women like them for other reasons besides the feeling of a "safe haven". They also promote more camaraderie and social behavior than do mailing lists, contributing to a greater feeling of "constructive leisure". Women often collaborate on projects in order to socialize, so this is a good way to encourage more serious contributions.

It goes without saying, of course, that you need to have forum behavior guidelines and you need to enforce them. Empower moderators to take on that job (and women often will volunteer for this kind of job if you ask them nicely).

2 Use flat conversation rather than deep-threads: "who" not just "what"

"While it is possible for a programmer to be relatively successful while being actively anti-social and programming does tend to attract people less comfortable with human interaction, computing is as social as you make it. [...] For me, programming by myself is less fun or creative than it is when I have people around to talk to about my program." —— Val Henson[2]

Women are much more likely than men to communicate for the sake of communication and for the bonding value. Men often grudgingly communicate in order to solve a problem (though sometimes that's a act). (Credits: Henri Bergius/CC-By-SA 2.0, Pingu1963@Flickr/CC-By 2.0, Terry Hancock/CC-By-SA 3.0)

Reasons:

Flat threading environments encourage a simpler "logic of conversation" that is more like a face-to-face discussion

It is easier to track who is talking, not just what they are talking about, and this is likely to matter more to women, for whom individual relationships in the community are generally more important than just mining it for information

Flat threading encourages smaller, more focused conversations with intentional topic-setting, these are likely to be easier for all newcomers to follow, not just women

This is a much more subtle and less obvious point. When confronted with the observation that women often prefer flat-threading to deeply-nested topical threading, some people leap to the conclusion that this is a product of limited experience with the technology. However, I'm convinced that it's more than that.

The key is the nature of the information and the psychological needs of the participant: if you are there primarily just to grab some information and go, then deep threading serves you by categorizing information. But if your reason to be there is largely social—you want to be in the company of like-minded people discussing a subject you love—then flat threading serves you by providing a better conversational context.

Women feel a stronger commitment to contribute when they are surrounded and depended-upon by people they consider friends. So ironically, these behaviors, which may not sound very productivity-oriented, will result in greater productivity.

In the same way, I recommend keeping IRC sessions small and intimate, with "teams" targeted to solve particular problems. Make arrangements for online "sprints" in this way, so that people with "lives" (which a lot of women do have) can work these projects into their time. But don't try to run continuous massive IRC sessions which you would have to dedicate your life to in order to follow.

3 As much as possible, use wikis instead of version controlled archives

"Being good at computing is considered to be an activity that requires spending nearly all your waking hours either using a computer or learning about them. While this is another misperception, women generally are less willing to obsess on one topic, preferring to lead a more balanced life. Women often believe that if they enter computing, they will inexorably lose that balance, and avoid the field altogether instead." —— Val Henson[2]

If you look at the traditional ways women collaborate on projects, you'll see a much lighter-weight process with lots of give and take, and contributions made in lots of small ways in parallel, rather than "rewrites" or "versions" made in large blocks. For women, the higher social interaction this requires is part of the payoff (Credit: claygrl@Flickr/CC-By 2.0)

Reasons:

Women like working cooperatively, they don't just tolerate it

The "reputation game" is much less important to women than is "belonging" to the group

Everybody has a browser, but women may have less control over what equipment and software they use, especially as beginners

Even if women do have the control they need to install development environments, they generally don't want to waste as much time "fiddling with the tools", and want fewer obstacles to simply getting the job done

Women are more likely to want to discuss or seek approval for their changes, owing largely to confidence issues

Wikipedia has a much more representative group of contributors than does free software in general. One reason is that it doesn't take much "buy in" (time risked) to participate. You see something wrong with an entry, then you punch "edit" and fix it—there's no big barrier to overcome, so you don't have to be as extremely motivated to overcome it.

It's too bad that there's not yet any good way to implement source code version control via a wiki-like environment (how would you test the changes?), but it's absolutely feasible for everything else in a project: documentation, textual and graphical resources, and so on.

4 Use very-high-level languages (Perl, Python, Ruby, etc)

"Another important point is that Free Software development is often done as a hobby, just for fun, and in one's spare time. Where is a woman's spare time? After their working day, most of them still have the second working journey, which is at home, taking care of the home, the children and her husband. If the men can have the privilege of doing Free Software in their spare time, sitting in front of the computer and having some fun coding what they want, women in general don't have this privilege." —— Fernanda Weiden[9]

"It matters when you have kids, it really does" —— Mitchell Baker[9]

"So I set out to come up with a language that made programmers more productive, and if that meant that the programs would run a bit slower, well, that was an acceptable trade-off. Through my work on implementing ABC I had a lot of good ideas on how to do this." —— Guido van Rossum (on his motivation for writing the Python programming language).

Women often find themselves in various support and care-giving roles. These are interrupt-driven lifestyles in which the large blocks of time required by traditional programming methodologies are hard to come by. But modern very high level programming languages can make shorter sessions productive (Credit: LizaWasHere@Flickr/CC-By-SA 2.0)

Reasons

Women have less time for buy-in to the technology.

Time often comes in smaller chunks, as it must be fit in around responsibilities like support and care-giving roles in their families

Unexpected interruptions and the resulting uncertainty of time intervals spent programming is an even bigger issue: you never know whether you're going to have time to put back together what you just took apart

For reasons of low confidence and a later start in programming, many women today will simply lack the faith that they can fight through to the end on a large, complex problem in a language that doesn't make it easy

Modern Very High Level (VHL) programming languages like Python, Perl, and Ruby can often condense out the busy work of programming, providing a better use of the time available

A language that emphasizes readability, like Python, can make recovering from an interruption easier, and less time is wasted as a result

This one was a deeply-personal revelation. For years during high school and college, I programmed in BASIC, then FORTRAN, and then C and C++. I felt pretty good about it, and like most hackers, I put in some long late night sessions of programming.

Then, sometime after college, we had our first child. After that, I found I couldn't program any more. Seriously. There were just too many interruptions. As soon as I got back "up to speed" with the software I was working on and "recovered state" enough to make the next logical step, I would get another interruption, and the program would go back on the back burner. Later, I'd find myself having to puzzle out what I had written a day, a week, or even a month in the past.

When I finally did get back into programming, it was through free software, and someone on my first project recommended I try Python. It was amazing. I could get stuff done again. That's both because Python code is more compact and because it is more readable.

Now the kids are school age, and I have more time, but I'm too hooked on the rapid productivity of Python to go back now.

5 Follow "extreme programming" ideas

"Like any other discipline, computer science is easier to learn when you have friends and mentors to ask questions of and form a community with. However, for various reasons, men usually tend to mentor and become friends with other men. When the gender imbalance is as large as it is in computer science, women find themselves with few or no other women to share their interests with." —— Val Henson[2]

Pair programming is so "girlie" it ought to giggle. Seriously. Extreme programming plays to women's strengths and mitigates their weaknesses. And it works pretty well for men too (Credit: Improve It@Flickr/CC-By-SA 2.0)

Reasons:

Test-driven development turns long-delayed gratification into lots of little wins, each one a confidence-building victory which women, who often lack confidence in their technical abilities, need to see

Pairs programming is a very "feminine" way to work, in close knit teams, observing the code together. Two sets of eyeballs find more bugs, and there is no better time to find a bug than right after (or even before) you make the mistake

Getting rid of the male "power-world" of hierarchical programming teams is a definite win for women, who prefer flatter "peer" structures

One wonderful trend, largely motivated by free software development is so-called "Extreme Programming" (XP). In my opinion, it's actually a very "feminine" way to work, and in any case, it directly confronts some of the obstacles that women face with programming. There are plenty of other reasons to use XP methods, but attracting women developers is a good one.

One issue that may be a problem is that women may not easily be able to find partners for pair programming sessions. It may be desirable to try to simulate this experience with small (tiny) IRC chat sessions and some means of viewing the same code as it is being worked on.

6 Replace pecking-orders with affirmation processes

"Interestingly, rude responses are often given by people who are in the process of gaining a reputation. It is often as if lower ranking participants try to build their reputation by either responding rudely and thereby implying impatience with the ignorant, or by showing off the extensiveness of their knowledge, instead of providing an uncomplicated answer." —— FLOSSPOLS[1]

"Often, the only reward (or the major reward) for writing code is status and the approval of your peers. Far more often, the "reward" is a scathing flame, or worse yet, no response at all." —— Val Henson[2]

How hard is it to say those two little words, "Thank you"? Men often won't care (but some will). Women often will care, and the cold shoulder of not responding to a contribution with some kind of acknowledgment is truly unacceptable (Credits: shellac@Flickr/CC-By 2.0, bandita@Flickr/CC-By-SA 2.0, Gisela Giardino/CC-By-SA 2.0, Nyenyec@Flickr/CC-By-SA 2.0, yasmapaz@Flickr/CC-By-SA 2.0, Emily Jones/CC-By 2.0, Open Clipart/PD)

Reasons:

The cult of personality is all about glory and honor, things that matter a lot to men, but are usually of secondary interest to women

Women don't like to "blow their own horns", but they love to be appreciated, and they'll do more work when they are

Subjective reputation is often flat-out wrong and very, very biased. Objective measures are useful to see what the score really is, especially when the players are not equally forthright

Explicit acceptance rituals encourage a feeling of "belonging" that is more important to women than it is to men, and more important than a competitive desire to "lead the pack"

It builds confidence and encourages people to contribute if they get tangible feedback and recognition for what they do

It's important to realize that flame wars and other male dominance contests do serve a social function. They are a very primitive way of evaluating the importance and value of individuals in the group. Knowing "who's in charge" is something that makes it much easier (especially for men) to cooperate. Men, either instinctively or through childhood experiences, know how to play this game, and they do it unconsciously.

Women's methods of achieving the same goals are very different. They revolve around higher levels of cooperation, less competition, and much more careful attention to affirming other people in the group. Women care more about "belonging" than about "winning". They don't care so much about "glory", but they care a lot about being "appreciated".

So concentrate on positive reinforcement of good behavior and good contributions. When someone does something helpful for the project, recognize them for it. Give them more responsibility. And—on the forum—give them some token (a label or avatar) that recognizes what they've done. That way, there isn't the necessity to crow about it. People will be able to tell in an instant who has made real contributions.

Women, because of shyness, low confidence, or social admonitions against "putting themselves forward", generally won't take these titles for themselves. They have to be given them by others, or they don't feel that they count. Being "appreciated" or "useful" was the point of the contribution.

All too often, that just doesn't happen in the free software process. People spend hundreds of hours writing and/or improving code, and what do they get for their trouble? Often not much.

Spend some time lurking on a female-dominated forum or mailing list if you want to see what I'm talking about. Women actually do this amazing thing of encouraging and complimenting each other. Above all, they remember to say 'thank you' when somebody does something good for their community.

7 Don't discount what women do

"Opening up our definition of hackerdom to include such traditionally female concepts as user interface and psychology, written and verbal communications, group interactions (both electronic and face to face), et cetera, may be a valid alternative to requiring women to fit the existing hacker mold. Additionally, it may result in communities and processes which are even more powerful than our current models." —— Kirrily "Skud" Robert[6]

Women do important things, but gender politics often lead to 'women's work' being degraded or discounted. Don't fall into this trap (Credits: Seth Anderson/CC-By-SA 2.0, SocialTechnologies.com/CC-By 2.0)

Reasons:

Good software is a lot more than just "code"

Documentation is no easier to write than code (unless you do it very badly)

Marketing, graphics, logos, icons, and just generally helping people are also important

Given a safe and affirming environment, women will do a lot of the stuff that men don't want to do on a project, and which is absolutely essential for the project's success

Artificial distinctions like "Turing-completeness" are a silly way to divide the world: HTML, SVG, XML, and SQL are no easier to write than C, Java, or Python, and just as important to many projects

Systematically undervaluing women's work is a holdover from archaic and sexist gender politics, it's just a way of perpetuating them

There is a pattern (in all of society, not just in computing) of systematically trying to devalue anything that is done by women as somehow less important or less difficult than anything done by men. Perhaps this is because men feel a need to "be important" and women mostly just feel they need to "be useful".

But the reality is that the jobs traditionally done by women are often just as difficult and just as critical to success as any of the jobs that men traditionally do.

Often enough, documentation, web pages, and other "non-programming language" products are the areas where women will first contribute code (notably these are areas where the male-dominated field of free software is consistently weak!). Value it for what it is, and don't make artificial distinctions about it. A contribution is a contribution. And those who today write documentation may write code tomorrow—if you don't drive them off in the meantime.

8 Emphasize community process over manufacturing products

"Computers are still seen as boy’s toys – even before going to the university many boys are ready to work with technology and develop careers in technical fields. Women, most of the times, need to dedicate much more time to study and professional improvement. In the FLOSS community, what is more important is the exchange of knowledge–through codes, documentation, debates and ideas. It’s like a library, a huge live encyclopedia available. This is very important for women and can be very helpful to their development." —— Sulamita Garcia[7]

Reasons:

The manufacturing and product-ization of software is artificial and antithetical to the nature of free software

Service and support areas are the profit center for free software, so they deserve more respect

The model of software as a defined "product" to be "manufactured" by a certain "release date" and "sold" is a highly artificial one, created primarily to make proprietary software companies viable. The reality is that creating software is a much more creative give-and-take process.

This really should be a no-brainer. In the proprietary software world, creating software is a profit center (you sell copies of your code), whereas providing service and support is a loss-center (because you typically included some kind of support in the sale price of the copies you sold, and you won't get that back on a regular basis). In the free software world, things are usually exactly the opposite: you make nothing from actually delivering code, because people can get it for free and copy it as much as they want, but you can make money from selling service and support contracts through a number of different business models.

Women, of course, tend to gravitate much more to support roles than men do. Yet they receive very little acknowledgement for this. See anything weird? Yes, that's right, the women are doing the big money work. So why is there so little appreciation of this fact?

9 Create a formal mentoring and induction processes

"LinuxChix started as a space for women who worked as techies to come together and get support. Generally when these women joined us they felt happy and surprised that there was a group of women discussing technology and that they were not alone." —— Sulamita Garcia[7]

Programming, like sewing, is largely a "tacit" skill, which is best learned by doing and by watching others (Credit: Seth Werkheiser/CC-By-SA 2.0)

Reasons:

Women have fewer opportunities for apprenticeship

Informal apprenticeships with men may be awkward (Is she your "apprentice" or your "girlfriend"?)

Women may have missed out on early training opportunities due to sexism earlier in their lives

Ultimately, learning to program tends to be an apprenticeship process. You can learn quite a bit through formal classes or by reading. You can even learn by spending enormous amounts of time bashing your head against the wall while trying to make something work on your own. But the best way is to be able to ask for help—even at the beginning when you need to ask the really, really dumb questions.

10 Make the existing women in your project visible

"I encourage all women in computing to be as visible as possible—accept all interviews, take credit publicly—even when you don't want to. You may be embarrassed, but by allowing yourself to be publicized or promoted, you might change a young girl's life." —— Val Henson[2]

The evidence of history proves that women have what it takes to do programming even at the most advanced levels. After all, the very idea of programming was invented by one woman (Ada Lovelace[11]) and the idea of compilers and high-level languages was invented by another (Grace Hopper[12]). A few women like Frances Allen[13] and Rosalind Picard[14] continue to innovate at the very highest levels. Other women, like Mitchell Baker [15] and Mary Lou Jepsen [16] have contributed in equally important ways to the success of free software. In the early days, programming computers was primarily "women's work" as these photos of ENIAC[17] and Colossus[18] programmers show. (Credits: US Navy Photos, UK Government Photos, Rama@Wikipedia/CC By-SA 2.0/fr, James Duncan Davidson/O'Reilly Media/CC By 2.0, David Bruce/CC By-SA 2.0)

Reasons:

There are pioneering women in free software who can act as role models for young women in seeking careers and vocations, but they are "lost in the noise" of all the men in the field

Role models can be powerful motivators for everyone, but especially for younger people who may not be very certain they can really follow a certain vocational path

Often, we act like free software forums are 100% male-only, when they are really more like 90%-95%. Making the minority of women visible now makes it easier for men and women to adjust to the reality and leaves room for that minority to grow

Many women lurk more than they post, for many of the reasons described. Seeing visible women accepted by the community will stir more of them to participate

While it's a hard road to be a pioneer, the presence of women will encourage more women to join in. It will also make it clear to the men in your project that they are in "mixed company" and this by itself will curtail some of the worst behaviors.

Of course, it requires that the pioneering women who do work on free software projects be willing to expose themselves to a bit more scrutiny than might be comfortable. You certainly should not try to force recognition onto them, but you should ask them if they're willing to stand up and be counted.

Diversity is strength

"People write software to meet their needs, to make software do what they want. If women don't participate in writing code and writing documentation, they will never have the results and the answer for their needs. That's how it is. Those who merely watch have no influence on driving development, and the consequence is not having software that [does] precisely what you want it to do." —— Fernanda Weiden[9]

I hope the benefits of having more women participate in free software are obvious. We write software to serve the needs of people, but we can only clearly see our own needs. A greater diversity of those involved means more perspectives on every problem, a better understanding of the problems that need to be solved, and better solutions for solving them.

Many of the "stereotypically female" contributions: interface design, documentation, and even marketing are areas in which free software is sadly lacking. It should be fairly obvious that if this is what women want to contribute, we should darned well make it easy for them to do so.

There's a lot to be gained by bringing women into free software, and the best way for you to help make it happen is to start with your project and the projects that you contribute to.

[10] Throughout this article I make a lot of generalizations about how "men" and "women" behave. Obviously men and women are not monolithic groups, and there's a lot of variation, so this is just short hand. There are some important differences that apply in the real world, though, whether because of nature or nurture. Indeed, in writing this article, I have taken the assumption that many of the issues are really just manifestations of lifestyle differences, and it's largely because of lifestyle issues that I feel I can identify with many of the problems that women face when dealing with "hacker culture" in general and "free software" in particular.

Comments

I'd always assumed that women were well represented in the Free Software Community because I saw names of some prominent female developers and simply imagined that there must be many more.

What a dreadful pity that your statistics show the opposite to be the case.

It is also completely shameful that even the proprietary software developers can easily outdo us in the matter of female participation.

Free Software Community, but not so free when it comes to women taking part. Software development is certainly an area one would expect to find women being able to work on an entirely equal basis with men.

I'm very disappointed with this finding and will certainly use this article to attempt to alter my own attitudes, where necessary, and to influence others to do the same.

These aren't new statistics of course -- they were collected a couple of years ago. But I don't think there's been a lot of good ideas about what to do about them. People know it's bad, but they don't know how to respond to it.

This article started as a series of design notes that I was collecting for my own use in creating a better, more inclusive system to encourage more people to participate in development processes. I wasn't particularly interested in women's requirements -- I just wanted to "assess user needs" and find practical and tested design ideas.

I am in fact writing another article (the next in the Making the Impossible Happen... series) about community design to encourage "an atmosphere of productive leisure", which is more general in scope. Which is why I'm publishing this now.

But it was a fact that most of the other communities I was studying for ideas were much more representative (some were about 50% women or even more). Also, there were some features or technologies that women used more than men (and vice versa). So the software certainly can be "gendered" (as Yuwei Lin puts it).

Later, I was made aware of the FLOSSPOL statistics and the various women's involvement projects (Debian Women, LinuxChix (which has the best FS logo ever, BTW), etc) through news sources, and I too was floored by the statistics (the FLOSSPOLS reference, BTW, contains a lot more detail than this. I don't recommend reading the whole thing, but the summaries are well worth your time).

Studying the reports, I saw confirmation of most of the trends I had noticed from watching the online behavior of men and women in different online environments, and I felt it was time for an article focused on the gender issue. At first I was a little self-conscious about writing this as a man ("what do I know about it?"), but the more I got into it, the more important it seemed (which is why this post became so huge).

And why does it suppose to matter that woman are not into free software? I cannot explain the logic in this? Usually woman being into computers is not so much of a big deal as it was before. I've been seeing a lot of these "woman need to get into computers", "how to attract chicks with Linux", lately and it needs to stop. How this article pinpoints woman directly sounds more like dating tips, and it's just fu**ing retarded. [Edited for language. Please. Next comment with swear words will be deleted]

No. I'm suggesting that the ad hoc way we have managed projects up until now is obsolete and that it creates the social barriers that have driven a lot of people away from contributing (women disproportionately, though not exclusively).

If we can get rid of that bad process, we can get rid of the barriers.

While I can agree with some of the recommendations - for example, I'm all in favor of courtesy and of giving generous credit to writers of documentation - I'm wary of replacing mailing lists with web forums, deep threading with flat threading, solitary programming with team programming, et cetera, simply on the basis of perceived female preferences.

When we talk about what women want, we need to specify the population in question: different women want different things. And a project leader may rightly care more about the desires of women who've already paid their dues, wrestled their way through the manuals, and arrived at a position to contribute than about the perceived preferences of women in general.

It might also be useful to broaden the discussion to consider women not only as contributors to existing OSS projects, but also as originators of such projects. One problem I've run into is a lack of coding capability and open-source awareness in the (overwhelmingly female) group of end users to whom my particular programs might be useful.

I have a background in both math and art, and, over the years, I've taught myself to program in C++, Java, and Python (with forays into Perl and Gimp's Lisp-based scripting language) by writing software for textile design. I've always been more than willing to share my source code. But the knowledgeable, code-contributing end-user audience on which open-source projects depend just doesn't seem to exist in the textile-design field. Instead there are countless people eager to hand over money for proprietary software like Adobe PhotoShop, Adobe Illustrator, SymmetryShop, and SymmetryWorks but dismissive (when not ignorant) of open-source alternatives like Inkscape and Gimp. I'm not a marketing person or natural proseletizer; I don't have the time or the talent to run a one-person campaign for OSS (let alone for my own efforts) within the largely technophobic textile community. Thus I've always wound up code that's useful to me, but not really promising as an open-source project.

My mistake, if it is a mistake, has been to tackle problems of interest to an audience for whom open-source and programming in general seem to hold little appeal. Had I applied my efforts to problems in a stereotypically male field (e.g., gaming rather than textile design), I might not have encountered such isolation. It's possible that female developers willing to share their source code will gain more visibility (not to mention social and emotional support) as women in general become less technophobic, more open-minded, and more receptive to open-source.

I don't have experience contributing to other people's OSS projects, and so I can't comment directly on that. But I have been reading online technical discussions since 1992 and Slashdot since its inception (admittedly, mostly lurking rather than posting). Much as I dislike flames, acrimony, and Asperger-ish behavior, I've often found these conversations more nurturing and emotionally "safe" (to me as a whole thinking human being) than the online talk I've encountered in female-dominated milieus (the LinuxChix groups being a welcome exception to this rule). So, I'd urge caution in reframing OSS development practices to be more "social" and less task-oriented. (Just my two cents, of course.)

Many other interesting points were raised in this article - wish I had more time to comment. Thanks again.

I agree that you can go too far with a focus on social involvement. However, I do think that this is already a major motivator for people to be involved in free software projects, though it is conspicuously missing from lists of reasons for involvement that I have read, and I think that the current environment is very male-centric in the forms of social gratification it grants. Paying some attention to the way women (in general) deal with these needs will make the whole more balanced in my opinion -- and not just for women, but to a wider variety of male participants as well.

It's also true that for any particular project you must consider the needs and makeup of the community it's meant to serve, and that means looking beyond gender generalities.

I wonder though if such a web community approach wouldn't have been perfect for your project? Aren't you in the position of trying to motivate people with textile expertise and limited programming skill to become more involved with programming and using free software?

I had a very similar problem with my own project The Light Princess, because that project depended so heavily on artwork and music. I wasn't selling free software developers on making art and music; I was selling artists and musicians on the value of free software. Obviously, the project was not terribly successful as a whole, but I did find people willing to contribute (about 50% women, as a point of interest). Not one of the artists ever joined the mailing list -- they would pass stuff directly to me, and I would post it for consideration. Nowadays I would've set up a wiki for that, but that was pretty new technology in 2000. If I ever get the game engine software to run, I will probably revive the project following a strategy similar to what I've outlined here. Then I guess we'll see if it works.

Also, if your project has to do with creating textile pattern graphics, I would like to personally invite you to participate in Linux Graphics Users where I think this should be on topic (probably under vector graphics? -- I'm guessing you're doing something akin to CAD). My username there is "Digitante". Of course, it is a users forum, but I know we'd be interested. Also, my mother is both an expert in needlecraft and a Linux user, so she'd certainly be interested in free software tools for textile work, though I don't know how equipped she'd be to contribute. I'd love to be able to recommend your software to her, if you could let us know where to find your project.

We face the same problems with all artistic and even engineering software packages -- the primary users usually have a limited interest or expertise in programming. I'm also seeing the same kind of problems with Open Hardware projects for things like "electronics design automation" (EDA) and "computer aided design" (CAD).

But while that is clearly not a gender issue, it does hold up the value of keeping the gate open for potential contributors with low-confidence in programming and hesitancy to join into the developers' discussion. If you make the slope between users and developers a little more graded, you may be able coax some of those folks to cross. There are ways to make use of their core skills while minimizing the software knowledge they need (e.g. build in easy scripting for adapting the software to more complex design problems), and that's probably the key to making it happen.

The idea of a navigable slope between end-users and developers holds enormous appeal, I think, for anyone who believes in open-source. Thus, any measure that helps users take part in development (e.g., a wiki, or hooks into the program that allow for scripting add-ons/plugins) deserves consideration. But some end-user communities operate at such a remove from some development projects that direct communication is nearly impossible. In some cases no wiki or scripting language or change of social customs is quite enough to bridge the gap.

Consider, for example, the ImageMagick suite of command-line tools for cropping, combining, and transforming bitmapped images. It's fast, powerful, and wonderfully flexible, with a dazzling (and initially daunting) array of options. I was thrilled, years ago, when I first stumbled across it. At that point I'd been active for years in the online textile community, connected to thousands of artists and craftspeople with image-processing needs. It says something, I think, that I first learned about ImageMagick not from fellow artists and craftspeople, but rather from a listed dependency in some other graphics program (can't remember which) that I was trying to run or compile under Linux.

While the ultimate end-users of ImageMagick may be artists with no interest at all in command-line tools, the intermediate users are programmers and writers of scripts. At this point ImageMagick has interfaces for incorporation into programs in C, C++, Java, Python, Ruby, Lisp, Tck/TK, etc., and I'm guessing it lies hidden under the hood of a great many graphics applications.

What we're looking at in this success story, I think, is two distinct user/developer slopes: one connecting end-users with graphics application developers and another connecting these application developers with the developers of ImageMagick. Thus, the people who work on ImageMagick just have to produce a good command-line product; they don't have to get into all the subtleties of gui design and open-source promotion for the various end-user audiences. And they don't have to explain complicated ideas (all those concepts underlying the many ImageMagick options) directly to those who ultimately benefit from those ideas.

The ImageMagick people have been able to fit the project to the community, I think, because the relevant community for that project is not the ultimate end users but rather a fairly large group representing the intersection of three sets:

(1) people with programming or at least command-line skills,
(2) people interested in computer graphics, and
(3) people who believe in the open-source development model.

No analogous group exists in the case of the suite of command-line utilities that I've been working on for textile design. In practice, this means that a successful textile design project needs to provide not only the core functionality (i.e., methods for combining multiple bitmapped and vector images into non-obvious repeat patterns in various colorways), but also a not-too-intimidating gui front end, plus end-user documentation, support, and "marketing."

I'm currently working on putting a web-hosted front end on a subset of my command-line utilities - the only way I can see to make my efforts useful to people who, overwhelmingly, don't install their own software, don't use Linux, don't read wikis (except Wikipedia), don't use the command line, and tend to fear (as a source of viruses, not to mention frustration) any product that isn't already well known or at least slickly packaged. The web 2.0 approach can get around these obstacles, but it does take extra effort: the effort of running a server, designing a web gui, and writing all the web code.

People create software not just out of altruism or to learn new skills and improve their resumes, but also because they need tools to pursue their own core interests. In some cases the problem field isn't all that negotiable; it's the developer's primary concern and motivation. If the problems the software solves are of interest mainly to a specialized audience with a low threshhold for computer frustration, then the developer who wants to share his/her efforts and reach this audience may have to take on a lot of extra work.

At this point I'm willing to do that extra work, but only if I get at least some nominal payment. Thus, I plan to charge for some of the web-based services; that seems the necessary route to respect within the textile community. Meanwhile an ancient version of the core code is at patternand.org. I do plan to update it and write some documentation after I get the web-based services going.

Finally, I'm delighted to hear your mother is using Linux; needlework-and-Linux stories are rare but always heartening. Thanks for the link to linuxgraphicsusers.com; the site seems very well-run with a good cross-section of users.

There is much work to do in this direction.
I tried to apply it on a mailing list, but it received mixed results.
A guy suggested that some program was so bad, that someone should cut of programmer's fingers. Now he wasn't really meaning it, but it would still drive people off. So I tried to point out that saying such things is wrong, but the effort was met with:
"Can we let this panty-wetting, cry-baby discussion die please?
He's rude, and pissed-off. Get over it and move on to another discussion."

I think you should add this to your list of things driving people off and which should be avoided.

This is where active moderation and out-of-channel communication can help a lot.

When you respond to a rude post with another post, which can hardly help but be rude itself, it leads to a perpetuation of the thread, which perversely makes it more visible, thus increasing the negative impact of the original rude comment.

But in a moderated forum environment with more out-of-channel options, you might:

Delete the post

Modify the post, by excising the rude comment but leaving in the essentials

Downgrade the post by a voting or "moderation points" system (note that showing formal disapproval of the post may be all that's need to mitigate its impact -- people who are sensitive to such things are often more afraid that such behavior is accepted than that it occasionally happens)

Ask the original poster to tone down their comments in a private message (e.g. ask them to edit their own post)

I've done each of these as a moderator before, and it's generally possible to do it without sacrificing real content. Usually, even the rude poster will realize the benefit of it (especially if the improved comment leads to a constructive response).

Great article! Thank you for all the information. Here you have given good pointers on why advocacy for freedom is a tough job: it requires women skills in a non-social/competitive/man-only community.

Please comment on the following points:

- Mailing list can be moderated too.

- Moderating can cause people to stop expressing their feelings and quietly abandon collaboration or simply use undercover manipulation techniques. Consensus is the best way to make everyone feel part of a project and make great efforts to get it better. But it requires that people can freely express their feelings. Obviously some way to motivate people to be polite and nice without forcing them could be good.

- You talk about free software (as in freedom) but you do not give the freedom to modify your article.

Author information

Biography

Terry Hancock is co-owner and technical officer of Anansi Spaceworks. Currently he is working on a free-culture animated series project about space development, called Lunatics as well helping out with the Morevna Project.