Google Summer of Code (GSoC) Mentor Summit 2025 Notes

[EwoutH]

These are my notes from the Google Summer of Code Mentor Summit in October 2025. I attended as a Mesa maintainer in my role as a mentor and primarily as an Organization Administrator for GSoC this year. The three-day summit took place in Munich, Germany.

There were about 190 other mentors from around 125 organizations, and six people from the Google Open Source team hosted and organized the event. The format was an un-conference, meaning the attendees themselves plan the sessions, and people can attend whatever they like. The event is essentially hosted by the community and its members. I hosted two sessions and attended a few others.

I jotted down some notes during the sessions, and recorded myself while discussing them in the train back. Whisper transcribed them to text and Gemini 2.5 Flash cleaned them up and formatted them. I reviewed the notes below swiftly.

Goals for Attending the Summit

Before diving into the sessions, here were my main goals for attending the GSoC Mentor Summit:

• Funding: I wanted to learn how other organizations secured funding.
• Government and Open Source: I was curious about opportunities and experiences related to government involvement in open source.
• AI in GSoC Proposals: We had a lot of proposals written with AI, which made selecting the right contributors difficult, so I wanted to discuss solutions.
• Science in Open Source: I was curious about open source software libraries specifically for scientific use.
• AI and Mentor/Mentee Roles: Even after a proposal is selected, AI changes the roles between the mentee and mentor by introducing a third party: the AI itself.

Session Summaries

I'll now discuss each of the key sessions I attended and my main takeaways.

Education and Open Source

A major takeaway from this session was the significant value of having open source experience during one's education. A quote mentioned was, "Freshly hired people with open source experience look like they're already ready to contribute. They're not freshmen, they're not juniors. They look like a hired mid-level developer."

I reflected that this is especially true if you've served as a mentor, not just a contributor. I discussed this with my co-mentor, Adam, who found that contributors are often narrowly focused on the task at hand, but as a mentor, you must look at the broader picture, which adds immense value.

This inspired me to start re-engage with my old university, TU Delft, with three potential points of interest:

1. Funding to accelerate their open source science development.
2. Integrating open source into their academic programs.
3. General engagement between open source maintainers and their users.

This might also be interested for other universities.

We discussed the issue of not receiving enough user feedback. One solution proposed was to conduct focus groups. Other ideas for engagement included:

• Putting URLs in error messages.
• Adding more "hooks" in the documentation.
• Collecting and analyzing data or models that students build to see which features are being used.
• Creating community awards.

Funding Open Source Projects

This session was hosted by an experienced open source developer. Key notes I wrote down included:

• It's beneficial to have a business-oriented person in your organization who understands that money isn't "dirty"—it's a useful tool.
• "Follow the money." Look at where your users are and which of them have the budget to spend. Companies are easy; individual users are typically harder.
• For science projects like ours, individual students are very hard to fund, while universities are somewhere in between.
• I suspect the education stream of university funding might be more reliable than the research stream. Tapping into the education stream, possibly in collaboration with other universities, could be beneficial.
• Community forums can help you find where your users are and if they are having issues. This combines with the engagement ideas from the previous session.
• Aside from incentives, you can eventually use the "stick"—like a restrictive license—if luring users in doesn't work well enough.
• Expect it to take a long time. It took three years for some companies to commit to funding.
• Grants are useful but are a one-time thing, requiring continuous time spent on applications.
• Government stipends are another great option if available.
• The best time to plant a tree was 20 years ago; the second best time is now. Start planning.
• You might be able to use a university's legal team to help set up your organizational structures, especially for government or EU funding, as it often has to go through an academic institution.
• Interesting organizations to look into include the Software Freedom Conservancy and the Apiro Foundation.
• Aggressive idea: You could put a clause in the license for publishing papers using MESA as the main method, suggesting a fee or a required donation (e.g., siphoning off 10% of a research grant).
• Open Collective and NUMfocus are existing financial entities.
• Financial Goal: Roughly €3,000 per month for MESA. €1,000/month could fund one person for one day a week. €3,000/month could fund three people for a day a week, which would make a significant difference.
• A fee per student per month with a membership structure could be useful.
• For MESA specifically, setting up a foundation or tiered membership structure where universities participate would be interesting. This tier could come with certain privileges or responsibilities like a financial donation or dedicated engineering time.
• Universities used to pay for commercial licensing, so the budget is somewhere. Open source is open, but it's not always free. Getting five or six universities to band together would be a great start.

Academia and Open Source

This session primarily covered the difficulties in getting accreditation for developing open source software in academia. It is often harder to build a career via open source software contributions than through traditional research.

Discussions covered various options for publication, funding, and how a Research Software Engineer (RSE) can build a viable career, especially for PhD students whose primary output is software.

A slightly more positive outlook was that if you write the software yourself, it is often the easiest tool to conduct your own research with.

Critical notes:

• Writing good software takes time, and the work (e.g., documentation, usability, scalability) is often not easily publishable.
• While this work is very useful and helps many users, you are essentially enabling better science for others, creating a multiplier effect that is difficult to claim as your own accomplishment multiple times over.

Ideas for improvement:

• Small papers are still papers. If you write a new module, you can publish on it.
• There are now dedicated journals for this, such as the Journal of Open Source Software (JOSS).
• You can also use Zenodo to gain a form of accreditation.

AI and GSoC

This session focused on the use of AI within GSoC itself.

• Many proposals were clearly AI-written.
• The group agreed that the critical thinking should not be outsourced to AI.
• One group successfully implemented a 10-minute, scripted interview with a few key questions for every candidate.
• The main conclusion was that GSoC should shift its primary focus from "the task" (writing a proposal, delivering code) to "the learning program."
• The goal should be to focus on the mentee's learning goals—what does the student want to learn? This gives them personal ownership.
• The mentee should align their learning goals and actively work to achieve them. They can use AI as a tool, but must ultimately be able to do the work themselves.
• Tasks not central to the mentee's learning could potentially utilize AI more heavily, as long as the work is still checked.
• This suggests GSoC itself might need to be restructured to focus less on proposals and deliverables and more on what the student has learned. The digital or physical infrastructure for submissions must be adapted to align with this, as "engage with the community and learn" is secondary to the requirement of "submit a proposal to Google."

Open Source Sustainability

This session addressed how to keep a community sustainable in the long term, even as people move on or their life phases change.

• Conclusion: People do open source because they enjoy it and get energy from it. Therefore, you need a positive, warm environment.
• The community size is a function of the number of people who join multiplied by the time they stick around. It must be easy to join and be a positive place to stay.
• Blender (the animation program) conducted a survey with the goal of getting 2% of its users to contribute in some way (financially or otherwise). This 2% target is a good benchmark.
• It varies by community: It's harder for a project like Inkscape, whose users are non-technical, but easier for a programming project whose users are already programmers. MESA is somewhere in the middle, as modelers can sometimes program out of necessity.
• A Summer School can be very effective, allowing people to take the time to learn in an informal setting.
• "Nerd Sniping" is another technique—sending interesting problems to people and seeing who responds.

Shifting Roles in the AI Era

This session provided a more extensive discussion on the changing roles between mentor and mentee in the AI era.

• We split the responsibilities between mentor and mentee and discussed where AI was involved.
• Mentor responsibilities: AI should generally not be involved, except maybe for initial review or filtering/selection tasks.
• Mentee responsibilities: AI is heavily involved, leading to the mentee adopting a "mentor role over the AI" and the human mentor taking on a role of "mentor on the mentor" (mentoring the mentee on how to manage their AI tool).
• Learning is still the goal. It's vital that students use AI to learn, especially for tasks designated as learning goals (like coding).
• Extreme Idea: Video Defense. A required video defense at the end (or 80%) of the project where students must defend their deliverable to prove they truly understood the code and the decisions/logic behind it. This ensures they internalized the work, regardless of who (or what) wrote the code. It could be an optional tool to invoke if heavy AI use is suspected.
• GSoC Central Professional Development Track: The idea of a central track of professional development topics (e.g., communication, project management, technical deep dives). Mentees could select one or more tracks based on their development goals. Organizing this centrally within GSoC would be amazing.
• High Expectations: Maintain high expectations for contributors (technically and morally) and take them seriously. Give them a high share of ownership. Discuss any concerns before judging them, and try to grow awareness of AI's potential side effects.

Open Source in Government

This was a smaller but still worthwhile session. I will jot down specific notes for this section later.

Final High-Level Notes on GSoC and MESA

Redefining the GSoC Focus

• Learning, Collaboration, and Communication are Key. The proposal should include a "What do you want to learn?" section to transfer ownership of the learning process to the mentee.
• The focus must be on it being a learning/mentor program, not a work program. The goal is not to optimize for output, but to learn as much as possible, engage with the community, and become enthusiastic about open source contribution.

Idea Specification

• Don't over-specify ideas. Leave room for contributors to explore, pick a direction, and discuss it with maintainers, allowing them to specialize and grow.
• Don't under-specify it either, as that results in a vague project that doesn't meet the organization's needs.

Contributor Retention

• Optimize for the chance of a contributor sticking with the community (or at least open source). It's okay to let a good proposal go if you have a great contributor with a slightly worse one.

Assessment in the AI Era

• In light of AI, a final reflection report or oral defense is beneficial, covering:
  • Learning Goals: What did I learn, and how did I learn it?
  • Deliverable Analysis: A retrospective of what worked well and what didn't.
  • Limitations & Future Work: A discussion of the project's limitations and potential future work (which can generate new ideas).
  • State Clarity: Ensure everyone clearly understands what the delivered code does and does not do, aiding in knowledge transfer even if the contributor leaves.
• Entry vs. Defense Interviews:
  • Entry Interview: To get to know the contributor, set mutual expectations, and make them feel welcome.
  • Defense Interview: To ensure they stand behind what they have implemented, can explain it, and have internalized it, proving they didn't just "hack it together with AI."

These tools can be used in combination or separately as needed.