September 20, 2009, 7:56 PM — Some software developers wrinkle their nose at the very idea of deliberate one-on-one help. The default behavior in many (most? it's hard to know) free and open source software (FOSS) communities is to read the code and documentation, try it out, rinse and repeat. People improve their skills on their own; if they need help, they post a note in a forum or ask in IRC. Why should it be otherwise?
However, we all learn differently. You might want to settle in with a programming book, while I prefer to take an in-person class. If your project wants to attract new contributors, it behooves you to think past the "dive into the deep end" culture.
"Many people want to participate, but are literally sitting there just waiting to be asked," says Mel Chua, a new community engineer on Red Hat's Community Architecture team and frequent contributor to the Sugar Labs and One Laptop Per Child projects. "No amount of general ‘Just jump in, please join us!' shouting will work if the potential contributors you're trying to reach don't think that any such invitation could possibly be directed towards them. If you want new contributors, you need to go out and find people and ask them, individually, for their help," she says.
Many open source communities do actual mentoring (even if they don't think of it with that label); others don't. Some projects make a concerted effort to connect newbies with more experienced people. They provide opportunities for people to work together in smaller teams (not just a gang hanging out in an IRC channel, however useful that is), such as in sprints and code-a-thons. The best known effort is undeniably the Google Summer of Code (GSOC), but plenty of mentoring happens on a smaller scale.
I asked people from several open source communities to share their mentoring experiences. In this article you'll learn what works, what doesn't, and how to encourage these relationships.
In talking here about mentoring, I make a distinction between "learn on your own" (such as examining the changes others make to the code you contributed) and somebody offering specific, individual advice (e.g. "It might run faster if you did this..."), particularly in an ongoing personal relationship. For more on mentoring in general, see my older article, The Executive Woman's Guide to Mentoring.
Just like any family, company or community, open source communities have their own way of doing things, says Grant Ingersoll, a member of the technical staff at Lucid Imagination, the commercial entity to Apache Lucene and Apache Solr enterprise search technologies. "If the project is going to be sustainable, you have to be welcoming of new members." And it's important outside the community, too; sometimes mentoring involves helping companies who are hesitant to adopt open source feel more comfortable, Ingersoll says.
Nor does the effort help your project attract only the raw, wet-behind-the-ears new programmers. It builds loyalty and commitment. For the last ten years, Chris Cormack currently the translation manager for the Koha Open Source Integrated Library System, has acted in a mentor capacity to several people. "I think almost all the people I have spent time with are still active in the community," he says. "Or [they] made a positive contribution to the community/project before they went on to other things."
Creating Mentoring Relationships
It's unlikely that you could be involved in the open source community and remain unaware of Google's yearly sponsorship of open source projects. "Since its inception in 2005, [Google Summer of Code] has brought together nearly 2,500 successful student participants and 2,500 mentors from 98 countries worldwide, all for the love of code," summarizes its website. The company has collected plenty of hard-earned wisdom, and I'll impart some of the lessons learned by Google's Leslie Hawthorn when we get to the specific advice section. (Really, it's coming.)
However, Google is not the only company to contribute in this way. The Ubuntu community, for instance, uses mentoring extensively. Explains Jono Bacon, Ubuntu community manager, people who want to become Ubuntu developers engage in a sponsorship process. The developer contributes a package, which existing developers review; the experienced developers offer comments until the prospective developer is ready to directly contribute to Ubuntu. "We have also run extensive mentoring campaigns in other parts of the community, helping teams to mentor other teams, mentoring at a governance level and more," says Bacon.
Deliberate mentoring is not limited to the "household name" FOSS projects. Abizer Rasheed, president of Effortless 24x7 and sponsor of SimWitty (which I also referenced in my article about sponsoring open source sprints) conceived of SimWitty's mentorship model as a three-way partnership. A sponsor provides high-level guidance, an advisor does the day-to-day mentoring, and then there's the intern or mentee. "Our pilot has my firm being the sponsor, J. Wolfgang Goerlich (a local seasoned security expert) mentoring, and a college student from Detroit interning. We plan to scale the model up with additional sponsors, advisors, and interns," he explains.
While it's ideal to have someone else create the connections, however, it isn't at all required.
