Mentoring: Your path to immortality

Have you ever wondered why some open source projects have better luck than others when it comes to attracting and retaining enthusiastic contributors? Here are a few ways open source projects can improve their chances of getting—and keeping—the kinds of contributors who help make projects succeed.

1. Give (social) permission

Go out of your way to give people permission to participate. Sure, you might think that because your project is open source, people already have permission. But the fact is that most new contributors don't know that have permission. In fact, they might think they lack the expertise, experience, or status to contribute.

And it's this last one—the status—that stops many contributors before they even get started. Surely you have to be an important, hot-shot big name to contribute a change to an important open source project, right? I can't tell you how many times I've encouraged someone to contribute a patch, and they've responded, "I'm not one of the developers on that project."

You must go out of your way to give permission. Tell people, explicitly, that they are allowed to fix things, change things, break things, redesign things. Tell them that there's no "me" and "them;" rather they are part of the project because they choose to be part of the project.

2. Give (technical) permission

Give permission on the technical level, too. Most software projects have a concept of a "commit bit" that is given to people who have somehow earned the right to change things. And most projects are extremely stingy with this.

Instead, I say, hand out commit rights like candy. This is, after all, why you have revision control—not only so you know exactly who changed what, when, and why, but also so you can revert bad changes.

So, be generous with commit rights. And when someone breaks something, roll it back, and then gently and kindly guide them to a better solution. Not in the manner of some projects that publicly humiliate people who send in bad patches, but in the manner of a parent guiding their child from a mistake into the right way of doing something.

3. Ask

Take the next step. Don't just tell people that they are allowed to contribute, but ask them to perform certain tasks. Be specific, even to the point of step-by-step instructions.

Many software developers will rightfully say that this takes a lot longer than just doing it themselves. But when you mentor someone, you're investing in the future. You're ensuring that when you decide to move on to something else, you're leaving the project in competent hands—hands that you have trained to do things in a way that you approve of.

4. Avoid simply cloning yourself

When you actively mentor, you are ensuring that you will still be active on your project, in a certain sense, long after you've moved on to other things. You'll leave your influence behind and amplify your own effort across multiple other people.

In a sense, you'll be leaving clones to continue your work.

But be sure that you're not just selecting copies of yourself, rather that you're expanding the ecosystem. You're not replacing yourself, you're amplifying yourself. Be sure to amplify yourself in harmony, with many tones, volumes, beats, and countermelodies. Monotones are boring.

Conclusion

I'll be presenting about the importance of mentoring at the Open Source Summit on September 11 in Los Angeles. Although the presentation is geared toward people who are active on open source projects, the principles I'll be discussing are relevant for any endeavor, especially those that rely (in any way) on volunteer effort.

In this article, I've touched on a few highlights to whet your appetite to come and see my presentation. I hope you'll be there, but if not, I plan to post the entire presentation on my YouTube channel after the conference.

For the rest of the story, don't miss Rich's talk, "Mentoring: Your path to immortality," at Open Source Summit, September 11-14 in Los Angeles.