GSoC Contributors

GSoC is basically an open source apprenticeship: contributors will be paid by Google to work under the guidance of mentors from an open source community. It's a really great opportunity to build new skills, make connections in your community, get experience working with a larger and often distributed team, learn, and, of course, get paid.

Time commitment

Contributors are expected work either 350 hours (full-time eqivalent) or 175 hours (part-time equivalent) over the course of the program. The default schedule runs over 3 months and can potentially be spread over a longer period. We do not recommend taking on another full-time internship, job, or schooling during the GSoC period, although a few weeks of overlap is often fine.

Application Process

To apply, you need to take a look at the mentoring organizations and the ideas that they are willing to sponsor. Typically, you'll choose one of their ideas and work with a mentor to create a project proposal that's good for both you and your chosen open source community. Sometimes, projects are open to new ideas from GSoC contributors, but if you propose something new make especially sure that you work with a mentor to make sure it's a good fit for your community. Unsolicited, undiscussed ideas are less likely to get accepted.

Note that Python is an "umbrella organization" which means that our team is actually a group of python projects that work together to do Google Summer of Code. If you're going to apply with us, you'll need to choose from one of those teams, because that defines which mentors will be helping you with your applications. Applications without any sub-org and mentor to evaluate them will be rejected. You can work with more than one sub-org while you're figuring out what you want to do.

Once you've narrowed it down to a project idea or two, use the application checklist to prepare your project proposal. (You can submit up to three proposals, but will only be offered one position if accepted.)

All applications are must be sent through the Google system.

Selection Tips

Google intends this to be a way for new contributors to join the world of open source. The contributors most likely to be selected are those who are engaged with the community and hoping to continue their involvement for more than just a few months. It's more important to be a good community member than it is to be a good coder, for most projects!

Read the instructions. A large number of contributors don't read the instructions when submitting proposals, and their applications get rejected. For example, every year we reject a number of contributors who submitted a resume, scientific paper, presentation or other file that doesn't contain any information about the project they would like to complete. Sometimes we get dozens of nearly identical form letters from a single university that wind up marked as spam. Don't do this!

Listen and use feedback from others. Every year, we reject a few contributors who simply wouldn't listen to their mentors. Remember: the mentors are using their interactions with you to figure out if it's worth their volunteer time to work with you. No one wants to have an intern who doesn't listen, and contributors who don't listen also don't produce code that the open source project can use, so contributors who don't listen don't get hired. Nor do contributors who are arrogant jerks, or who violate the Code of Conduct. Be professional and show that you will take the mentoring relationship seriously.

Here's some resources so you can read up more on how to be an awesome GSoC contributor:

  • The GSoC student Guide -- This is a guide written by mentors and former contributors. It covers many questions that most contributors ask us. (Note that it was written when all GSoC contributors were students.) Please read it before asking any questions on the mailing list or IRC if you can! New contributors in particular might want to read the section Am I Good Enough?
  • Google's list of resources -- Note especially the Frequently Asked Questions (FAQ) which does in fact answer 99% of the questions we get on the main GSoC IRC channel.

Python GSoC Frequently Asked Questions

  1. How do I choose a project or sub-org? (or What project should I choose?)
  2. What do I need to know to participate in Summer of Code with Python?
  3. How should I address my emails? (or Why shouldn't I start my emails with "Dear Sir"?)
  4. What does "don't ask to ask" mean?
  5. What should I do if no one answers my question?
  6. How many slots does python get? How many slots does project $x get?
  7. Where can I find information about previous years?
  8. What can I do to have the best chance of getting accepted?
  9. Why does Meflin always say no?

How do I choose a project or sub-org?

Choosing a project is a pretty personal choice. You should choose something you want to work on, and none of us can tell you exactly what that would be! But here's a few questions you might want to ask yourself to help figure that out:

  • What software do you already use? If you use the software, you know a lot more about it and probably have stronger opinions about what would make it better!
  • What would you like to learn? GSoC is meant to be a bit of a learning opportunity. Have you always wanted to be more involved with biology? Astronomy? Mathematics? Education? See which projects might help you improve your skills.
  • Who do you like working with? Hang out where the developers do and get to know some of your potential mentors. Which developers inspire you?
  • How do you want to change the world? Do you want to help people learn more? Communicate better? Understand our world better? Lots of python projects can help you do social good!
  • How do you like to communicate? Do you like realtime communication on IRC? Perhaps you should choose a project with mentors close to you in time zone. Do you like asynchronous communication on mailing lists? Find a group with active lists. Communication is a big part of summer of code (or really any open source development in a team) to finding a team that works the way you want to work can make your summer more awesome.

There's a list of sub-orgs for this year and lists of sub orgs who have participated in previous years Be aware that all sub orgs might not be able to participate every year, and make sure to check and see if they're planning to participate before assuming.

If you're chosen as a GSoC contributor, you're going to be expected to make some decisions on your own, so you can make a better first impression on mentors by showing that you're able to narrow down your field of choices!

What do I need to know to participate in Summer of Code with Python?

The answer to this depends a lot on the project you choose. We have a range of projects, from beginner to advanced. Each of the sub orgs expects different things from their contributors: maybe you'll need to know a bit about machine learning, or email, or image processing. The answer to this question is always ask your mentors what you will need to know for a specific project.

But a lot of people ask early on because they want to be sort of generically ready but they're not sure what they want to do yet, so that's not always super helpful.

So here's a list of a few things that are useful for most Python umbrella projects:

  • You need to have a bit of experience with Python. You can be a beginner, but practicing in advance is good! And there are a lot more projects available for contributors who are reasonably used to the language, so more practice means you'll have more project options.
  • You need to feel comfortable asking questions, because we're going to expect you to ask if you don't understand something.
  • You should be comfortable communicating your ideas to others in public. Most projects have public mailing lists and would prefer if you use them, and Python GSoC contributors are also required to blog about their work over the summer. You can use a pseudonym (nickname) if that works best for you. Google will need to know who you are to pay you, but we just need something to call you.

    All GSoC contributors are required to post weekly and answer these 3 questions in a post:
    • 1. What did you do this week?
    • 2. What is coming up next?
    • 3. Did you get stuck anywhere?


    These answers can be very short (Under 100 words) or longer depending on what you want to say. The idea is that these blog posts serve as your weekly check-ins with the org admins and help show the wider Python community what kind of work our GSoC contributors are doing.
  • You probably want some experience with version control. We have a lot of projects that use different tools, such as git, mercurial, or bzr, and you can find out which one your project uses in advance and practice using it on your schoolwork or personal projects to get used to it.
  • You might like to take a bit of time to read the python style guide, PEP8. Not every project uses these rules, but they can give you a rough idea of what is considered "readable code" by most pythonistas. (And for fun, you might want to read the poetry of PEP20 "The Zen of Python")

How should I address my emails? (or Why shouldn't I start my emails with "Dear Sir"?)

If you want to make the best first impression, DO NOT start emails with "Dear Sir." Python has many mentors who are female and/or prefer other forms of address. We realize you're trying to be polite, but "Dear Sir" is often perceived in our communities as alienating, rude or simply too formal and off-putting.

Try "Dear developers" or "Dear mentors" if you're sending a general email. If you're addressing a specific person, use the name or nickname that they use on their emails. Culturally speaking, first names or chosen nicknames are fine for most open source projects.

What does "don't ask to ask" mean?

You'll hear this phrase sometimes on IRC, and it means "please just ask your question, don't say something like 'can I ask a question?' first."

Why? Developers are often pretty busy, and if you just ask the question, someone can jump in the minute they see your message with the answer or direct you to folk who can answer it better.

If you ask "can I ask a question?" you're basically just waiting for someone to say "yes" before any useful information is communicated. Many folk consider this slow, annoying, and perhaps even rude. Save everyone (including yourself!) some time and just ask the question right from the start. Culturally speaking, in open source projects it's generally ok launch right in to a question on IRC; you don't even have to say hi first!

What should I do if no one answers my question?

  1. Be patient. If you're on IRC, stick around for an hour or so (you can do something else, just leave the IRC window open and check back occasionally) and see if someone gets back to you. If they don't, try posting to the mailing list (it's possible all the developers are asleep!) If you're on a mailing list, you should give people around 24-48hrs to answer before worrying too much about it.
  2. Make sure you're asking in the best place. One common mistake new contributors make is to contact individual developers rather than asking on a public mailing list or a public IRC channel. You want as many people as possible to see your questions, so try not to be shy! (and don't worry about looking too much like a newbie -- all of us were new once!) Sometimes projects have different lists/irc channels/forums/bug queues for different types of questions. If you're not sure, do feel free to follow up your question with something like "hey, I haven't gotten an answer on this... is there somewhere better I could post it or more information you need to help?"
  3. Try giving more information. If you've hit a bug, try to give the error message and information about your setup and information about what you've already tried. If you're trying to find a bit of documentation, indicate where you've already looked. And again "hey, I haven't got an answer... what other information could I provide to help debug this problem?" is a reasonable follow-up if you're not sure what people might need.
  4. If you're really having trouble getting in touch with your mentors, talk to the Python org admins by emailing gsoc-admins(at)python.org The Python org admins should have contact info for mentors with each project and can help connect you. (Note: please don't complain that you can't get in touch with us on the general Google Summer of Code lists or #gsoc. They're just going to redirect you to Terri and the other python org admins anyhow!)

How many slots does python get? How many slots does project $x get?

We don't know our slot allocation until Google announces them, and Google bases their numbers on the number of GSoC contributors we tell them we want. The more great applications we have, the more slots we'll request. So rather than worrying about the number of slots, you should be aiming to be such a memorable and great prospective GSoC contributor that your sub-org will definitely request a slot with you in mind.

For sub-orgs, new groups working with us usually get 1-2 slots, experienced sub-orgs may be granted as many as they can comfortably mentor at the discretion of the org admins. (The max number will likely be close to the total number of mentors divided by two, but the actual number requested depends on which GSoC contributors the org specifically wants to hire after they've done an initial review of the applications.)

Google has been incredibly generous with letting us have slots in previous years, so we are usually more limited by the matching of mentors with truly excellent contributors. We've had as many as 70 or fewer than 20 depending on the quality of GSoC applications.

If we get 100 applications and 50 of them are excellent, we'll try to find enough mentors for 50 GSoC contributors. If only 5 of them are excellent, then we'll be sad but we'll only request 5 slots and most of our mentors would take the year off. Sometimes whole sub-orgs take the year off because they have no excellent GSoC contributors. (and yes, if every single application we got was amazing we'd try to find a way to mentor all those contributors.)

Where can I find information about previous years?

SummerOfCode on the python wiki

Why does Meflin always say no?

He’s just like that! It's actually an incredibly important job: his job is to say no when things aren’t ready, so we can go back and make things more awesome. It's also his job to make sure that Terri's workload is reasonable, and that means saying NO pretty frequently. All those no’s make it possible to run this program every year!