|
| 1 | +--- |
| 2 | +title: "Three Years with Google Summer of Code: What I've Learned" |
| 3 | +slug: three-years-with-google-summer-of-code-what-ive-learned |
| 4 | +date: 2025-11-02 |
| 5 | +authors: ["Ivan Ogasawara"] |
| 6 | +tags: [open-source, gsoc, mentoring] |
| 7 | +categories: [gsoc] |
| 8 | +description: | |
| 9 | + Three years in GSoC taught us one thing: mentoring matters more than code. |
| 10 | + As a 2025 mentoring org (with AlphaOneLabs, Extralit, Makim, Sugar), our |
| 11 | + playbook is simple—balance mentors, set explicit contribution rules, meet |
| 12 | + regularly; and for contributors: communicate publicly and ship small, |
| 13 | + tested PRs. |
| 14 | +thumbnail: "/header.png" |
| 15 | +template: "blog-post.html" |
| 16 | +--- |
| 17 | + |
| 18 | +# Three Years with Google Summer of Code: What I've Learned |
| 19 | + |
| 20 | +Mentoring is at the heart of Open Science Labs (OSL). It's why we joined Google |
| 21 | +Summer of Code (GSoC) in the first place. We started as a sub-organization under |
| 22 | +the NumFOCUS umbrella for two years, and in 2025 we were accepted as a |
| 23 | +**Mentoring Organization**. Huge thanks to **Anavelyz Pérez** for keeping us on |
| 24 | +track. We’re pleased to have secured four contributor slots for 2025 with |
| 25 | +**AlphaOneLabs**, **Extralit**, **Makim**, and **Sugar**. |
| 26 | + |
| 27 | +We're incredibly proud of the contributors and mentors who made GSoC 2025 a |
| 28 | +success. We were also, honestly, a bit heartbroken—many strong applicants did |
| 29 | +real work and still didn't get in. On a personal note, attending the **GSoC |
| 30 | +Summit** was a highlight: I met inspiring people and learned a lot from their |
| 31 | +experiences. |
| 32 | + |
| 33 | +Below are the lessons that stood out across these three years and practical |
| 34 | +recommendations for organizers, mentors, and contributors. |
| 35 | + |
| 36 | +--- |
| 37 | + |
| 38 | +## The Big Lesson |
| 39 | + |
| 40 | +**GSoC isn't just about code—it's about mentoring.** Code is the artifact; |
| 41 | +mentoring is the engine. The best summers happen when we design for learning, |
| 42 | +clarity, and care. Everything else follows. |
| 43 | + |
| 44 | +--- |
| 45 | + |
| 46 | +## Recommendations for Organizers |
| 47 | + |
| 48 | +- **Confirm your slot count early.** The number of slots you _realistically_ |
| 49 | + expect should shape how many projects you onboard and how you scope them. |
| 50 | + |
| 51 | +- **Balance mentors as well as projects.** When allocating slots, distribute |
| 52 | + contributors across both projects _and_ mentors. Avoid situations where one |
| 53 | + mentor has two contributors while another has none—burnout and uneven support |
| 54 | + help no one. |
| 55 | + |
| 56 | +--- |
| 57 | + |
| 58 | +## Recommendations for Mentors |
| 59 | + |
| 60 | +- **Limit the number of projects per mentor.** The pre-selection phase is |
| 61 | + intense. If you're stretched across multiple proposals, candidates won't get |
| 62 | + the guidance they deserve. One well-mentored project beats three |
| 63 | + under-mentored ones. |
| 64 | + |
| 65 | +- **Codify contribution rules up front.** Document expectations clearly and link |
| 66 | + them everywhere: |
| 67 | + |
| 68 | + - Max PR size (e.g., “prefer ≤300 lines; split larger changes”). |
| 69 | + - Stale PR policy (e.g., “no updates for 10 days → close or draft”). |
| 70 | + - Code style, linting, and formatting rules. |
| 71 | + - Clear stance on AI-generated code (allowed or not, and under what |
| 72 | + conditions). |
| 73 | + |
| 74 | +- **Keep your CONTRIBUTING.md and PR template current.** Treat them as living |
| 75 | + documents. If you change the rules mid-summer, call it out in a pinned |
| 76 | + message. |
| 77 | + |
| 78 | +- **Equip contributors to grow.** Share starter issues, architecture diagrams, |
| 79 | + walkthrough videos, and links to docs or talks. Provide “good first PR” |
| 80 | + examples. |
| 81 | + |
| 82 | +- **Meet regularly.** Short weekly 1:1s or cohort calls work wonders. Use |
| 83 | + agendas. End with explicit next steps. |
| 84 | + |
| 85 | +- **Nurture community, not competition.** Encourage contributors to help each |
| 86 | + other, co-review PRs, and pair on debugging. A supportive, respectful culture |
| 87 | + is non-negotiable. |
| 88 | + |
| 89 | +- **Have a Plan B for great applicants who aren't selected.** If you have |
| 90 | + bandwidth, offer an internship track, micro-grants, or |
| 91 | + “fellows-without-funding” with mentorship and recognition. It keeps momentum |
| 92 | + and grows your contributor base. |
| 93 | + |
| 94 | +--- |
| 95 | + |
| 96 | +## Recommendations for Contributors |
| 97 | + |
| 98 | +- **Default to public communication.** Ask questions in the project's public |
| 99 | + channels. It helps others learn and shows the team how you collaborate. |
| 100 | + |
| 101 | +- **If a mentor is unresponsive, switch projects.** They're likely overloaded; |
| 102 | + repeated pings won't help. Find a project with responsive maintainers and |
| 103 | + bandwidth for new contributors. |
| 104 | + |
| 105 | +- **Avoid giant PRs.** Huge changes are hard to review and often get stuck. Ship |
| 106 | + small, focused PRs that follow the project's style and tests. |
| 107 | + |
| 108 | +- **Show you understand the project's culture.** Read the docs. Match coding |
| 109 | + style. Follow the templates. Keep commits scoped and messages clear. |
| 110 | + |
| 111 | +- **Be careful with AI-generated code.** Don't paste blindly. Understand the |
| 112 | + problem, explain your choices, remove unnecessary comments, and **never** |
| 113 | + include emojis in code comments. |
| 114 | + |
| 115 | +- **Discuss big changes before you implement them.** Don't refactor core |
| 116 | + components or alter architecture without buy-in. Open an issue, propose a |
| 117 | + design, gather feedback. |
| 118 | + |
| 119 | +- **Ship tests and pass CI.** If you fix a bug or add a feature, include tests. |
| 120 | + Make sure CI is green before asking for review. |
| 121 | + |
| 122 | +- **Submit up to three proposals to multiple orgs.** Each org has limited slots, |
| 123 | + so contributing and applying across organizations can improve your chances—but |
| 124 | + focus on quality! Note: only one proposal can be accepted per contributor. |
| 125 | + ([developers.google.com][can_i_submit_more_than_one_proposal]) |
| 126 | + |
| 127 | +* **Write a crisp proposal.** Be clear, specific, and concise (≤10 pages). |
| 128 | + Demonstrate understanding of the project and outline concrete steps, |
| 129 | + milestones, and risks. Ask maintainers for early feedback so you have time to |
| 130 | + refine. |
| 131 | + |
| 132 | +--- |
| 133 | + |
| 134 | +## Looking Ahead |
| 135 | + |
| 136 | +I'm excited to keep participating in GSoC in the coming years and to keep |
| 137 | +welcoming new contributors into open-source communities. Thank you to the GSoC |
| 138 | +team for running this program year after year—it raises the visibility of |
| 139 | +projects, gives newcomers a safe place to learn from experts, and strengthens |
| 140 | +the open-source ecosystem. For hundreds of students and first-time contributors, |
| 141 | +GSoC isn't just a summer; it's a beginning. |
| 142 | + |
| 143 | +[can_i_submit_more_than_one_proposal]: |
| 144 | + https://developers.google.com/open-source/gsoc/faq#can_i_submit_more_than_one_proposal |
| 145 | + "Frequently Asked Questions | Google Summer of Code" |
0 commit comments