Open source · Mentorship · Maintainers
How to run an open source mentorship program on your own
How to run a small open source mentorship program on your own, outside Google Summer of Code, Outreachy, and LFX: how much time it takes, how to scope it, what to write down, and how to end it.
Most maintainers who want to mentor someone look first at Google Summer of Code, Outreachy, or LFX Mentorship. They're good programs. They also run on their own calendars, decide who gets in, and want an organization behind the project. If the timing is wrong or your project doesn't qualify, you can run a small open source mentorship program yourself. This post is about how to do that in the time you actually have.
Why keep it small and bounded
Maintainers are stretched, and fewer people are coming up behind them. Tidelift's 2024 maintainer survey found that maintainers under 26 had fallen from 25% of respondents in 2021 to 10%. Read Tidelift's maintainer survey summary.
Meanwhile the open front door is getting noisier. curl ended its bug bounty in January 2026 after the share of valid reports fell below 5% while the volume kept rising. An open queue spends your review time on whoever shows up. A small program spends it on a few people you chose, for a set period, with an end date. Read Daniel Stenberg on ending the curl bug bounty.
What the big programs give you
| Aspect | Google Summer of Code | Outreachy | LFX Mentorship |
|---|---|---|---|
| When it runs | Once a year; organizations apply in January and February | Two cohorts a year, May to August and December to March | Three terms a year: spring, summer, and fall |
| Length | Projects of about 90, 175, or 350 hours | 13 weeks at 30 hours a week | 12 weeks full time or 24 weeks part time |
| Contributor stipend | Paid by Google; $1,500 to $6,000 before regional adjustment | $7,000 | Based on $6,000, adjusted by region |
| Who can join | Students and open-source beginners, 18 or older | People who face underrepresentation or discrimination in tech | Open applications, selected by each project |
| What your project needs | Acceptance as a mentoring organization | Community funding for each intern | Linux Foundation review and an OpenSSF Best Practices badge |
If you qualify and the timing works, use them. The stipend matters for contributors who can't afford to volunteer. Spots are limited, though. Outreachy said in 2025 that funding cuts had shrunk its cohorts by 60%, from an average of 65 interns to 25. Read Outreachy's call for mentoring organizations.
How much time a mentorship program takes
Decide how much review time you have before you decide anything else. Outreachy asks mentors for 5 to 10 hours a week while applicants make their first contributions, and about 5 hours a week during the internship. That's a fair benchmark for one contributor. For a first program, plan on one to three people, each with a named reviewer. I'd rather finish a small program than stall a big one. Read Outreachy's mentor expectations.
Scope one outcome with an end date
Pick one outcome your project needs, break it into a few ordered milestones, and set an end date. Each milestone should name the work and say what done looks like. I wrote a separate guide on turning backlog issues into milestones: Turn your backlog into a contributor program.
Write the rules down before anyone joins
- Hours a week you expect, and what to do when that changes.
- How fast a reviewer responds, and how long a pull request can sit waiting for changes.
- What done means for each milestone.
- Your AI policy: what's allowed, what must be disclosed, who answers review comments.
- Whether the work is paid, and if so, who arranges it.
- How the program ends and what the contributor gets at the end.
A contributor knows what they're agreeing to, and you have something to point back to when things drift. The review norms have their own guide: Set clear code review expectations with contributors.
Choose who joins
You can let people ask to join or invite people you already know. Either way, a small real task tells you more than a cover letter. Ask applicants to read the project, set it up, and comment on one issue.
Then clear the path. Research by Igor Steinmacher and colleagues groups newcomer barriers into five areas: social interaction, finding a way to start, documentation, technical hurdles in the code, and gaps in what newcomers already know. Check your setup instructions, your first issue, and your chat channel against that list before anyone arrives. Read the research on newcomer barriers.
Run it
Agree on a check-in rhythm in the first week and keep it. Review quickly: the Open Source Guides cite a Mozilla finding that contributors whose code was reviewed within 48 hours were much more likely to come back. Keep public review about the code, and take coaching about habits or confidence somewhere private. Read the Open Source Guide on building community.
Decide ahead of time what happens when a contributor goes quiet. One check-in, then a clear point where the milestone goes back to the pool. Expect it to happen at least once.
End it on the date you set
Close the program when you said you would. Write each contributor a short record of what they did, what feedback they got, and how they responded. It's worth more to them than a thank-you.
The CHAOSS Mentorship metric suggests tracking how many mentees keep contributing compared with your community's usual retention, and how many go on to larger roles. Keep expectations realistic. Research on Google Summer of Code found most students join for the experience, not to stay for good. A program can still be worth running if nobody becomes a maintainer. Read the CHAOSS mentorship metric.
Tools
A first program can run on what you already have: a pinned issue with the rules, a label per milestone, and a GitHub project board. If you'd rather have it in one place, Devprentice is built for this kind of program. It holds the repository, milestones, acceptance criteria, reviewer, capacity, and AI policy, lets people ask to join, and ends with a Contribution Record. The work stays on GitHub under your project's rules, and it's free for public repositories. See how Devprentice works for maintainers.