Catching up with Leslie Hawthorn

I think the most important lesson I learned was to just get out there and make things happen, no matter how many mistakes you'll make along the way and no matter how many pairs of eyes are watching you make those mistakes. When I started with the team, I had no FOSS experience whatsoever and was quite worried about doing the wrong thing, and very publicly no less. Over time, I realized that it was far better to make as much progress as possible and make the inevitable course corrections required rather than try to get everything right from the start.

I've also learned that a small group of people who are dedicated to making the world a better place can be incredibly successful in doing just that. It may sound like a cliche, but I never imagined when I started working on Summer of Code that I would have the chance to help so many individuals and projects make things better, from finding new contributors to improving their community structure and relations. Granted, having the power of Google as a company and brand behind the program contributed a great deal, but the real power in Summer of Code is the individuals who contribute to making it a successful way for students to or contribute to FOSS.

As for what I would do differently if I could reboot the program, I think it's working quite well the way it is. It would be excellent to scale pay for the student participants according to their respective geographies or vary the program time line a bit more to take into account various school schedules, but that's just not possible with 2-3 people on the Google side managing logistics. I like to imagine how epic Summer of Code could be with a team of ten people working on it, but that's not particularly logical when you consider the overall size of the Open Source Team.

There are times I think that removing the monetary component would be a good thing - just have folks do the program for the recognition and the t-shirt. It would certainly make administration easier and allow more students to participate in the program. However, I also realize that one of the original goals of the program was to provide students with gainful employment in addition to programming experience, and t-shirts, while completely awesome, do not pay the rent or put food on the table.

I think it has been incredibly effective. When I meet up with GSoC students, most of the individuals I speak with had only been using FOSS, but had not contributed patches or fixed more than a few minor bugs. The best aspect of the program, though, is simply spreading the idea of FOSS' importance to the next generation of programmers. The participants in the program become wonderful evangelists for open source, whether or not they remain core contributors to the projects they worked on for GSoC. I think many of the students who have participated in the program will be instrumental in seeing that FOSS is used in the companies that employ them once they enter the workforce.

I think about half the code produced during GSoC ends up merged into project source trees, but that's just an educated guess. Several projects ask their students to work on research implementations of particular features and, as with all software development, some of what is produced ends up not being the most practical solution. On the other hand, I sometimes hear from program mentors more than a year after a particular GSoC that their student's code just entered the mainline. I think the education that the students receive in FOSS and software development in general is more important than the project work they produce, but certainly a great deal of useful code has been written due to GSoC.

I'm particularly proud of the Google Highly Open Participation Contest, which was the world's first global initiative to introduce pre-university students to open source. The contest has only occurred once, though I believe Google has plans to hold it again in the future. The effort was incredibly successful - more than 350 students worldwide participated and completed more than 1,000 bite sized tasks for 10 open source projects. The best thing about GHOP was that it focused on all aspects of FOSS, including documentation, user experience research, marketing and advocacy, not just code. That holistic approach to software development made FOSS more accessible to a wider range of young contributors. I'm actually in Vermont right now as I'll be accepting an award for GHOP from the National Center for Open Source in Education on Friday [April 9, 2010].

I'm also proud of launching and managing the Google Open Source Blog, which now has over 17,000 subscribed readers. The blog gave the team the opportunity to talk about all the great work Google does for the open source community. It also gave Google a great venue to showcase all the wonderful things the community was able to do with company's help, from news about GSoC to FOSS development sponsored by Google.

First and foremost, make it very clear if you are willing to mentor folks on your project. A "help wanted" note on on your project home page is a good start. Don't be afraid to clearly spell out exactly the kind of contributions you are looking for - if your project will only benefit from folks who have advanced experience in machine learning, that's OK. Folks with a less developed skill set in that area will find another good home. It's also great to have someone specifically assigned dealing with newcomers and helping them get up to speed on the basics quickly before handing them over to someone who can help guide them in a particular area in depth.

Share your mistakes with your mentees. It is incredibly easy for someone less experienced to feel like you are some kind of deity and that your hard won knowledge is somehow an innate ability. By showing off some particularly ugly code or talking about your own faux pas on a development mailing list, you give those with less experience more confidence in their ability to go from newbie to seasoned contributor.

Be available as much as you possibly can be, especially when first starting the mentoring relationship. People do well when they feel like their contributions matter and their voice is heard, and they'll feel neither if they don't hear from you early and often. Once the relationship has been established, you can take a bit more time to answer questions, etc., but during the first few weeks being there as much as you can be is incredibly important. It's also worthwhile to be there often so you can steer your mentee to asking the community for help so that he is not solely reliant on your guidance or opinions. As long as your mentee feels like you're there for a particularly complex or troubling issue, she will be more likely to ask others for help on the easier matters and become more integrated into the wider community as a result.

Don't be nervous about your lack of experience, just dive right in. Check out a project's mailing list for an idea of what's most important right now and what has been important in the past six months or so. Then join the project IRC channel and lurk for awhile. Don't worry if no one acknowledges you or says anything at first. Eventually, when you have an idea of what you'd like to do for the project, say implement a cool feature or host a user group in your home town, then speak up in the channel. Don't ask to ask a question, just ask it. Be prepared for people to not think you'll carry through on your intended efforts - many people get very excited by the idea of a project but don't actually get stuff done, so the folks you talk to will naturally wonder if you fall into that category. This is OK and completely natural - once you've sent in your first patches, updated the documentation or created that project presentation and asked for feedback, you'll see more engagement with your ideas and get more help from the community to further expand on your work.

Thanks to Deb Nicholson of the Free Software Foundation, an entire day's track at Libre Planet was devoted to getting more women involved in Free Software. My talk revolved around some basic points for mentoring, a few of which are enumerated above. The points aren't gender specific, but I hear from many, many projects that they are specifically interested in mentoring folks who come from groups underrepresented in their project, particularly women. I think mentoring is particularly valuable to women and other underrepresented groups since the social group that they are approaching doesn't have as many people in it who look like them, literally, and it can be difficult to feel comfortable and welcome in such an environment.

For groups looking to attract a more diverse group of contributors, start with the basics. Go to the members of your community who are underrepresented and ask them what you think can be done to improve the situation. (Note that no woman can speak for all women in FOSS, just like no man could speak for all men in FOSS, so this may be a difficult conversation at first.) Ask them why they were excited about the project in the first place, whether they would recommend working on the project to their colleagues and what the project can do to be most welcoming to newcomers in general. When you hear great ideas, implement them.

Make sure to include women speakers on the agenda of your project's conferences. Women in particular tend not to attend technical conferences if they feel like they are the only woman present. The closer you can come to gender parity on your conference program, the more women you'll attract to your conference. And I think we all know the importance of connecting in person to making FOSS happen.

Another way to help increase diversity in a project is to publish a diversity statement or a mission statement that explicitly states that the project is open to all and encourages participation from as many different kinds of people as possible. It may be obvious to all the project members that you are open to anyone's participation, but actually reading that a project is looking for people from all walks of life makes people feel welcomed and valued. Specifically mentioning that you are looking for newbies is a great way to attract a more diverse community if most of your contributors eat, sleep and breathe your project. More perspectives help a project grow and thrive.

Please note that I am going to make a whole bunch of generalizations here, and these are just my opinions.

I think things are getting a whole lot better. The conversation is taking a more positive tone - we're not just focusing on the problems anymore, we're giving people concrete advice on how to make things better. A lot of my colleagues have been focusing on providing positive role models for other women to participate and talking about all the reasons why we enjoy contributing to FOSS, all of which helps more women get involved. I've also seen much more discussion about the role that FOSS plays in making the world a better place, which definitely appeals to women; women tend to want to know that their work makes a wider impact rather than just wanting to scratch their own itch.

I think the growth of women in FOSS will really take off in the next few years since more women are stepping up and being vocal about their contributions to the community and their passion for their work. Sharing one's enthusiasm and joy make FOSS that much more attractive to all new contributors, not just women.

I think there are many factors involved. Women tend to be socialized away from technical endeavors, women tend to get their first computer much later than men do, women tend to have fewer technical role models than men do, etc. I think there's definitely a cultural aspect, too; studies have shown that women are less likely to get involved in competitive scenarios and to underrate their skills when in competitive scenarios. The very nature of FOSS is pretty competitive - one solution vies with another for primacy, one often has to be more vocal to get one's opinions heard - and women may be less likely to be comfortable in those situations. I'm not suggesting FOSS development practices should change overall, but easing all new contributors into your community processes will yield better long term results since more people will feel invested in the project if they have a positive initial experience. Save the harshest critiques of patches or the RTFM responses for those who are a bit more advanced in FOSS and I think we'll see many more people stick around and continue contributing, especially women.

Honestly, I just felt like it was time for a change. I loved my role at Google and I love working with the FOSS community, but I wanted to do something different. Consulting allows me to get a wider range of experience in business and I'm looking forward to expanding my skill set.

Heh. I've been idly talking about creating an intentional community for years now and hackers are just my kind of people. I love Costa Rica and the company that I'll be working with in the near term has offices in the Valley and Costa Rica. I'm looking forward to investigating the viability of a "Costa Rican hacker colony" while consulting. Specifically I'll be working on marketing and business development, and consulting gives me plenty of time to continue pursuing my passion for FOSS.

I'm delighted to say that I am seeing the community taking a more expansive role of the ideas of contribution and contributor. Once upon a time, if you couldn't write code you simply weren't needed. I'm now seeing that attitude change and more individuals and projects explicitly state that any and all contributions are to be valued, be they coding, documentation, running a booth at a conference or organizing user group meetings. All of these require different talents and all of these efforts make a project better. The more inclusive we all are at recognizing contributions, the more contributors we'll find donating their time and expertise to FOSS.