Every year, the Google Summer of Code (GSoC) Mentor Summit brings together open source maintainers, community leads, and mentors from across the globe.

It is an energizing unconference where the diversity of open source can be touched. This is a unique occasion to share what works (and what doesn’t) across diverse communities for mentoring new contributors, but not only.

The 2026 edition took place in Munich from October 30 evening to November 1st in the afternoon.

Even if this was the tenth mentor summit I attended (I had to count the T-Shirts), it is always amazing to feel the positive vibe there.

I attended the 2026 edition together with Michele and Eugen from the Uyuni project, representing openSUSE.

Here are a few notes of what we are taking back.

Handling intercultural differences

One standout session focused on navigating cultural differences.

A key recommendation was Erin Meyer’s book The Culture Map, which explores how different cultures decode feedback, hierarchy, and disagreement.

In practice for us:

• Explicit on boarding on feedback: instead of assuming contributors know how to receive technical critiques, projects benefit from holding a dedicated session at the start of GSoC on “How we ask for, interpret, and act on feedback.”

• Align mentors culture: a lot of the GSoC contributors are from India, and most of our mentors are from Western countries.

  Involving an Indian mentor to mentor with a western mentor usually makes a difference to bridge between the cultures.

• Draft Pull Requests: new contributors may be more at ease to work on pull requests which are flagged as draft.

  This usually helps with the feedback loop on the code.

• Show that mentors need help too: showing the new contributors that even mentors need to handle comments in pull requests and ask questions helps them feel more at ease.

AI-related sessions

Many of the sessions where about AI and the impact it has on Google Summer of Code and open source in general.

There were mixed feelings about AI in the attendance: from anti-AI to found of AI with sceptics in the middle.

Here are some points, that we took away:

Software Freedom Conservancy still warns against the possible copyright issues on generated code.

Karen Sandler recommended to take a look at their LLM-backed generative AI recommendations.

The sustainability of the use of generative AI has also been a concern in several discussions.

I came back with a nice introspection question: “To what extent could you now stop using AI?”…

I will let you think about it for yourself.

I liked the idea that some other organizations have: “we’ll put as much effort in reviewing than you put in creating the PR”.

So basically, why would we want to spend time on reviewing an AI-generated change that the author did not review himself?

Some organizations have automation to detect fully AI-generated contributions and automatically prepend a robot icon (🤖) to the PR title.

I any case, defining an AI acceptable use policy will be needed for open source projects.

There may even be a link to such a document to set in next Google Summer of Code organization applications, so that this would be clear to applying contributors. Of course, this means that maintainers should not feel bad in ignoring code submission which are not matching these defined rules.

Working with GSoC contributors

Here are some notes in random order about how to improve how we work with contributors during GSoC.

• One of the interesting points for the GSoC admin team, is that it is acceptable to fail a contributor producing good code, but not involved in the community. GSoC is more about on boarding new contributors than code production.

• Communicating once a week with the contributor is not enough. Many organizations ask to provide at least a short status update every day. This would also help to know if they are sick or blocked on something. Some organizations even use this to produce a bi-weekly blog post on the overall GSoC progress.

• We need to ask contributors to first use the product to get familiar with it. This is specifically true for Uyuni as this is a complex beast. They could also be involved in the user channel to try to help users.

• In the past we invited GSoC students to become mentor next year. We probably didn’t do it enough, specially on Uyuni, and should try it more.

• Only using open channels for the communication with the GSoC contributors helps other mentors to chime in if needed. Using private discussions doesn’t help taking part in the community.

• Some organizations require the GSoC contributors to publish a weekly blog post with their progress, learning and blockers. This could be a good idea, but adds quite some work load.

Unclassifiable

We had a nice session and hallway discussions on mechanical keyboards. A question from people who don’t know about them: why did you really want to go down that rabbit hole!

We had a few emotional moments sharing our memories about Robert Kaye. He had a significant impact on Google Summer of Code and open source. Robert was really good at connecting people together and has been the one taking care of the chocolate room at the GSoC mentor summit for more than a decade.

It is also good to reconnect with mentors that I met at the past mentor summits and discover new people and projects.

The week-end also had plenty of occasions to celebrate, with a Halloween costume contest and a karaoke.

Thank you Stephanie, Mary, Lucy, Max and Erin for the organization of that amazing event!