Mentoring in Open Source Communities: What Works? What Doesn't?

Find out what it takes for mentoring to work in your free and open source software project.

Page 3 of 4

Mentoring is About Communication

Let's start out with a few ground rules, summarized well by Chad Outten, director of Learning Technologies at My Learning Space. He initially volunteered to document support material for the Moodle teacher certification (MTC), completed the certification himself and was asked by the program manager to mentor-assess future candidates. In his opinion, MTC's mentoring is a key factor to successful learning outcome for candidates. His overall guidelines are:

1. Establish clear expectations

2. Communicate regularly

3. Provide structure through milestones and deadlines

4. Encourage constantly

5. Model best practice

Probably the most important of those is: Communicate regularly.

Google's Summer of Code program manager, Leslie Hawthorn, likely has more experience than does anyone else in what does and doesn't work in open source mentoring. She pointed me at a few outstanding resources, including Advice for GSoC Mentors and Advice for GSoC Students, which could be applied to nearly any project. After a mentor summit at the end of October, she says, they'll put together their guide to mentoring; it'll be available first from FLOSS manuals and later in a print edition.

What doesn't work? "When both sides assume that the other will do the work to maintain the relationship," says Hawthorn. Mentors should be approachable, not only at moments of crisis or when the mentee reaches an impasse. Her advice is for participants to decide how much time should be spent trying to figure out the answer: an "n hour" or "n minute" rule. That is, "If you get stuck and can't figure it out in an hour, e-mail me." As Hawthorn explains, "You don't want to train them to be so independent that they don't ask for help when they need it."

It's not unusual for mentors to wrongly decide that "no news is good news." Good mentors take time to strengthen the social bond, she says, and engage with the mentee early. Don't assume that a mentee will come to you. Offer advice like, "I thought you might have a little trouble with...." Hawthorn explains, "You uncover places that the mentee needed help with; it opens up a dialog."

Engard's Koha experience is a good microcosm of mentoring-done-right. "In the beginning, [Chris] just taught me about the basics of using the system, how to participate in the community, what software I should install to be able to communicate best with my new colleagues/community members across the world. As time went on, he taught me how to add code to the codebase and even explained the file structure so that I could find the right files to alter. Now he's helping me learn Perl."

Mentors should recognize that newbies aren't always confident about what to ask. Engard says, "If I'd change anything it would be to ask more questions. In the beginning it can be so scary to jump into a world that has been well established. There is a culture and pecking order that isn't always obvious, and I would have hated stepping on someone's toes. Now I know that everyone wants to help, they want new members in the community and [I] understand that the community is the power that drives the software."

According to Hawthorn, successful mentors are willing to share their own failures. It gives confidence, she explains. "If the god of the codebase you're working on admits that they made the most colossal blunder, their own mistakes don't seem so traumatic or horrifying." Similarly, an effective mentor knows when to ask someone to help out; most mentors explain, "I'm responsible for you, but you can come to any of us on this list." It also demonstrates that the "expert" mentor has plenty more to learn.

This ties into something Dreamwidths' Paolucci says: "Create a project culture where trying new things -- and failing at them on the first try -- is not only culturally acceptable, but viewed as a good thing." In many open source projects, she explains, imperfect or unfinished patches are viewed as a time-wasting liability, even if it's only in the minds of the people who are doing code review. "Even if you never say something like that where anyone can see it, the attitude is still going to creep into the subtext of every interaction, and newcomers will be able to sense it," says Paolucci. To attract new contributors, she says, it's critical to "create a culture where a partway-there patch isn't viewed as ‘Great, now we're going to have to spend the time to clean that up' but as 'Great! Someone else did the first 70% of this, which is going to save me a lot of time and effort!'"

Mentoring takes time

Nearly everyone I spoke with emphasized how much time and effort it takes to properly mentor other people. It's worth it, they insist, but only if you allocate time for it, and only if the right people get involved. Helping the new people learn the ropes does make your own work take longer, Koha's Engard acknowledges. "But in the end, it means less work for you because someone new is on board to help out."

"The main problem with mentoring in a community project (one without significant paid staff) is time," says Josh Berkus, who's on the PostgreSQL core team. "Being a good mentor requires a lot of time, frequently more time than it would take you to do the development yourself. For this reason, most OSS developers are not temperamentally suited to be mentors."

Don't underestimate the time it takes to effectively mentor. "If I could reset the clock," says Novell's Brockmeier, "I'd probably structure my duties so that at least 25% of the time was set strictly to enabling new contributors." He recommends that companies with contributor-facing positions consider devoting at least 20% of their time strictly to working with new contributors -- one day a week with no other requirements. Even in a personal relationship, adds Google's Hawthorn, "Five hours a week doesn't sound like much but finding that time is difficult."

Don't expect immediate results. Says Dreamwidth's Paolucci, "It took us about four months of heavy, active development -- 100+ commits a week -- before we started seeing the payoff. You will lose people you mentor; you will spend incredible amounts of time and effort on people who don't stick around; you will lose the hack time of your primary mentor for at the very least a few months as it gets directed into reviewing, committing, and mentoring instead." She stresses: This is a long-term strategy, not a short-term one.

Don't forget to take notes! A mentor has a unique opportunity to learn a newcomer's perspective. Koha's Cormack wishes that he documented more, because "a lot of the questions are indeed FAQ ... so I do end up answering the same thing." That can lead to a more terse answer than the person asking deserves. If you take the time to write a thorough and complete answer to your mentee's question, consider also adding the answer to the project wiki; it can make it easier for the next person to learn.

The best FOSS mentoring experiences, it seems, comes from projects that devote attention to creating an easy on-ramp for new users, often including a senior project role whose job it is (formally or otherwise) to connect people. Let's take a closer look at that.

| 1 2 3 4 Page 3
ITWorld DealPost: The best in tech deals and discounts.