Recently I was a guest on a panel podcast hosted by Cal Evans that included Laura Thomson, Beth Tucker, and Anna Filina. It was entitled “Sexism in Tech” and was a response to some of the recent goings-on in the tech community. It was a very fun podcast, and I encourage you to give it a listen. Even if you’re tired of hearing about the issue, I promise there will be something there you can take away, because we didn’t just rehash the same old conversations.

While we talked about many things related to being a woman in a male-dominated field, one of the main things we talked about was this feeling of empathy. And it got me thinking about a few things.

So, my kids love to play the Punch Buggy Game. If you don’t know the game, it goes like this: when you’re driving around, if you see a VW Beetle, you call it out and punch the person next to you in the arm. In our car, it usually goes something like this:

When someone posts something controversial or “offensive” on the Internet, it’s kind of like playing a game of Punch Buggy, except it goes something like this:The thing with punching someone in the arm is, you really don’t know if you hurt them in the process. You aren’t that person, and you’re not feeling that pain. You can imagine what it would feel like for you if you were the one being punched and how you’d react. And if it’s different than how the other person reacts then clearly there is something wrong with them. But I can give the same punch in the arm to Mike Tyson and an 83 year old woman, and I can pretty much guarantee it will not feel the same to each of them. (No, I’m not advocating punching 83 year old women in the arm, for the record.)

My point is that unless you are a true empath, you can’t feel the other person’s emotions. So for you to tell me that something doesn’t offend me, or that a punch doesn’t hurt me, well, that’s kind of ridiculous, isn't it.

Just as there is a range of pain, there is a range of offensiveness. A punch from Mike Tyson will elicit a pretty similar reaction in everybody, just like there are things that happen that offend a large number of people. But generally speaking, what may be offensive to one person may or may not be offensive to another.

The farther away you are from a situation, the harder it is to empathize. If you’ve not been a minority in a group before (especially in a career-type setting), then it is hard to even imagine what that’s like. A male friend recently came to me and told me about a childcare situation he was in where he was the only male. In this group of females, he was already feeling a bit apprehensive when one of them made a joke about him being a pedofile, and why was he there, etc. etc. He didn’t think the woman meant anything malicious, but was instead just clueless. Unfortunately, her insensitivity left my friend feeling hurt and even more awkward than before. Even though he loved working with kids, it tainted his whole experience, and made him question whether or not he even wanted to continue. A few synapse connections later, my friend came to me and said “now I know what you guys must feel like in this industry. I’m really sorry on behalf of us all.” In our game of Punch Buggy, my friend realized that a punch in the arm can hurt, even if the other person didn't mean for it to.

Now, in contrast to Punch Buggy, when my kids play with Legos, it usually goes something like this:

The dynamic the kids have when putting all things aside and just being creative is completely different than the Punch Buggy game. In theory, they could argue that the car isn’t really a car, because it doesn’t really look like a car, and the door isn’t a door at all, and that it really should be used for a window. But they don’t. They just create. They don’t criticize. They don’t try and convince each other that the other person is wrong. They don’t make assumptions about what the other person’s intentions were, or how they are feeling. They just create. They encourage, they discuss, and they create.

This is the tech culture that I want. I want to remove gender bias. I want to remove age and racial discrimination. I want people to stop arguing over what programming language is better. Or platform. Or text editor. Instead, I want people to encourage, to discuss, and to just freaking create.

As I said on the panel discussion, this is our culture. It is what we make it. It is not dictated by some corporation somewhere. It’s ours to make and mold and shape into whatever we want. So I say more Legos, and less Punch Buggy.

Consider this a call to the PHP Internals team. We've been doing a series of panel discussions over at Engine Yard about PHP-related frameworks and where they are going in the future, but one important piece that's missing is the discussion about the future of the PHP core.

A few weeks ago, I approached Rasmus about this and we both came to the agreement that it would be very difficult to nail down core devs to a handful of people. The PHP core team is large and far-reaching. How do you decide who to ask to participate? The only solution is to open it up and include whoever wants to be included.

I didn't want to spam the internals list with this, so I'll just put it out here on my blog, and hopefully the word will spread. If you're a core PHP contributor and you want to voice your opinion in a friendly panel discussion about where you'd like to see PHP in 5 years, then I'd love to chat with you and include you in the discussion.

You can find me at enaramore at engine yard dot com, or my personal email at elizabeth at naramore dot net. Hope to hear from you!

Sometimes opportunities come along that you just can't pass up. Such as the case for me these days; I'll be leaving my job as Community Development Manager at SourceForge for a job at Engine Yard as the PHP Community Manager. As you might have heard, Engine Yard recently acquired Orchestra, and as such, is making a splash in the PHP space. (This is awesome on so many levels.) I am extremely lucky to be on Randall Thomas's team (@daksis for those who don't know him), whom I had the great pleasure of meeting in person last year at JRubyConf. Not only will I get to work with Randall, I will be working closely with the Orchestra team; a group of collective awesomeness. WOOT! I kind of feel like I'm "coming home" to my PHP community, and that makes me really happy. And not just the "Hey, I didn't spill anything on myself today" kind of happy, but the "I need to high five the shit out of someone" kind of happy. You've all been warned.

I've greatly enjoyed working with the folks at Geeknet, and have met some *very* smart people along the way. Incidentally, they are now in need of a "Community Growth Hacker" for SourceForge, so if this sounds like something that might be of interest to you, by all means, let them know! They are a terrific group of people.

I will say goodbye to Geeknet on October 9, hello to Engine Yard on October 17, and in between, I'll spend some time at Brooklyn Beta. You'll also see my smiling face at PHPNW, and probably ZendCon, so I hope to get a chance to chat with you. I want to hear what's new with *you*!

I'm thrilled to announce that I'm starting a new contract job working for Geeknet, and in particular, SourceForge. I will be their new OSS Outreach Coordinator, which means I get to spend my time helping open source projects be more awesome. I will work closely with new and existing projects to figure out what help they need and how SourceForge can help fill those needs. There are a lot of cool things going on at SF right now, and I'm thrilled to be a part of it! Also, I get to work with Jeff Bates (hemos from Slashdot) and his team of awesomeness, which seriously does not suck.

In case you haven't seen the latest SF news, they've redone the entire site from the ground up, and added more tools to make lives easier for devs and end users. We're breaking apart the bundle of SF services, so that projects can use whatever they need (and of course, everything is still completely free). For instance, OS projects can use just the download service to take advantage of SF's global mirror network, even if they want to keep development on someplace like github. SF is serving up about 3 million downloads a day, and their mirrors serve on average 2.25 gpbs. Also, Adobe is now hosting their open source development community on the new & improved SF, which is very cool. (Btw, if you have feedback on the new forge, we'd love to hear it.)

I'm really glad to be involved in helping SourceForge help open source, because that's really what it's all about-- making open source better.

Why I care, and you should too.

Many people know that when I can, I help Ed Finkler out with Spaz. I don't contribute to the code base, but I help with end-user support, and I help coordinate the efforts of other end-user support people. Many people also know that I work with PHPWomen and of our attempts to boost open source involvement with our members through the PHPWomen Partnership Program.

Interestingly, the issues involved with both of these groups overlap. As those in the open source community who either contribute to, use, or advocate open source projects, we understand the importance of keeping them vibrant and active. We understand how great it is to be a part of a growing project we believe in. We understand the benefits of being an active community member. We understand that it not only helps the good of those around us, but it helps us hone our own skills. So what can we all do to get more people to contribute? Even if you aren't a project lead on an open source project, you don't want to see it fail. The obligation to keep things going lies within us all.

I get curious about things sometimes, and when I wondered "where is everybody?" I wasn't sure of the answer. There are so many great opportunities in open source projects. Are people taking advantage of them? Do they even know about them? Do people even care?

What the "research" showed.

Naturally, my first thought was to ask Twitter. So in this completely non-scientific poll, I asked developers who weren't contributing to an OS project, why they weren't contributing. At the time of this post, there were responses from 264 people, and I allowed people to choose more than one reason. Of course this is by no means exhaustive, nor is it meant to be a substitute for any real research on the matter. But I think this does give a little insight.

Although there are many things that keep us from contributing (including one person who "thinks people like Ed Finkler are scary"), the top three replies, by far, were these:

1. Not enough time.
2. Not sure where or how to contribute
3. I'm not confident enough in my own skills.

Numbers 1 and 2 were no surprise to me. Funny thing about Number 3, though; I added that as an afterthought. It was one reason I personally always shied away from contributing, but I figured surely others were more confident in themselves. I found these results quite interesting, and I'm a bit relieved that I'm not the only self-conscious one out there.

So what?

How can we overcome these obstacles to encourage more participation in our projects?

Let's look first at Number 1: TIME.

It would be great to have more time. We all need more time. Nobody has enough time. Yeah, yeah. We get it. I don't foresee that changing anytime soon, so how can we work with this? Here are some ideas for project leaders/devs:

• Break up big jobs into little jobs. If you need help with documentation, break it into smaller, more manageable chunks. Chances are, you'll have better luck getting someone to write a one-page doc as opposed to a 20-page doc.
• Quantify time commitments. I tried being a member of our elementary school's PTA, but for some reason I didn't quite fit in with the other moms (long story; I'll tell you over a beer sometime.). While I still think those people are crazy, one thing I'll give them credit for is that they know how to recruit volunteers. They tell you up front how much time a task will take. Only then can volunteers make an informed decision about whether they can step up. Much like putting a monetary price on something, you are telling people how much it will "cost" them.
• Keep time commitments minimal.. Something else the PTA does right, is that they've mastered the art of breaking things into 15 or 30 minute increments. They tell you up front "this task will take you 15 minutes" or "we need someone to take carnival tickets for 15 minutes." And really, who doesn't have 15 minutes in the day to work on something they care about? (Ok, there may be one guy out there; his comment on the poll was that "his wife would kick his ass for doing something that took away from family time without financial recompense." He might not really have 15 minutes to spare, poor guy). Even bigger tasks can be broken up per day; 15 minutes a day works out to almost 2 hours a week. Not too shabby.

What about Number 2? UNCLEAR EXPECTATIONS.

People aren't mind readers; they like to know what you need from them up front. Here's what we can do about this:

• Define what exactly is needed. We've started doing this with the PHPWomen Partners - by explicitly defining areas where the most help is needed, you make it easier for potential contributors to see how they can help. Makes sense, right?
• Make the "how to contribute" page on your project website clear as day.Help them help you. Don't make potential contributors search for or guess what you need help with.

And Number 3? LACK OF CONFIDENCE.

If we don't keep the cycle of contributing going, and include new people on a regular basis, inevitably the cycle will die, and the project will stagnate. We all have to start somewhere, and we all make mistakes. So what can we do to convince people that you don't need to be a super ninja coder to contribute to a project?

• Save some low-hanging fruit for beginners. It's easy to do the easy things. But think about it, if you only have more advanced things on your to-do list, then your chances of attracting a beginner are much more slim.
• Communicate that you have a welcoming atmosphere. We do this through the PHPWomen partnership program also. The goal is to encourage participation, and to reassure new members to the community that they will be accepted. Remember, potential contributors to your site are not mindreaders. If you don't tell them, they don't know.
• Appoint an ambassador. Having one person that can help newcomers to the community understand how things work, what it means to contribute to open source, where to go for questions, and that sort of thing can go a long way in actively recruiting new participants.
• Make it clear you have other needs besides code. Many projects are also in desperate need of design, documentation and support help. Many also simply need users of the software to help other users or to help spread the word.

The bottom line is, if you're involved at all with an open source project, you have a vested interest in seeing it thrive. In order to do that, you need to "sell" it. You need to sell how great it is to use, and also how great it is to work on it. You need to actively encourage people to participate by keeping in mind the three main obstacles above.

What other ways can we recruit new faces to our open source projects? I'd love to hear your thoughts.