Python Summer of Code

Contributors: get paid to work on open source projects!

Projects: find new contributors and mentor the next generation!

What is it?

Python

Python is a popular high-level programming language. It is a general-purpose language used by scientists, developers, and many others who want to work more quickly and integrate systems more effectively.

Google Summer of Code

Google Summer of Code (GSoC) is a global program that offers new contributors over 18 an opportunity to be paid for contributing to an open source project over a three month period.

The Python Software Foundation (PSF) is an organization devoted to advancing open source technology related to the Python programming language. Since 2005, the Python Software Foundation has participated in Google Summer of Code, serving as an "umbrella organization" to a variety of Python-related projects, as well as sponsoring projects related to the development of the Python language. Python provides mentors, Google provides the program (and the money!), and GSoC contributors write code!

GSoC 2026 has been announced!

Python is hoping to apply to GSoC 2026, but right now we don't know anything! We will not have a list of sub-orgs until late January 2026 and there is no guarantee we will be accepted as a mentoring org.

Contributors: Please start with the Python GSoC getting started guide. Last year's Ideas page has a list of organizations that took part, but we already know several that will not be returning in 2026. Please talk to the organizations directly. Now's a good time to get familiar with the projects and their needs.

Mentors and sub-orgs: Please contact the org admins if you want to be part of GSoC 2026.

How do I get started?

Choose an organization.

There's hundreds of thousands of projects that use Python, and you need to narrow down the list before you can get help or do much that's useful. See How do I choose a project or sub-org? for ideas on how to do that.

Any open source experience will help you prepare for GSoC, so don't worry too much about what project you try first and don't be afraid to change your mind! When we know which sub-orgs will be participating, they'll be listed with the project ideas.

Set up your own development environment.

Document what you do so you can remember it later, and so you can help others if they get stuck! And if you get stuck, don't be afraid to ask for help.

Start communicating with the developers.

Join the mailing list, IRC channel, or any other communication channels the developers use. Listen, get to know the people involved, and ask questions.

  • Read first to see if your question has already been answered. We get a lot of repeat questions!
  • Communicate in public (not in private). Most open source work is done in the open, so demonstrate that you can do that!

Try to fix a bug.

Many projects have these tagged as "good first issue" "easy" "bite-size" or "beginner-friendly" -- do a search to see what comes up. Competition for the easiest ones can be fierce, so don't be afraid to try something harder if you think you might know what to do.

Can't find a bug? Other ideas: find typos and fix them. Improve test coverage by writing new tests. Improve documentation. Use a tool like Pylint or Bandit to see if you can find new issues.

Find bugs and report them.

Hopefully you won't encounter too many, but it's always a good idea to get familiar with your project's bug reporting process.

Help with documentation.

As a beginner in your project, you're going to see things that are confusing that more experienced developers may not notice. Take advantage of your beginner mindset and make sure to document anything you think is missing!

Help others.

Most projects are looking for not just coders, but good community members who people like to work with. Show your community skills by helping others and make a great impression come selection time!

How to apply

Short application checklist:

  1. Read the links and instructions given on this site -- All of it! we've tried to give you all the information you need to be an awesome GSoC applicant.
  2. Choose a sub-org (check the list here). Applications not associated with a sub-org typically get rejected.
  3. Talk with your prospective mentors about what they expect of GSoC applicants and get help from them to refine your project ideas. Listening to your mentors' recommendations is very important at this stage!
  4. Prepare a patch for that sub-org. Usually we expect GSoC contributors to fix a bug and have made a pull request (or equivalent). Your code doesn't have to be accepted and merged, but it does have to be visible to the public and it does have to be your own work (mentor help is ok, code you didn't write is not).
  5. Write your application (with help from your mentors!) We have an application template to help you make sure you include all the information we expect. All applications must go through Google's application system; we can't accept any application unless it is submitted there.
    • Use a descriptive title and include your sub-org name in Google's system. Good example: "Mailman: Improve archive search" Bad example: "My gsoc project"
    • Make it easy for your mentors to give you feedback. If you're using Google docs, you can enable comments and submit a "draft" to your mentors. If you're using a format that doesn't accept comments, make sure your email is on the document and don't forget to check for feedback!
  6. Submit your application to Google before the deadline. We actually recommend you submit a few days early in case you have internet problems or the system is down. Google does not extend this deadline, so it's best to be prepared early! You can edit your application up until the system closes.

Tip

Communication is probably the most important part of the application process. Talk to the mentors and other developers, listen when they give you advice, and demonstrate that you've understood by incorporating their feedback into what you're proposing. We reject a lot of applicants who haven't listened to mentor feedback. If your mentors tell you that a project idea won't work for them, you're probably not going to get accepted unless you change it.

More tips are available in our contributor's guide and FAQ.

What goes in an application?

An ideal application will contain 5 things:
  1. A descriptive title including the name of the sub-org you want to work with (if this is missing, your application may be rejected!)
  2. Information about you, including contact information.
  3. Link to a code contribution you have made to your organization. (Usually this is a link to a pull request.)
  4. Information about your proposed project. This should be fairly detailed and include a timeline.
  5. Information about other commitments that might affect your ability to work during the GSoC period. (exams, classes, holidays, other jobs, weddings, etc.) We can work around a lot of things, but it helps to know in advance.

We also provide an application template to help you get started.

What do bad applications look like?

Python regularly discards about half of our the GSoC applications because they aren't valid. Here's what most rejected applications look like:

  1. Cover letter and/or resume only. This isn't enough information to match you with a mentor and project, so it will land you in our "ignore" pile.
  2. A blank file.
  3. A random ebook or other file on your hard drive. Not only is this not a valid GSoC application, it's often copyright infringement.
  4. Submitted your grand idea for improving Python the language. You can read more about how to propose enhancements to python in PEP-1, but GSoC is not the place for that.
  5. Project ideas not associated with a sub-org. Often these are related to current popular topics. For example, in 2020 we got a lot of covid-tracking application proposals. If you want to work on generative AI, LLMs, crypto, machine learning, big data, etc please apply to a do a project suggested by a mentor or work directly with a sub-org to make sure your project idea is something they actually want. Most "hot topic" ideas we get are very poorly researched, infeasible, or otherwise not viable GSoC projects.
  6. Really simple python application ideas that are not 175 or 350 hours worth of work (For example, a python "hello world" script. Seriously. We get several of these most years.)
  7. Random python code converted to a pdf.
  8. A small business or personal open source project idea. GSoC is not a startup incubator, sorry. You need to apply to work with an open source project that already exists and has mentors available.

Getting in Touch

Please note that Python has a Community Code of Conduct and mentors and contributors working with the PSF are asked to abide by it as members of the Python community.

Mailing Lists.

Sign up to the gsoc-general(at)python.org mailing list to get updates, reminders, and to discuss questions. Please join the list before you send a message!

The most common questions are answered here:

Live chat

Specific sub-orgs

To talk with people from a specific sub-org, check their ideas page listing for their mailing lists, IRC, and other contact information.

Tips!

  1. Read first. We've tried to answer the common questions on this site, and we get asked things like "How do I get started?" and "Where do I find easy bugs?" a lot. Check the Frequently Asked Questions (FAQ) on the GSoC contributor page for more!
  2. Be Patient! Our mentors typically have day jobs and can't always answer right-away. If you can't hang out on Matrix for an answer, send an email instead.
  3. Ask questions directly on Matrix. You don't need to introduce yourself or say hi first, just ask away!
  4. Communicate in public. That lets many mentors read your question so you can usually get an answer faster.

For mentors: All the gsoc admins can be reached at gsoc-admins(at)python(dot)org if you have questions about participating. (GSoC contributors should email gsoc-general(at)python.org with all of their questions, unless they are of a sensitive personal nature.)

Org admins

The 2025 Python Software Foundation (PSF) org admin team:

  • Terri Oda (@terri:python-gsoc.org on Matrix) - focus areas: figurehead, making final decisions, website/documentation
  • John Hawley (@warthog9:python-gsoc.org on Matrix) - focus areas: infrastructure, advice, emergency mentoring/mentor supervision.
  • Matthew Lagoe (Botanic on IRC) - focus areas: GSoC contributor blogs, irc bot, making sure things happen on time
  • Morgan Gangwere (indrora on IRC, @indrora@social.sdf.org on the fediverse) - org-admin; focus: backseat quarterbacking, tooling later on.
  • Ben Lewis (ben_zen on IRC, @ben_zen@social.sdf.org on the fediverse, as well as @ben@social.python-gsoc.org) - focus areas: mentor & org communication, timetables, coffee
  • Kushal Das (@kushaldas:matrix.org on Matrix) - focus areas: advice, time zone coverage

The org admins can be reached at gsoc-admins(at)python(dot)org (for mentors) GSoC contributors should almost always visit Getting Started first, and email gsoc-general(at)python.org only if you get stuck.

We also have some "org admins emeritus" who may be able to help you:

  • James Lopeman (meflin on IRC)
  • Florian Fuchs (florianf on IRC)
  • Stephen Turnbull (yaseppochi on IRC)

Other Stuff