You can prepare yourself for Google Summer of Code by contributing to open source software.

My background: I first started looking for an open-source project in Dec 2018 to be a part of Google Summer of Code 2019. Back then, I asked some previous year GSoC students about the preparation strategy — All they had to say was to pick a mentoring organization from the GSoC official website based on your tech stack and start with small contributions to the codebase. It could be fixing typos in the documentation, writing tests or fixing “easy to fix” issues. Believe me, it looked easy but most people can’t even do that. I had started learning to program just 6 months before that, so I didn’t have much confidence to even submit a proposal for GSoC in March 2019 because I couldn’t make any contributions. Then again, in June 2019, I decided to give it a try. After some research I found an interesting project, SymPy, and started sending patches around Dec. Furthermore, I got so involved in the community and by the time of applying for GSoC in 2020, I got several PRs merged into the SymPy codebase. Result: my project was selected!

This will be a detailed answer for beginners because I still remember what issues I dealt with, on my own, when no one was there to help me make my first contribution. This answer can also help you get started with open-source contributions in general, not necessarily GSoC. Note that the following are my personal views, and my mentoring org is not involved here at all. What I have noticed in my journey is that most first-time contributors face common issues:

• Not able to run the software locally and they just quit. Fix: that happens with a lot of people. . .So, after reading the installation guide (properly!) in the README, if you are unable to run the software on your system, then simply ask for help on the mailing lists or whatever channel they use. Some projects use Gitter, others use Zulip, et al.
• Fear of large codebase. That is a common issue that most contributors face. It looks overwhelming at first, but trust me, with the time you’ll get used to it. Fix: You need to deal with some specific files to fix issues, and you don’t have to understand the whole codebase at all in the beginning. Commands, like grep, come really handy while searching through large files. I have seen that some of the lead maintainers of the projects also don’t know all parts of the codebase, they are learning alongside you. Another trick here is to understand the codebase by fixing issues (when you’re just starting out, it’s normal to spend 1–2 hrs on a single issue), so try to fix as many issues as you can, send the patches, and get them merged. Even if you come up with a naïve approach to solving a particular problem, fellow developers will help you in improving the code even further. That’s the whole point of open-source, right? ;)
• Not able to find the best project which suits your tech stack. Hmmm…well, you have two options: Choose your org according to your skill sets or field of interest. For that, there’s this cool thingy I found online which gives you information about the organizations selected for GSoC in the past years. The second option you have is to take some time & just learn the tech stack your favorite organization is using. I would prefer the first option any day. You might not like the project after you get comfortable with the tools.

These were some of the common hurdles you might face while making your first contribution. But, if you get past these, congrats! You can now handle your trajectory on your own.

General Tips:

• Don’t try to learn a lot of tools/languages at the same time. You won’t get very far just by knowing the syntax. In fact, once you know any language then learning the syntax of some other lang won’t take much time, probably two weeks, not more than that. So focus on quality here. Learn to program — don’t just learn a tool. And it's obvious that it would take years, if not months. This page by Peter Norvig has some great advice for you, have a look: Teach Yourself Programming in Ten Years. Regarding the open-source contributions — even if you have made a small project (in your lang of choice) on your own before — you’re good to go! It could be a game you made for yourself and for others, a blog posting web app, an android app, your own website, whatever. Just build something before you dive into the world of open-source.
• Start early. Want to maximize your chances of selection? Start early. I personally feel it’s really important to start early because it was a significant factor in my acceptance. I have seen some proposals being accepted even though the students started contributing in March (Usually, the deadline is in the last week of March. Check on the official website for the exact date), but that could only happen when you have a kickass proposal. I got involved in the community in Dec, and that gave me enough time to pick up the best project for me out of the ideas list, and also: I was able to submit around 30 PRs by the time of the application deadline, and around 22 got merged. You don’t have to necessarily submit these many PRs because quality PRs matter more. Note that mentoring organizations are always looking for long-term contributors to the project. So don’t make them feel like you won’t contribute after the summer program.
• Follow the open-source etiquette. This Medium blog-post might give you more precise information. One thing I find really important is to be patient. Note that open-source projects are usually created by volunteers in whatever limited time they have available. Ask to-the-point meaningful questions, and wait for sometime before you ping on them again. Don’t just assume that they are available to answer your questions 24/7 — because they are not — most of them have full-time jobs. Also: please try to avoid being personal. Don’t call them by names, use their handles if you can in the pull requests or open issues, and be polite/friendly. Most probably they know much more than you do. You’ll notice sometimes they won’t reply to FAQs — and it's fine — don’t get offended because you can find the necessary info in the wiki page.
• Learn about Git & GitHub workflow, install a Linux distribution on your system, learn written communication. Being proficient in Git version control and getting comfortable with using GitHub is a necessity (You can check out what the project is using, and then learn that. Git and GitHub are most commonly used). Mostly the code you write will be pushed to GitHub. In the beginning, if you know how to submit a pull request and add commits to it, you can start making contributions. It would nice to learn git concepts, not just a bunch of commands (this Medium blog can be useful). Learn about branching. Play with it. Also: Install a Linux distribution on your system (I started with Ubuntu). Customize your development environment, get comfortable with a code editor (I use VS code), and stick to it. Open-source development is mostly done remotely so you have to learn written communication. Writing accurately is difficult but you need to convey your thoughts well enough.
• Don’t focus on more than 2–3 organizations. In my opinion, one should focus only on one organization (or two at max) and try to make a good impression in the community. Fix issues, write documentation/tests, suggest ideas, help first-time contributors, answer questions on StackOverflow related to your project if you can; Try best to show that you understand the project, and are really excited about it. Finally, try to choose your project from ideas list (which you may propose in GSoC) early on and send related PRs. It is highly likely that you will be selected if you have good PRs in the part of codebase your GSoC project is related to. The more effort you put in, the more they’ll trust you. See the following graph for some inspiration (only to show that it’s good to be consistent):

• Submit a kickass proposal. Above all, try to submit an excellent proposal because that’s what matters in the end. They’ll select you based on that. Try to make it at least 15–20 page long, and that will show the research you have done. Have a look at previous year accepted proposals and prefer the same template. Add code snippets for the desired functionality, that would be great! Even if you haven’t contributed a lot to the project before the deadline, at least try to make a good proposal, you never know they might select you.

I’m sure you would have learned a lot of new things by the time you’ll submit your proposal(s). After you submit your proposal(s), there’s a 1 month period before the accepted projects are out. Keep on sending patches in that period because a lot of students don’t get involved in the community.

Don’t get dishearted if your project is not accepted. In fact, take it as a challenge to try again next year (if you’re eligible, of course) with more enthusiasm and after gaining some skillset. No matter which university you’re in, no matter what your major is, as long as you show them that you have the right skills, you’re good to go! Around 1200 proposals are accepted each year with proposals coming from students across the world; luck plays a big role here. What you can do? Try your best!

EDIT:

Now, I’m a GSoC Mentor—maybe I can share some points about the application review process to help y’all. Hmmm.

After you guys submit your proposal, the organization mentors and admins will take some time to review all the ones they receive. They can quickly separate well-crafted proposals from the garbage ones. So don’t write a 2–3 page long garbage proposal. To maximise your chances of selection, here’s what you could do:

• Reach out to the potential mentor of your desired project early on. They will surely help you solidify your proposal before you submit it on the website. If they show some interest in your proposed idea, that means it is probably an important project for the organization at the time. Remember that there are cases when any excellent proposal could get rejected because there is no one available in the org at that particular moment who could mentor that project. So interact with the mentors early. It’s a great chance for you to make a good-first impression—if possible do some portion of your project before the deadline. They do appreciate that very much. Basically what they wanna know is: can you successfully complete the project in time?
• Pleasant interactions with the community will definitely take you a long way. It’s better not to insult someone (or have a condescending attitude) because everything is public. Even when you’re trying to correct someone, try to do it politely, like: “Hey there! I think it could be better for us to do it this way.” Not like: “You’re wrong here. Follow my way.” That’s just how the open source ecosystem is.

Lastly, I feel like GSoC is both an underrated and overrated program (in a country like India; roughly half of the accepted applicants are from there).

Underrated because a lot of students don’t actually realize the importance of open-source contributions aside from getting into GSoC. So many companies value developers who contribute to OSS as a hobby. Any accepted student who stays in touch with the community after the program is over is most ideal for any organization.

Overrated because GSoC is not the only way to gain experience. There are many other similar programs like Outreachy, MLH Fellowship, Google Season of Docs, GirlScript Summer of Code, etc. Just making contributions to any well-known OSS like Tensorflow, Reactjs, CPython or Golang is a great achievement in itself, and can be added in your résumé.

Anyway this was about GSoC. Best of luck, may the source be with you! ;)