Google Summer of Code 2012

Here's what i have to say on the topic (it's mostly freeform, so i decided not to send it as a text file; if you do need a text-file version, ask - i'll provide it):

Your chances to get accepted and complete GSoC successfully will increase, if you're very good at software development. "Very good at" usually means that you're top of your programming class, and you probably dabbled in software development before becoming a student. If you develop software on a regular basis, your skill will (usually) raise over time, and your chances to complete GSoC will raise along with it (that is, second-year students have more chances than first-year students). If you're a year away from your graduation and you've been the top student in your programming class, and you're matching all other requirements of a project, then (barring any unfortunate turns of events) the probability of you being accepted and passing GSoC successfully is nearly 100% (unless you're terminally lazy). That said, if you aren't as skilled, but your experience with software development has told you that you might have the right aptitude, then you have a chance, never doubt that!

Obviously, look at the projects/organizations that use the programming languages you know. You might not have a lot of experience using that particular language; it's usually enough to just be familiar with it (i.e. complete a course in C++ without writing any real C++ programs other than those required to pass the course exams). If you are not familiar with the programming language required to apply for a project, but believe that you meet all other criteria (see below), consider your learning ability, and try to read a tutorial or a book that teaches the required programming language. If you know 2 or 3 different languages and know the right programming paradigm, learning a new programming language is not very difficult. If you are not an experienced programmer, and need to learn a language for a project, then look for a project that requires the use of an easy-to-learn language (Python, Ruby, etc). That will improve your chances. If learning is required, then do talk with the developers. Some organizations have welcoming community and will gladly help you to learn; others will not, and you will be left to your own devices.

Discuss an application with the developers. At length. Use IRC or a mailing list - whatever is best for a given organization (some organizations favor IRC, other - mailing lists). They might suggest some ideas or variations not present in their ideas list.

You can also propose your own projects! If you've been dying to implement a new feature in your favorite software package - here's your chance! That is, if you find someone who will agree to be your mentor for that project.

Fixing several long-sanding bugs might be considered important enough to constitute a project. In fact, many pieces of software need bugfixing more than new features, so don't be afraid to suggest yourself for a role of Bugfixing Guru (that is, if you're sure of your bugfixing abilities in the context of that particular organization).

Some (but not all) projects require not just programming skills, but also some scientific or engineering knowledge (such as signal processing, gene sequencing, law, artificial intelligence, and all kinds of math). If you have the knowledge required for a project, and are able to program at all (but not on the right language), then that's probably better than knowing the required programming language, but not having enough knowledge in the right field. But, again, not all project require that kind of special knowledge.

Once you've chosen a promising project (or came up with an idea of your own, and the developers from the organization you're aiming to apply to think it to be a good idea, and you've found a mentor for it), try to download and compile the source code for the software you'll be working upon. If you need help compiling it - look for tutorials/HOWTOs. Also ask the developers - they might have something to say regarding your particular build environment and/or platform. If you succeed - mention that in your application. It will score you some additional points with the developers.

Once you've got things compiling, try to write something. If a [small] subset or part of your project (one small feature, handling only some of the simplest cases, and full of dirty hacks) can be completed quickly enough (a couple of days) - try to do that. Otherwise, come up with some schemes, or make a verbal descriptions of the changes you're going to make, pointing out the places in the application's code that will require changes, and how your code will interact with it. If the project requires some kind of protocol or data storage - come up with a protocol description or a storage format specification. If the software you're going to develop is complex enough - make a diagram or a flowchart that shows the components (existing and yet-to-be-developed ones), and how they interact. All of that will show the developers that you understand their code and your task.

If the organization you're applying to has a wiki and allows you to use it - do use it to publish some of the information for your application. While Google will keep your application in Melange for historical purposes, and it won't be lost afterwards, adding info to organization's wiki page is already a small contribution and improves your image.

Language skills are important. While this might not apply to all communities, you'll usually get best results by participating in any discussions (in chats and mailing lists) among the developers, if you have something meaningful to say (but avoid "bikeshedding"). And you should try your best to participate in any discussions related to your project. With anyone, not just your mentor. If you're accepted, keep your discussions public. Ask for advice, or for other developers' opinion on things you do. Your mentor has some authority over you and your project, but other developers might be able to help you better (especially if your mentor is not available as often as you'd like him/her to be), and their insights are valuable. All that means knowing the right foreign language. If the developers only speak English, and you don't, your chances to be accepted will be lower (and if you're accepted, it might be more difficult to complete the project). If one of the developers speaks the same language as you do (happens in some large international organizations) - you might pass, but again, this will hamper your ability to participate in public discussions, which might reflect badly on your project.

Your ability to learn is important. Good learning skills will allow you to quickly cover your lack of knowledge or skill before and during the application period, and they will help you complete the project once you're accepted. All software developers learn, and you, as a student, will learn even more. Even if you're an accomplished programmer, you still stand to learn a thing or two.

If all of the above made you think that students who are well-prepared and well-educated in programming, social interactions and sciences have better chances of being accepted - you're absolutely right. Luckily, such students are relatively rare. Don't be discouraged, even if you're lacking in something - you'll learn as you go.

If you don't know English (or whatever language the developers are using among themselves; but it's usually English) as good as you'd like - take some time to write and proof-read your e-mails to the mailing list, and try to participate in chats as best as you can. You might notice that your command of English improves over time. Hey, in many educational programs you have to pay to learn something. In GSoC Google is paying YOU to learn! How cool is that?!

All things considered, it's better to do 2-3 good and well-researched applications, than to apply for 10 projects simultaneously. Don't spread yourself too thin.

Don't lie. Be objective.

If you haven't done everything described above (code compiling, tools familiarity, learning to participate in community discussions, project-related research) - do that. There will be a stretch of time called "Community Bonding Period" (about a month), it's purpose is for you to get familiar with the code base, tools, documentation, developers, etc (yes, that's right: while you're supposed to do some of those things AFTER being accepted, doing them BEFORE being accepted improves your chances to be accepted; sad, but true).

Google will require a copy of all your contributions at the end of the program. Just a formality, but make it easy for yourself, and set up some kind of version control system (or use the one the organization of your choosing uses). Later you'll be able to dump all your changes as patches, pack them and send that tarball to Google.

If you completed a 3-month project in 3 days, it means one of the following:

• You're a genius. The developers will find more work for your agile mind.
• Your project is too easy. The developers will find more work to fill your spare time.

But that is a rare occurrence. Usually you'll be running out of time instead. But it's OK to review your project during mid-term evaluation and set new (realistic) goals, if the original ones can not be achieved in time, and there are objective reasons for that. But it's better to set realistic goals from the start, rather than change them as you go. Some projects allow for several stages of completeness. For example, a project might include a major feature and a couple of minor features; if you can't finish everything in time - concentrate on the major feature, you might still pass the evaluation (obviously all that is to be discussed with your mentor).

Don't take long breaks. The longer you stay out of the development, the harder it becomes to dive back (although it depends on the nature of the project and on your talents and personality; sometimes a project is so interesting, that you can't wait to code some more!).

If you're not coding for your project - think about your project. Thinking helps too (sadly, it does not help you to pass the evaluation; a lot of well-written and working code does).

Students can submit their applications via the Google Summer of Code 2012 site from March 27 - April 9, 2012. We hear almost universally from our mentoring organizations that the best applications they receive are from students who took the time to interact and discuss their ideas before submitting an application, so make sure to check out each organization's Ideas list to get to know a particular open source organization better. In addition to an application, students will be required to sign a Student Participation Agreement.

Your application should include the following: your project proposal, why you'd like to execute on this particular project, and the reason you're the best individual to do so. Your proposal should also include details of your academic, industry, and/or open source development experience, and other details as you see fit. An explanation of your development methodology is a good idea, as well. It is always helpful to include contact information as well, as it will not be automatically shared with your would-be mentors as part of the application process. If the organization you want to work with has a specific application template they would like you to use, it will be made available to you to fill in when submitting your proposal via the Google Summer of Code web app. [note: the PicoLisp community has not specific application template]

Yes, each student may submit up to twenty applications. However, only one application will be accepted. We've heard from our mentoring organizations that quality is better than quantity.

Yes, as long as they meet all other requirements for program eligibility. Students should be sure to note their previous relationship with the project in their applications. New work will need to be done for the project as part of participation in Google Summer of Code.

That's up to you. Keep in mind, though, that our mentoring organizations will be publishing a list of proposed project ideas, so you may find that you'll want to revamp your application later, or create an entirely new one to address one of those ideas.

No, each participant may only work on one project and is only eligible for one stipend.

No, only an individual may work on a given project.

That's fine, a little duplication is par for the course in open source.

While we greatly appreciate the value of documentation, this program is an exercise in developing code; we can't accept proposals for documentation-only work at this time.

Google will provide a stipend of 5500 USD per accepted student developer, of which 5000 USD goes to the student and 500 USD goes to the mentoring organization.

Accepted students in good standing with their mentoring organization will receive a 500 USD stipend shortly after coding begins on May 21, 2012. Students who receive passing mid-term evaluations will receive a 2250 USD stipend shortly after the mid-term evaluation deadline, July 13, 2012. Students who receive passing final evaluations and who have submitted their final program evaluations will receive a 2250 USD stipend shortly after the final evaluation deadline, August 24, 2012. Mentoring organizations must request their payments of 500 USD per student mentored by November 5, 2012.