Designing an Open Mentorship Program¶

After some consideration, you've decided to create a new open mentorship program or initiative but you don't know where to start. Don't worry! In this chapter, we'll guide you through the most important design decisions for an open mentorship program.

Mission and vision¶

Before you start thinking about the overall structure of your program, you need to write mission and vision statements for your program. This exercise an important first step in creating a new initiative — those statements will guide other important design decisions because they're connected to the very essence of the problems that provoked you to create a new program. A mission statement should be a reflection of your current program prospects — what it does, its goals and how it will achieve them. For example, here's the mission statement for Outreachy:

Our mission is to inspire, support, and promote new generations of marginalized and underrepresented contributors, activists, and leaders in the free and open source ecosystem through mentoring opportunities.

A vision statement is all about your dreams and aspirations — what do you envision to happen if your program is successful in achieving its mission? Outreachy's vision statement is as follows:

Our vision is a world where every person can find their place in the free and open source ecosystem.

Target groups¶

If your mission statement is similar to Outreachy's, it may already include a couple of words about who is the target group of your program. We recommend that you expand that definition. You can do so by envisioning what kind of person will participate as a mentee or as a mentor through personas¹. Personas are models of your target groups based on real-world observations and insights. That information may be gathered through informal conversations, feedback collection, interviews or research. Each persona should have a short biography including details such as their demographics, goals, frustrations, motivations, behaviors, etc. Here's a sample of an Outreachy persona for a potential mentee:

Deborah is a 20-year old woman from Nigeria. She's almost done with her undergraduate studies in Computer Science. She's the only woman in her class, and she's often begrudgingly assigned to documentation duties in group projects because her classmates don't take her seriously. When attending OSCAFest last year for the first time, Deborah heard from a lot of speakers and attendees that contributing to open source projects can help her build her portfolio. She's used WSL on her computer, but she's never contributed to an OSS project. Deborah learned C++ and Python in university courses. She feels confident in her programming skills and has created a couple of small projects outside her classes, but she wasn't given a chance to code in larger scale projects yet.

And here's a sample of an Outreachy persona for a potential mentor:

André is a 45-year old man from Brazil. He's part of one of Debian's core teams. Last year, he suffered an accident that forced him to take a 3-month sick leave. This event encouraged André to reflect about his life and his privileges. He asked himself, what can I personally do to fix this broken world? He realized he would like to use his privilege to help those who aren't as privileged as him. André had some experience with teaching and mentoring in university, but he hasn't mentored someone in a couple of years.

This exercise will help you understand who you and your program will serve and what needs and aspirations each person may have when your paths meet. Remember, however, that your target groups aren't set in stone — you can revisit this definition and change your perspective on who to serve at all times. For example, Outreachy started as a program to encourage women to work under GNOME's projects. Our target groups expanded as our understanding of underrepresentation and systemic bias widened. We expect you to revisit personas somewhat often as your understanding of the problem you want to address will improve with time.

Model and format¶

Program type¶

What kind of program do you want to run? Different models serve different purposes, suit different communities, and ask different things of the people running them.

Short-term internships are the most common model in open source mentorship. Outreachy and GSoC both run three-month cohorts, twice a year. The timeline is long enough to produce substantial contributions and short enough to be manageable for volunteer mentors. Interns are paid a stipend, which makes participation possible for people who can't afford to volunteer. The structure is well-defined:

• Application period
• Contribution period
• Internship
• Evaluation

For communities that want to bring in contributors from underrepresented groups and need a proven framework to do it, this model has the longest track record.

Fellowships are longer and typically more open-ended — from six months to a year — often with a broader scope that includes community building, research, or leadership development alongside technical work. They suit programs where the goal is to develop future maintainers or community leaders rather than produce a specific deliverable. They require more sustained investment from mentors and more careful scoping at the start, but they can produce contributors who are more deeply embedded in the community by the end.

Peer mentoring pairs contributors at similar experience levels to learn from each other. It works well inside communities that want to build connection and knowledge-sharing across the contributor base, and it's lower-stakes than hierarchical models. Both people are learning, which tends to make honesty easier. The limitation is that neither person may have the depth to see what the other is missing. Peer mentoring works best as a complement to other structures, not as a standalone program for bringing in people new to the community.

Rolling or cohort-based programs admit participants in groups rather than individually, building community among participants from the start. Outreachy uses this approach too. Interns from different projects go through the program at the same time, with shared channels, community calls, and social events that connect them to each other as well as to their individual mentors. The cohort itself becomes part of the experience, and alumni of the same cohort often stay connected long after the program ends.

Most programs don't have to choose just one. Git's model layers hierarchical mentorship — involving one or two experienced mentors per intern — inside the broader Outreachy cohort structure, connecting individual guidance with community belonging. The combination works because both layers are intentional.

Mentoring type¶

What kind of open mentorships you want to facilitate with your program? To help you decide, let's revisit the taxonomy of open mentorships:

Open mentorship programs often have a specific vision for the mentorships they offer: one that follows a specific format (rigid), may be formalized through agreements under an organization (formal) and is transient (lasting weeks or months) rather than sustained (lasting years). A format for open mentorships defines what mentee and mentor journeys may look like, such as following a specific schedule, e.g. a 3-month mentorship period that starts and ends in dates defined by program organizers or submitting progress reports through a specific channel (e.g. forms, emails, messages, meetings) to program organizers for mentee and mentor evaluation. We advise you to deliberate about:

• Mentorship duration and period
• Responsibilities of mentees and mentors
• Expected mentorship outcome (e.g. producing specific artifacts, creating or successfully incubating a project, hitting milestones)
• Payment conditions and structure, if providing any financial support

We recommend deliberating about formalization methods (e.g. agreements, contracts) if you're considering providing any kind of financial support to mentees, mentors or collectives. Seek legal advice to include the items listed above and other important legal provisions in the agreements you create.

It's also up to you to decide whether you will allow collectives, projects or mentors to define if they will do one-to-one, many-to-many, or many-to-one mentoring. Outreachy allows mentoring communities to define how many mentors will work under each project, but we encourage co-mentoring and require them to work under one-to-one arrangements at minimum.

Mentee-mentor matchmaking types¶

Matching is one of the most consequential decisions a program makes. A poor match produces a mediocre experience and a contribution period filled with friction that leaves both people less likely to stay involved in mentorship afterward. There are three main approaches, and the best programs combine all three.

1. Interest-based matching pairs people around shared enthusiasm for a project or problem. It's the most natural starting point in open source, where contributors choose projects they care about. The strength is motivation. People work harder on things they find genuinely interesting. The limitation is that shared interest doesn't guarantee a working relationship. Two people can both love the same project and still communicate completely differently, work at different paces, or have expectations that don't line up.
2. Skills-based matching pairs a mentee's current abilities with a project's requirements and a mentor's expertise. This is the approach Git uses in its application process. The micro-project tests whether the applicant can actually do the work the internship requires before anyone commits to the full three months. Skills-based matching reduces the risk of a mismatch that only becomes apparent halfway through. It also helps mentors calibrate their guidance from day one rather than spending the first weeks figuring out where the mentee actually is.
3. Community-fit matching considers how the mentee and mentor will work together as people — their communication styles, time zones, working hours, feedback preferences, and cultural backgrounds. This is the dimension most programs skip, and the one that causes the most interpersonal problems. A mentee who prefers written, asynchronous feedback paired with a mentor who likes to think through problems verbally in real-time calls will struggle — not because either of them is wrong, but because nobody asked the question before the pairing was made.

Outreachy recommends that mentors respond to applicant questions within four hours during the application period and notes that if interns don't hear back within that window, self-doubt kicks in and they often start looking at other projects. Response time is a matching variable. If a mentor can't commit to that kind of availability, the program needs to know before the match is made.

One more thing worth saying about matchmaking: it will sometimes go wrong despite your best efforts. Have a process for what happens when it does. A clear, simple way for either party to flag that the relationship isn't working is a sign of a program that takes its participants seriously.

Finances and funding¶

Creating a financial structure for a program is complex and depends on specific program needs. While we can't provide a detailed script for this task, we do recommend thinking about the following questions:

• Will you or any of the program organizers be paid for their work organizing the program as a part of their current job or under a separate contract? Several programs have started with volunteer staff and then reached a state where they could compensate their organizing team after finding steady funding. On the other hand, their capacity to volunteer may decrease with time.
• Will you provide financial support to mentees, mentors or collectives? What kind of financial support would you like to provide? Will you pay every person the same amount, or will it be a dynamic amount based on aspects such as their geographical location or disclosed needs? Do they have to hit specific milestones or submit specific documents or artifacts to have their payments approved? Note that the complexity of the financial support arrangement should accompany the capacity of your organization to make payments. Dynamic amounts may require more attention and energy.
• What would you do if your program had the financial support of sponsors or grantmakers? In what areas would you invest? What would you expand or create?

Note that making payments to residents or citizens of some countries may be more difficult than you realize. Some banks may refuse to initiate specific transactions due to risk management measures. We ask you to be insistent and fight for those mentees or mentors, even if it means looking for another financial institution for you banking.

We recommend creating a diverse funding structure for your program — that is, you should have multiple streams of funding to sustain it. Additionally, as a general rule, you should take advantage of periods of more successful fundraising to build reserves for periods of financial difficulty. We've had success building relationships with individual donors, corporate sponsors and grantmakers. We should warn you, however, that as of 2026, it may be more difficult to find funding for program activities in certain funding ecosystems.

Admissions and applications¶

What will be the entry points of your open mentorship program for mentees, mentors and any other supporting roles such as coordinators, experts and facilitators? Formal admissions may involve receiving applications from mentees and mentors individually or under a collective. What those applications may ask or entail depends on factors such as legal requirements, evaluation criteria and program mission. What would you ask to the ideal people to join your program that would help you identify them as such? Are there any tasks or activities that could help you evaluate if they're a good fit? Informal admissions can be used if you want to restrict access to the program to a trusted circle or if you don't have the reach to gather a larger application pool, but may know folks who would be good candidates for a pilot cohort.

You can adopt a single-step or a multi-step application process. We generally recommend single-step applications for programs expected a small application pool (i.e. a few hundred applications) and multi-step applications for programs handling a larger application pool (i.e. thousands of applications). Know, however, that the more steps you add to an application process, the longer and more strenuous it may be for every person involved in reviewing, approving or rejecting those applications.

Embedding inclusivity¶

Inclusivity in a mentorship program is a set of decisions made throughout the design process that determine who can actually participate — not just who is theoretically eligible.

Design for the person who will find participation hardest. That means stipends large enough to offset the opportunity cost of participating. It means flexible timelines that accommodate different academic calendars, family responsibilities, and time zones. It means contribution processes that work asynchronously so a mentee in Lagos and a mentor in Berlin can collaborate effectively. It means documentation clear enough that someone unfamiliar with the project's cultural norms can find their footing without a network of insiders to lean on.

Accept contributions beyond code. Outreachy has included documentation, design, and translation internships since its early years. It was a recognition that the work of maintaining open source is broader than any single skill set and that limiting mentorship to code contribution limits who can participate in ways that compound existing inequities. A program that accepts only code contributions will attract a narrower pool of applicants. That narrowness will be reflected in who becomes a contributor and eventually in who becomes a maintainer.

Include the people the program is meant to serve in its design. A program designed to support contributors from underrepresented groups, built entirely by people from well-represented groups, will reflect the assumptions and blind spots of its designers. Bring in people with direct experience of the barriers the program is trying to address — as advisors, as co-designers, as beta testers of the application process. Their input will surface problems that would otherwise only become visible after the first cohort has already had to navigate them.

Design for multiple learning styles and cultural contexts. Not everyone learns best by reading documentation and asking questions on a public mailing list. Some people learn by doing and need a lower-stakes space to make mistakes before going public. Some come from cultural backgrounds where asking questions of a senior person directly feels presumptuous and need explicit permission and encouragement to do so. A program that assumes everyone navigates learning and authority the same way will serve some participants much better than others.

Evaluation and measurement¶

We recommend establishing an evaluation and measurement process for your program from the very start and keeping records of every alum and their program outcomes. You can establish an evaluation process to occur as mentees go through their mentorships — a more immediate feedback collection — and conduct a wider study of alum's perceptions of the program and their medium to long-term outcomes every couple of years. We advise you to track metrics such as program satisfaction, the status of mentor and mentee relationships, mentee progress, and how often an alum is interested or becomes a mentor themselves.

The evaluation of a mentee — and whether their program outcome should be considered successful — is something that can be a shared responsibility between mentors and program organizers or the sole responsibility of mentors or organizers. And you should determine, at minimum, whether a failed evaluation puts an end to their mentorship experience or if mentors and organizers can propose and execute interventions to help them get back on track. This decision depends on how involved you want to be in mentorship decisions after matchmaking and the scale of your mentee and mentor cohorts.

Support¶

Defining channels and means of support requires awareness of what level of involvement you want and you can provide to each mentee and mentor pair. Some programs have a role of a mentoring coordinator — someone who follows specific groups of mentorship relationships closely, mediate lower complexity issues (e.g. mild communication issues) and escalate medium to higher complexity issues (e.g. mentor on a sick leave, absent mentee) to program organizers. Some program organizers may choose to support mentees and mentors more closely through social activities and one-to-one support calls and channels. The scale and the complexity of mentee-mentor relationships under your program may prevent you from following each and every mentorship closely. Model communication and support strategies according to your capacity to sustain them.

Safeguarding¶

Open mentorships often come with some power imbalance: the mentor knows more about the community and the project. They often have a say in whether a mentee's work is accepted, whether they receive positive references, and whether their project is considered successful.

That doesn't make open mentorships inherently problematic. It makes mentorship political, as those with less power are more exposed to stakes and interests. Good mentors are aware of this and actively strive to counteract it. They don't use access and information as leverage, consciously or otherwise.

Open mentorship carries a specific risk that often goes unmentioned: the assumption of availability. Mentors in FOSS programs are almost always volunteers fitting mentorship around existing jobs and responsibilities. Mentees, especially those receiving a stipend, may feel implicitly obligated to make themselves available whenever the mentor is. That asymmetry of time, financial dependence, and social standing needs to be managed.

Programs carry responsibility here too. A program that pairs an inexperienced mentee with a mentor who has never been given any guidance on how to handle conflict, give feedback, or recognize when a mentee is struggling is not just failing its mentees. It's also failing its mentors and setting up both for an experience that could have been good but wasn't.

The ethical baseline for open mentorship is straightforward, even if it isn't always simple: mentor's and mentee's wellbeing come first. Not the project's output. Not the program's metrics. When those things come into tension — and they do — programs and mentors need to know which way to lean.

We recommend familiarizing yourself with the practice of safeguarding and embedding it in every design choice — especially if you're designing a program serving marginalized and vulnerable populations. Safeguarding is about preventing and reducing harm to all parts involved with our work. UNICEF's safeguarding policy and safeguarding implementation guidelines are great places to start learning about it.

In the next chapter¶

• How to support your program's mentees!