Designers, Women, and Hostility in Open Source

After working in technology for 17 years now, I can assure you: constantly being the only woman in the room stinks. Since I usually am, one of my career goals is to surround myself with capable women technologists as well as men. It’s not easy, but it’s important—and not just because I’m lonely, but because I make stuff, and creations reflect their makers. The tech industry is by and large a boys’ club, and that’s a shame, because homogenous teams turn out one-dimensional products. Diverse teams are better-equipped to make things that shine because they serve a wide range of people. (Related: The Case Against Drop-down Identities.)

At Lifehacker, my original vision was to create a new kind of tech blog, one that wasn’t yet another “boys worshipping tech toys” site, one that was helpful, friendly, and welcoming versus snarky, sensational, and cutting. (That was no small task in the Gawker-verse, and I learned much in the process.) Today at ThinkUp, I have a similar goal. 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. We explicitly identify inclusiveness as one of the best characteristics of our small, up-and-coming community. Still, uptake is slow, the on-ramp steep, and for me, it constantly begs the question: what we can do better?

That’s why an essay by UX designer Vitorio Miliano, Designers and Women in Open Source, caught my eye. Miliano theorizes that there aren’t many designers in the open source world for the same reasons there aren’t many women: because open source communities alienate non-coders and newbies by design. He writes:

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.

That’s a punch in the gut for OSS leaders who work hard, often in their spare time, to create a democratic process and collaborative workflow for total strangers located around the world to create something as complex and technical as software. (Especially those of us who identify as feminists.)

But Miliano’s right. And as far as I can see, it’s up to OSS leaders to work even harder to redesign their communities to encourage diversity instead of prevent it. Because it helps me to think aloud and write things out, here are some approaches we’ve implemented, discussed, or are considering at ThinkUp.

Welcome Wagons, Mentors, Conversion Rates, and the Power of Nice People

The best part about working on an open source project is that you’re not just building a software application; you’re building a community. In addition to making first-class software, ThinkUp’s goal is to be the ultimate “gateway project,” a friendly, accessible virtual neighborhood that people want to live in and build up, especially if they’ve never been a part of OSS before. One of my main metrics for measuring our success is how many community members’ first-time OSS contribution happened at ThinkUp. We love handing out the Nerd Merit badge to first-time contributors.

Converting a newcomer into a contributor starts with a warm welcome.

At Lifehacker I learned something important about creating a productive online community: leaders set the tone by example. It’s simple, really. When someone you don’t know shows up on the mailing list or in IRC, you break out the welcome wagon, let them know you’re happy they’re here, show them around the place, help them with their question or problem, and let them know how they can give back to the community. Once you and your community leaders do that a few times, something magical happens: the newbie who you welcomed just a few weeks ago starts welcoming new folks, and the virtuous cycle continues.

We’re still relatively small, but at ThinkUp we’ve done a good job of this so far. After two years, we pride ourselves on two things: 1. newbies are welcome, and 2. while we’ve had passionate conversations, we’ve never had a single flamewar or ego battle on our mailing lists.

Mentoring new contributors is also a powerful way to grow and diversify your community, and create long-term, loyal contributors. After last year’s success in Google’s Summer of Code mentoring program, we plan to do more mentoring/internship programs for new coders at ThinkUp. Creating bonds between new coders and veterans strengthens the community and attracts even more like-minded contributors who enjoy collaborative learning on a common project.

For coders, the path of promotion from user to contributor is clear-cut, but the on-ramp is not as obvious for non-developers. An early thread on ThinkUp’s mailing list, subject line The frustration of a non-developer, began our community’s clarification of what, exactly, constitutes a contribution to the software. Turns out, it’s not just code.

Clarifying and Encouraging Non-Code Contributions

For programmers, the process of contributing to an open source project goes like this: you download the source code, you change the source code, and then you submit your changes to the project maintainers in the form of a patch, and if that patch gets accepted, your contribution shows up in the software. Done.

What’s not clear is how people who don’t code contribute their skills and expertise to making OSS software. Because it’s not clear, they don’t, and the software looks and feels like it was designed by engineers, for engineers—because it was.

At ThinkUp, there was a time that I was so focused on perfecting the right git branching strategy, I forgot that contribution does not always equal code. This is an area where we can still improve, because there are so many different ways non-coders can and should contribute to the project, including but not limited to:

• Showing up in the IRC channel and welcoming newcomers
• Offering tech support on the mailing list or in IRC
• Transferring knowledge shared on the mailing list or in IRC into the project wiki
• Following up on tech support questions on the mailing list or in IRC with further questions, links, or additional information
• Filing bugs in the issue tracker, or updating existing issues
• Taking screenshots and documenting details of confusing or clever bits of interface
• Recognizing good work by community members; discouraging unwanted behavior; acting like the kind of community member you want to work with
• Tweeting, blogging, or Facebooking about project news, developments, or features
• Hosting, showing up at, or blogging a project podcast
• Pairing up with a project “buddy” to work on an issue and brainstorm solutions
• Mocking up or wireframing interfaces for existing or desired features, even if it means using a tool as simple as Microsoft Paint

Sometimes turning a non-coder into a contributor is as easy as pointing them to a wiki page and asking them to add text about their experience using or troubleshooting the software, like Dan did here.

When an OSS community has a code-centric view of project contributions, not only does community, documentation, and technical support suffer—the software does as well.

Adjusting Community Values: Prioritizing Design and Usability

A well-built software application does more than just function: it’s beautiful, frictionless, self-explanatory, and it performs a task and stays out of your way. Still, interface design doesn’t get nearly the respect and prioritization it should by typical OSS engineers. (Myself included; this is another area where ThinkUp can improve.)

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?

When “polish” is a priority, when it’s discussed, recognized, rewarded, solicited, and it’s a required part of the patch acceptance process, programmers will be motivated to do the work to get it right. 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. This is been the lesson I keep having to learn and re-learn: design and usability cannot be an afterthought.

Cutting features in the name of usability is an especially sticky wicket when those features were built by volunteers in their spare time, but this is where project leadership steps up.

Design by Committee and the Benevolent Dictator

Feature/option bloat is a common pitfall for all software, but it’s especially so for open source software built by a democratic community of self-starting engineers for whom it’s too easy to say “I’ll just hack up a little button that adds my pet feature and stick it here.” Every OSS project has a single committer or team of committers who have final say about what features and fixes get merged into the application. Some projects have a Benevolent Dictator, who has final say on decisions that the community can’t reach consensus on. It’s the committers’ and the BD’s role to ensure that end users come first and engineer’s pet projects come second.

However, good project leaders don’t rule with an iron fist; rather they sell a vision for the software and its priorities to the community so that the community comes to good decisions on its own. When it cannot reach consensus, the BD steps in. Karl Fogel explains:

Although “benevolent dictator” (or BD)is the standard term for this role, it would be better to think of it as “community-approved arbitrator” or “judge”. Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It’s unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won’t stay around unless they have some influence on the project’s direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say “This is the way it’s going to be.” Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.

Because an OSS project’s BD is not actually a dictator with swift and final say on all decisions, these community decision-making processes can take months and even years. After his logo design was rejected after a year of discussion by contributors to an open source project, Miliano says that on a non-OSS team, the contributors who spoke up wouldn’t have had a say at all:

I would wager that as most of the developers of any given open source project are not representative of its end-users, the developers wouldn’t even be involved in the design process in the first place. You can’t design by committee, only take into account the needs of the stakeholders, and if you don’t actually use the software, you might not be at that table. The designer would, essentially, only be generating work for them.

I think there’s an in-between here, and at ThinkUp, we’re still finding it. We’re working with Mule Design to redesign the app’s look and feel and interface. While we’re only at the beginning of that process, in the kickoff we decided that design by committee was not an option. The community will not vote on a list of design options. Instead, Mule will create a design and sell it to the community at large, citing what they learned about the app from its stakeholder and end-user research. To keep the community informed along the way and encourage buy-in on the process, they’ll share what they learned and what they made as they reach milestones. Because Expert Labs funds ThinkUp development, contracted Mule, and acts as ThinkUp’s benevolent dictator, there is no question: we will implement Mule’s redesign with community buy-in—even if everyone doesn’t agree on every single pixel.

Your Community Is Your Best Feature

On the modern web, where far-flung strangers collaborate on things like authoring an encyclopedia and overthrowing abusive governments, it’s still too hard for most people to contribute to open source projects. It’s ironic, too, because open source collaboration was happening on the internet way before tools like Facebook, wikis, Twitter, and Google Docs existed. It’s not for lack of tools, it’s because of broken culture. Miliano writes:

Open source platforms are a community in the traditional sense of something you pretty much have to be internally motivated to join. Joining an open source community is closer to joining a church or moving into a neighborhood, and, let’s be honest, these neighborhoods are sexist boy’s clubs with no facility for mentoring, no respect for design, and mailing lists that are 50% dick-measuring contests.

But that’s not the way it has to be. If OSS projects do what it takes to welcome contributors of all stripes, not just the usual suspects, they’ll produce better software. At least, that’s our bet.