Photo by Hans-Peter Gauster on Unsplash
GSoC: All You Need To Know
Important information regarding GSoC curated from sources recommended by the Official GSoC Website
Tips From Advice For GSoC
Think about you.
What computer science subject area or specific issue or problem interests you? What are your skills? What languages do you know? What tools are you familiar with? Make a list.
Verify your application meets all requirements
Make sure your application includes the specific information and format the org asks for, as well as what is required by the GSoC program rules. Double check your work before submitting the proposal: misspelling in writing has a similar result as does misspelling in code :-)
DO NOT WAIT UNTIL THE LAST MINUTE TO APPLY.
(This is so important, we put it in ALL CAPS.)
Every year we get potential contributors asking for extensions to the application deadline. We can not give extensions for any reason, even if your internet is down, you were in exams, your computer was stolen, you misunderstood the timezone, you were on a plane or in the hospital. It is in your best interest to submit the application early.
Plus, the longer the org has to review your application and give you feedback on your draft, the better your chances of being accepted as a GSoC contributor.
FAQs
Can a group submit a proposal together to work on a single project?
No, only an individual may work on a given project.
Can I submit more than one proposal?
Yes, each GSoC Contributor may submit up to three proposals. However, only one per GSoC Contributor may be accepted. No more than one proposal per GSoC Contributor will be accepted, no matter how many proposals you submit.
What does a good proposal look like?
The Contributor/Student Guide has a section on "Writing a Proposal".
The best proposals are from participants who took the time to interact and discuss their ideas with the organization before submission. Be sure to include the following: detail on exactly what you're proposing, why you're proposing it, the reason you're qualified to do it, your development methodology, your expected timeline, etc. It should also include details of your academic, industry, and/or open source development experience.
Do not just read a Project Idea from the org's list and then write your proposal - you need to talk to them. Contributors who don't discuss their proposals with the target organization are very unlikely to be selected for GSoC.
Should I send proposals directly to the mentoring organizations?
No, all proposals must be submitted through the program site. Proposals submitted outside of the Google Summer of Code program site will not be considered for Google Summer of Code.
You are strongly encouraged to reach out to the mentoring organization early to discuss your ideas and get feedback and a better understanding of the work they do before submitting your final proposal.
Do I get paid for participating in GSoC?
Yes! Google will provide a stipend to GSoC Contributors who pass their evaluations and are able to receive stipends.
How much time does GSoC participation take?
Organizations have scoped projects based on total expected time to complete a project. Small size projects should take about 90 hours, medium size projects about 175 hours to complete, and large projects about 350 hours to complete. Depending on your skills and the difficulty of your project it may take you more or less time to meet the goals of your project. If it becomes that your project was underscoped or overscoped you and your mentor will work together to adjust accordingly.
Can the schedule be adjusted if my school ends late/starts early?
The GSoC 2024 program has some flexibility in the schedule for projects. The length of time allowed to complete a project can range from 10 weeks to 22 weeks for medium and large projects with the standard length of 12 weeks. Small projects can range from 8 to 12 weeks. GSoC Contributors and their mentors can decide together if a project should be extended to end a couple of weeks or so later.
The program start date cannot be changed, everyone will begin the program at the same time.
You and your mentor may jointly agree to adjust the scheduling of milestones or weekly work schedule to allow for some flexibility within the overall program framework.
The first evaluation date is based at the halfway point of your expected project timeline. For medium and large projects it will be after 6 weeks for projects in the standard 12 week schedule). For small projects it will be after 4 weeks based on the standard 8 week project.
GSoC Rules
Organisations
Responsibilities.
Each accepted Organization will perform all necessary additional steps required for the Organization to participate in the Program, including:
providing an Ideas List;
determining the Organization Project Criteria, provided that the Organization may not discriminate on the basis of age, race, creed, color, religion, gender, sex, sexual orientation, national origin, disability, marital or veteran status or any other basis that is prohibited by applicable law; and
assigning two or more persons, as applicable, to:
serve as the Organization Administrators;
evaluate GSoC Contributor Project Proposals submitted to the Organization in accordance with Section 7.4 below and decide which Project Proposals to accept;
help GSoC Contributors integrate with the Organization’s community during the Community Bonding Period;
serve as Mentor(s); and
serve as alternate Mentors in the event an existing Mentor is unable to fulfill their responsibilities.
If Google reasonably believes that an Organization has failed to meet the foregoing responsibilities, Google may remove such Organization from the Program.
Each Organization is responsible for its Organization Administrators and Mentors. If Google reasonably believes that an Organization Administrator or Mentor for an Organization has failed to meet any of the responsibilities set forth in Sections 5.3(a) or 6.3(a) below, as applicable, Google is not required to issue any stipends to the Organization.
Organization Administrators
Responsibilities.
The Organization Administrators for an accepted Organization will:
act as the main points of contact between Google and the Organization and will respond to any inquiries from Google within thirty-six (36) hours;
oversee the overall progress of the Organization and its GSoC Contributors throughout the Program;
perform administrative tasks regarding the Program for the Organization, including publishing the Organization’s Ideas List and designating one or more Mentors for each accepted GSoC Contributor through the Program Website;
edit GSoC Contributor project schedules when requested by Mentors from their Organizations;
oversee and manage Mentors to ensure that they meet their responsibilities as set forth in Section 6.3 below;
complete the necessary forms required to receive (or decline) the applicable stipends by the posted deadlines as set forth by Google Program Administrators;
complete the followup questionnaire from Google sent at the six month and one year mark post program; and
review the “Roles and Responsibilities” document published on the Program Website and be sure they, and each of their Mentors, are meeting the responsibilities outlined therein.
If Google reasonably believes that an Organization Administrator has failed to meet any of the foregoing responsibilities, Google may require the Organization to designate a replacement Organization Administrator.
Mentors
Responsibilities.
Each Mentor for an accepted Organization will:
participate in the Community Bonding Period;
provide guidance to their GSoC Contributor(s) on their Projects for the Organization;
use best efforts to respond to GSoC Contributor requests within thirty-six (36) hours;
provide Evaluations of their GSoC Contributor(s)’ work as described in Section 8.1 below in accordance with the Organization Project Criteria; and
review the “Roles and Responsibilities” document published on the Program Website and be sure they are meeting the responsibilities outlined therein.
If Google reasonably believes that a Mentor has failed to meet any of the foregoing responsibilities, Google may require the Organization Administrators to designate a replacement Mentor and remove the former Mentor from the Program.
GSoC Contributors
How to Apply. GSoC Contributors who wish to apply for acceptance into the Program must:
accept the terms of the GSoC Contributor Agreement, and
submit a Project Proposal through the Program Website during the application period described in the Program Timeline.
Project Proposals.
GSoC Contributors must submit Project Proposals to Organizations through the Program Website during the application period described in the Program Timeline.
Each GSoC Contributor may submit up to three (3) Project Proposals; however, only one (1) Project Proposal may be accepted per GSoC Contributor.
Project Proposals may, but are not required to, be for Projects on an Organization’s Ideas List.
If a Project Proposal is for a Project that the GSoC Contributor is already working on, the GSoC Contributor must note this in the Project Proposal. Any work done on the Project prior to acceptance of the Project Proposal will not be considered for Evaluations.
Acceptance.
Project Proposals will be reviewed by the Organizations to which they were submitted. An Organization may accept or reject any Project Proposal at its sole discretion. In the event that two (2) or more Organizations wish to accept Project Proposals from the same GSoC Contributor, the Organization that ranked the Proposal the highest will be granted the GSoC Contributor for their Organization. Google will announce the Project Proposals accepted to the Program on the Program Website.
Each GSoC Contributor with an accepted Project Proposal will be matched with at least one (1) Mentor from the applicable Organization.
GSoC Contributors without an accepted Project Proposal may not continue with the Program and their Google Summer of Code 2024 account will become inactive.
Responsibilities.
Each accepted GSoC Contributor will perform all necessary additional steps required for the GSoC Contributor to participate in the Program, including:
participating in the Community Bonding Period;
providing Evaluation of their Mentor as described in Section 8.1 below;
working diligently to complete the Project as it may be modified with the agreement of the Organization;
following the coding and documentation standards set out by their organization;
actively participating in the Organization’s community and adhering to the Organization’s rules and codes of conduct; and
publishing their Project code in a publicly accessible location and under an Open Source Initiative approved license of the Organization’s choice.
If Google reasonably believes that a GSoC Contributor has failed to meet the foregoing responsibilities, Google may remove such GSoC Contributor from the Program.
Program Participation
Evaluations.
Multiple Mentors. If a GSoC Contributor has more than one (1) Mentor:
the GSoC Contributor is only required to submit an overall Evaluation of the Mentors; and
only one (1) Mentor is required to submit an Evaluation of the GSoC Contributor. If more than one (1) Mentor submits an Evaluation, only the final Evaluation submitted before the deadline will be accepted.
Form. Evaluations must be in the form of responses to questions provided by Google through the Program Website.
Deadlines. GSoC Contributors and Mentors must submit Evaluations through the Program Website by the deadlines set forth in the Program Timeline. Evaluations are given at two (2) points: after Phase 1, and at the end of the Final Phase.
Visibility.
Except for any fields labeled “shared with GSoC Contributor” (“Shared Comments”), Evaluations submitted by a Mentor will only be visible to the Organization Administrators, the GSoC Contributor’s other Mentor(s), if applicable, and the Program Administrators. The GSoC Contributor will only see a pass/fail grade result and any Shared Comments.
Evaluations submitted by a GSoC Contributor will only be visible to the Program Administrators. The Organization Administrators and Mentor(s) will only see the parts of the evaluations explicitly indicated Viewable by Mentors and/or Organization Administrators.
Notwithstanding anything to the contrary in subsections (i) and (ii) above:
Google may make Evaluations available to other Google employees, third parties, or the Organization or GSoC Contributor, as applicable:
upon the GSoC Contributor’s or Organization’s prior written consent, as applicable; or
if Google deems such action necessary to administer the Program (e.g., where the Program Administrators need assistance from other Google employees in their review to reconsider a GSoC Contributor’s grade or where the feedback may be vital to arbitration with the GSoC Contributor or Organization regarding payment or non-payment of a stipend).
Google may use Evaluations internally to improve Google Summer of Code.
Grading; Missing Deadlines.
The Mentor will evaluate the GSoC Contributor’s Project Submissions based on the work from the beginning of the work period until the start of the evaluation period. Any work done during the evaluation period itself will be considered for the next evaluation period.
The Mentor will evaluate the GSoC Contributor’s Project Submissions against the Organization Project Criteria.
If a GSoC Contributor receives a failing grade on the Phase 1 Evaluation, the GSoC Contributor will be removed from the Program.
If an Organization Administrator does not agree with the grade given by the Mentor to a GSoC Contributor, the Organization Administrator may submit an updated Evaluation, which will supersede the original Evaluation. This updated Evaluation must be complete before the original Evaluation deadline.
If a Mentor fails to submit an Evaluation by the applicable deadline, the Organization will not receive any offered stipend for that GSoC Contributor mentored.
Final Project Materials. GSoC Contributors must submit their Final Project Materials through the Program Website by the Final Evaluation deadline. If a GSoC Contributor fails to do so, the GSoC Contributor will be deemed to have received a failing grade on the Final Evaluation, regardless of the actual grade the GSoC Contributor received from the Mentor.
Payment
Stipends. Stipends are offered at Google’s discretion and, if offered, are subject to subsection (b) below. GSoC Contributors and Organizations may receive stipends from Google as follows:
GSoC Contributors. Stipends for GSoC Contributors are at Google’s sole discretion, and are adjusted to cost of living based generally on the country in which the GSoC Contributor is currently residing. GSoC Contributors will be required to provide proof of residency in their country along with other compliance documentation when registering for their Payment Processor account, which is how they will receive their stipends.
Each GSoC Contributor who has received a passing Phase 1 Evaluation may receive a stipend after the Phase 1 Evaluation deadline.
Each GSoC Contributor who has received a passing Final Phase Evaluation and who has submitted the Final Phase Evaluation of their Mentor on time may receive a stipend after the Final Phase Evaluation deadline.
Google will endeavor to issue stipends within 5 business days to all GSoC Contributors who received passing evaluations from their Mentor and have an active Payment Processor account.
If the GSoC Contributor is unable to create an account with Google’s Payment Processor within the specified time period, Google may not issue any funds to that GSoC Contributor.
Organizations. If Google, in its sole discreption, decides to issue Organization stipends per GSoC Contributor mentored, Organizations will be required to meet deadlines as specified by Google Program Adminstrators in order to recieve any payments. Google is not required to pay amounts requested after any announceed deadlines.
Google shall not issue any funds to U.S. state or federal government or public university employees in the United States.
Google shall not issue any funds to Google led Organizations.
Google shall not issues any funds if the Organization is a part of the U.S. federal government.
If the Organization is unable to create an account with Google’s Payment Processor within the specified time period, Google may not issue any funds to that Organization.
Google is not required to pay any stipends to any GSoC Contributor or Organization that violates any applicable law or regulation, including money laundering regulations.
- GSoC Contributors and Organizations must be able to create an account and pass the Payment Processor’s compliance checks. If a GSoC Contributor or Organization does not pass the Payment Processor’s compliance check they cannot receive any stipend for the Program.
Tax Documentation. Tax-related documentation must be submitted by July 15, 2024 for GSoC Contributors. GSoC Contributors submitting tax-related documentation after the above dates will be disqualified from receiving any stipends. Google is not required to issue any payments if tax-related documentation is submitted after these dates.
- GSoC Contributors. GSoC Contributors must submit tax-related documentation during their registration with the Payment Processor.
Final Results
Google will announce the Final Results on the Program Website.
Preparations(Video)
Read the student guide
Past Proposals
Timeline
Good Proposal
Thoughtful
Well Documented
Easy to Read
Long enough
Proposals way to evaluate candidate's understanding of the engineering process
Proposals starting point for conversation
Send Draft Proposal Early
- Keep editing draft proposal
Includes previous experience and interest
Set realistic milestones
Communicate early and often
Consider non-code contributions
Reporting Bugs
Helping other applicants get started
Contributor Guide
Am I Good Enough?
The soft skills
You find out where to go for help with technical questions
There are many available resources on the interwebs to go to for help with technical questions, knowing how to use a search engine to begin your search is very important.
You take and respond well to feedback
The community developed software model relies heavily on constructive feedback and the willingness for each contributor to take that criticism and make the code better. You are going to be getting regular feedback from your mentor – not all of it is going to be “this is great” “you are awesome.” Learning from and graciously accepting feedback is a very important trait for a successful GSoC contributor.
You can work independently
Since you’ll be spending significant amounts of time working alone - not being afraid to face the unknown and start breaking down what may initially seem like insurmountable problems independently is important.
You know when to ask questions
Do you think you already know everything about everything in the world of open source programming? Then you probably aren’t good enough for GSoC!
You can communicate effectively
Communication is key to GSoC. We will mention this many times in this guide. Being a successful GSoC contributor requires you to communicate with your mentor and the community regularly. Much of the time the communication is via chat or email but you may also have weekly video chats with your mentor or community. If you are behind schedule or you are stuck on implementing something but have tried to find the answer to no avail, reach out to the community and your mentor, don’t stay stuck.
Pro Tip: Read the organization’s requirements or skills they are looking for in potential GSoC Contributors
Be aware that some requirements are likely to be firm and you must meet those requirements for the organization to consider your application. For example, many organizations require potential GSoC contributors to submit pull requests as part of their application, or they require you to have a chat with someone in the community about your idea before submitting your proposal. More complicated projects will likely require familiarity with particular programming languages, processes or techniques. It is also possible some organizations may be looking for students who are earlier in their development, while other organizations may be looking for applicants more advanced in their skills.
However, some of the requirements may be less stringent and could be things you can learn quickly, just be sure to mention that you are working on these skills, etc. when you are discussing your proposal with the organization.
Making First Contact
How to observe community interactions
Join both the development and user mailing lists and spend a few days just reading the conversations.
Read the mailing list archives.
Join the project’s discussion forums/chat channel (IRC, Discourse, Slack) and lurk for a bit.
Read all the available information on past GSoC projects.
Take a stab at going through the project documentation, at least to the point where you feel like you can ask questions that are not already extensively covered in the docs.
At the end of your “listening and research” phase you’ll understand how, where and when the community interacts and know the best way to ask questions.
How to begin participating in conversations
Introduce yourself! If you are new to the community you need to let people know who you are and why you are interested in contributing to the project.
Ask questions. You should be able to come up with at least a few legitimate questions before offering your opinion on the right way to do things.
Be humble. Until you’ve engaged with the community, for at least a few months, assume that those people talking about things probably are privy to community nuances you might not yet see.
Don’t be intimidated. Don’t let a bad experience stop you from getting involved. Just relax and think about why you were snubbed and if there’s anything that you should be careful about before participating in another conversation.
No matter what, don’t wait until the application period to initiate contact - really! Engage with multiple communities once the participating organizations are chosen to get a feel for how different groups work and find the one or two that fit your interests/personality.
Finding the Right Project
Ask questions
Consider any questions you might have about the project, how it might be implemented, and what it would entail. Read the FAQs. If there’s still anything unclear about the project and requirements, get your doubts cleared. Formulate your questions and suggestions regarding each idea into a clear and concise communication.
Evaluate your options
Once you’ve researched the shortlisted projects and got your questions answered, re-evaluate your options before writing the proposal. Also think about whether the communities you’re interested in match your needs, and if you’ll have fun working with those people. Is there enough documentation and help available to get you started on the project? Given all the feedback, do you think you’re really excited about the project and think that you can do a good job of it?
From Project Idea to Project Plan
You’ve narrowed down your search of organizations and projects, you’ve made first contact, and you’ve started communicating directly with potential mentors. Now it’s time for the critical process of turning a project idea into a project plan.
In most cases, your potential mentor(s) will have lots of ideas and preconceptions about each project that were not included in its original description on the Project Ideas page. Discuss and research the project idea in as much detail as possible. You may even consider preparing mock-ups (illustrations, powerpoint, or websites) to help clarify your understanding and vision of the project. You will want to discuss the scope of the project idea, including which parts are critical versus optional for the program timeline. This process will directly feed into your application and ideally distinguish it from all the others. Just think about it: if you’ve helped clarify the project idea and contributed to an actual plan of action, it makes it an easy process for mentors to evaluate your proposal and give it a high ranking!
Pro Tip: The earlier you apply, the better. Submitting your proposal early helps you get early feedback.
Don’t be that person: Cut and pasting an idea from the organization page and turning that in as your project’s description is a big no-no. You’ll be expected to research and submit your own ideas about how to accomplish the project your way, not just state the end result.
Writing a proposal
The Basics
First and foremost, make sure you meet Google’s formal requirements for participation in Summer of Code. This includes ensuring that you are eligible to work in the country where you reside for the duration of the program. Remember, if you are in a country on a student visa or another type of visa you could have restrictions on the number of hours you can participate in a program like GSoC or you may not be eligible to participate at all. Hopefully, you have already checked this by now, but be sure to double-check before you waste time and energy on a proposal.
Inventory your time. Figure out how many hours per week are already spoken for outside of your GSoC commitment, including time spent volunteering for other projects and activities, a part-time job or counting credit-hours of academic instruction. In any case, be completely clear about outside time commitments as part of your proposal. If you know you need to take a couple of weeks off because of finals or a wedding, etc. be upfront with the mentors, we have added some flexibility into the program so this should be fine, you just need to let your mentor know as soon as you know the details. Do not surprise an organization with your time commitments later on. It may be possible to extend the end date of your project if your org will allow it. But this should be discussed early on so everyone can be on the same page.
Make sure that you are able to be in regular close contact with organization mentors via the usual open source means (email, chat, etc) for the duration of the program. It is not necessary (or likely possible) that you be geographically near your mentor. However, if you are not sure you will have good Internet connectivity continuously over the summer, GSoC is not for you.
This program is the Google Summer of Code. If you are less than fluent in the programming languages that your target organization uses, you might want to skip the work of writing an application. If you do decide to proceed, be clear about your level of ability, so that the organization can make an informed decision.
Elements of a Quality Proposal
Most organizations have their own proposal guidelines or templates. You should be extraordinarily careful to conform to these. Most organizations have many, many proposals to review. Failure to follow simple instructions is highly likely to land you at the bottom of the heap.
There are certain elements of the proposal that should apply to every organization. Proper attention to these elements will greatly improve your chances of a successful proposal.
Name and Contact Information
Putting your full name on the proposal is not enough. Provide full contact information, including your preferred name, email address, websites, etc.
Title
Your title should be short, clear and interesting. The job of the title is to convince the reviewer to read your synopsis. Do not put your name in the title.
Synopsis
If the format allows, start your proposal with a short summary, designed to convince the reviewer to read the rest of the proposal.
Benefits to Community
Don’t forget to make your case for a benefit to the organization, not just to yourself. Why would Google and your organization be proud to sponsor this work? How would open source or society as a whole benefit? What cool things would be demonstrated?
Deliverables
Include a brief, clear work breakdown structure with milestones and deadlines. Make sure to label deliverables as optional or required. You may want your plan to start by producing some kind of white paper, or planning the project in traditional Software Engineering style. It’s OK to include thinking time (“investigation”) in your work schedule. Deliverables should include investigation, coding and documentation.
Related Work
You should understand and communicate other people’s work that may be related to your own. Do your research, and make sure you understand how the project you are proposing fits into the target organization. Be sure to explain how the proposed work is different from similar related work.
Biographical Information
Keep your personal info brief. Be sure to communicate personal experiences and skills that might be relevant to the project. Summarize your education, work, and open source experience. List your skills and give evidence of your qualifications. Convince your organization that you can do the work. Any published work, successful open source projects and the like should definitely be mentioned.
Follow the Rules
Most organizations accept only plain text applications. Most organizations have a required application format. Many organizations have application length limits. In general, organizations will throw out your proposal if you fail to conform to these guidelines. If you feel you must have graphical or interactive content associated with your application, put just this content (not a copy of your proposal) on the web and provide an easy-to-type URL. Do not expect reviewers to follow this link.
Submit a Proposal early
Submit your proposal early during the application period so that the organization mentors can review it and ask you questions or request more detail on aspects of your proposal before the final deadline. You can edit the proposal as many times as you wish before the application deadline. You may even want to label the proposal as a draft so it is clear you are looking for feedback before submitting the final proposal.
Remember, thousands of potential GSoC contributors are submitting proposals so it can take organizations a few days or even a week+ to get back to you if they have questions. So the earlier you submit a well written draft proposal, the more time they have to give you feedback on it so you can make it stronger and understand more of what they are looking for.
Follow the instructions from the organizations on the content and format of your proposal.
Remember to submit your final draft before Google’s deadline, regardless of if you have received any feedback or not from the org. If you do not have a proposal submitted in the GSoC webapp by the deadline there will be nothing for the org to look at. There are absolutely no extensions to deadlines in GSoC proposal submissions for anyone, ever.
Outside the Project List
Some organizations allow GSoC contributors to propose work that is not on their official Ideas Page. This can be a great opportunity to get your proposal on the top of the stack. Reviewers tend to get excited about a GSoC contributor that goes beyond a direct response and enthusiastically proposes work that is novel and creative.
However, original proposals are also riskier; their flaws will be much more apparent. Here’s some of the ways that such proposals fail:
Projects without a mentor
Try to make sure that someone in the organization would be willing and competent to work with you.
Projects that better belong with other Summer of Code organizations
Open source organizations try hard to avoid stepping on each other’s turf. Try to find your best fit.
Projects that represent too large a scope
The time flies by quickly. If you have a large project, break it into small, coherent pieces and propose to get the first couple of them done. That way the organization can be confident that you can complete a project in the allotted time and the project isn’t left incomplete indefinitely.
Incoherent proposals
The organization needs to see a clearly contained piece of work. If the organization can’t understand or define the work, the proposal will be thrown out.
Projects that are “inappropriate” for legal or social reasons
If your proposal is near the boundary, make sure you clear it with your target organization in advance.
Boring projects
For the mentor and the organization, half the fun is helping a GSoC contributor do something novel and cool. Infrastructure per se isn’t necessarily boring, but it should be part of a luminous vision.
Stuff that’s already been done to death
Novel work should be novel. Surprise.
Even given this list, there’s plenty of room for cool work. Given the opportunity, you should seriously consider taking advantage and writing a proposal that differentiates you.
General Notes
While there is an official limit of three submitted proposals, it is okay to submit more than one high-quality proposal. If you have several strong possibilities for the same organization, consider submitting several proposals. Organizations will figure out which one they like best. But avoid sending many medium-quality proposals and concentrate on fewer high-quality proposals.
Most organizations are risk averse. It is better for everyone if your project is under-scoped and sure to complete; as opposed to a large-ish project which may not get done. Under-scoping is an annoyance. Incomplete is a disaster.
Integrate and leverage existing open source code in your project. Only propose to write something yourself if you cannot get it any other way.
The “Pencils Down” deadline for your project to be completed will come sooner than you think.
How GSoC Works
Google Summer of Code moves in phases after you are accepted. The first phase is the Community Bonding Period (~3 weeks) in which you get to know your community and get familiar with their code base and work style. The next phase is the initial phase of coding (Phase 1) which is evaluated with a midterm evaluation from your mentor halfway through the Google Summer of Code term. The final phase is your time to complete your project (the final half of the program). There will be a final evaluation at the end of the term; you will also need to submit a URL to your work product.
Evaluations
Evaluations are not as daunting as they may sound. This is an opportunity for you to evaluate your mentor and your mentor to evaluate you, not a quiz on your coding abilities. Some mentors even choose to review their evaluations afterward with the GSoC contributor in order to integrate the feedback into the coding process for the rest of the term. Be honest about your experiences with the program. This helps GSoC improve in future years. Remember, you must complete your evaluation of your mentor at the final phase or you will receive an automatic fail.
Participant Roles
There are four roles in the Google Summer of Code program:
GSoC contributor
This is you! A GSoC contributor is a student or a new contributor to open source. This person could be a university student, a recent graduate, a person switching careers, a developer early in their career, person returning to the workforce, etc. GSoC Contributors come from a variety of academic backgrounds - many are university students or graduates of coding schools or programs, while others are self-taught.
Organization Administrator
Org admins are the “cat herders” for GSoC open source projects. Some org admins also mentor GSoC contributors during GSoC. Org admins are the final authority about matters such as which GSoC contributor projects will be accepted and who will mentor whom. They are also responsible for approving and adjusting any project deadlines requested by the mentor and GSoC contributor. If you’re having difficulties communicating with your mentor or making progress, an org admin can help.
Mentor
Mentors are people from the community who volunteer to work with a GSoC contributor. Mentors provide guidance such as pointers to useful documentation, code reviews, setting milestones for the GSoC contributor, etc. In addition to providing GSoC contributors with feedback and pointers, a mentor acts as an ambassador to help GSoC contributors integrate into their project’s community.
Program Administrator
Program administrators are employees of Google’s Open Source Programs Office who run the program. These folks do a variety of tasks: select the participating open source projects each year, create and analyze the program evaluations, administer the program mailing lists, ensure that participants are paid, respond to inquiries about the program. Program administrators do not select which GSoC contributor proposals are accepted into Google Summer of Code.
Open Source Culture
Abbreviations and Slang
People come up with abbreviations and slang that are meaningful inside the group, but not necessarily to outsiders. Ask questions when you don’t understand a term, a joke or some arcane bit of project lore.
Here are a few useful resources for teasing out meaning from initialisms, acronyms and abbreviations:
Urban Dictionary (http://www.urbandictionary.com)
Webster’s Online Dictionary (http://www.websters-online-dictionary.org/)
The Jargon File (http://www.catb.org/jargon/html/)
Acronym Finder (http://www.acronymfinder.com/)
A to Z word finder (http://www.a2zwordfinder.com/)
Communication Best Practices
One of the best things about GSoC is the group of individuals from diverse cultures and different open source organizations that participate each year. This also means that you cannot make any assumptions about communication. Specifically:
Always read the Program Rules, FAQ and this guide first! One of the best ways to destroy your reputation early is to repeatedly ask questions on the chat channel or the mailing list that are covered in a FAQ or other types of documentation.
Don’t expect instant answers. Remember you are working with volunteers.
Avoid humor when communicating with the entire GSoC community. It does not translate well to large groups and is likely to be misconstrued by someone.
Remember that other peoples’ time is just as valuable as your own.
Like a bullhorn
When you post to the GSoC student list you are essentially using a bullhorn to broadcast your words to 8,500 people across time zones and international boundaries. Use your bullhorn wisely, or it might be ripped from your hands by an unruly and angry mob, or by a responsible moderator.
How to Use IRC
Many projects use IRC for real-time conversations. Often these IRC conversations appear very casual. It is always best to assume formality if you have any doubts about who may be listening or participating in the conversation.
The Fedora Project has a great FAQ on how to use IRC. Read it!
http://fedoraproject.org/wiki/Fedora_Channel_FAQ
Some additional guidelines:
Include your preferred name in your IRC signature information.
Never private-message (pm) someone that you don’t know without first asking if it is OK in the public channel.
Read the topic before asking questions.
Stay on-topic for the channel.
Before asking questions in #gsoc - read the FAQ!
How to Get a Head Start
The last thing you want is for the coding period to start and then realize that you don’t have all the tools you need installed and configured to actually begin work. Don’t let this happen to you! The community bonding period is the perfect time to get these things sorted out.
Start Working with Your Fellow GSoC contributors
GSoC is not only about working with your mentor. There’s this amazing group of outstanding and motivated GSoC contributors too.
GSoC Contributor/Student mailing list
Google has a private mailing list for the GSoC contributors/students. From 2005-2021 GSoC was focused on students hence keeping the student in the list name. The mailing list also has GSoC participants from earlier lists. Use the GSoC contributor/student mailing list as an additional resource. Your questions can be technical or non-technical. Of course, remember not to be a bullhorn and be mindful of the mailing list etiquette. Please don’t “+1” on the mailing list as you are spamming thousands of people and will likely have the message moderated.
They’re just like me!
There are many GSoC contributors who have faced or are facing problems like you. Don’t be scared to ask your questions. This is more true for the GSoC contributors who have been accepted to the same organizations as yours. You can ask them about how they got their dev setup working. Help each other out on the chat channels and mailing lists. Don’t be afraid to ask and don’t be afraid to answer!
Make friends around the world
GSoC is a great opportunity that helps people and communities collaborate across boundaries. Use this opportunity to learn more about diverse technologies and cultures and be respectful of the cultural differences.
Meetup and discussion groups
You can always find GSoC contributors who are excited by the same ideas as yours. Use your GSoC contacts to organize meetups and discussion groups. You can meet up with people who are interested in the same things as you. It’s always good to put a face to the names that you’ve been friends with. Help each other out with coding problems.
Organize Student Chapters
You can even consider starting a local student chapter for your community if you can find enough interested people. It’s a great way of socializing, making and keeping new friends and also spreading word about your community, open source and GSoC.
Review Your Project Plan
Do you have a good project schedule? Have you informed your mentor of any planned absences? Make any project adjustments you may now recognize as necessary based upon getting your dev environment setup and your new understanding of how the project works. With the flexibility in extending your program timeline that is being offered, this is a crucial time to let your mentor know if your plans changed since you first wrote your proposal and now you will have limited availability for X weeks for whatever reason. Communicate with your mentor. They want you to succeed but you have to let them know you have some varying availability during the summer. It’s okay as long as you let them know as soon as you can so you both can work on a reasonable schedule and project milestones together
Time management for contributors
Well, 12 weeks isn’t a lot of time to write all the code and have all the fun that you’re supposed to have during GSoC. Efficient time management goes a long way in helping you make the most of your GSoC experience. Even though Google puts out a timeline for making sure that things do happen on time, you and your mentor should come up with a custom time line that fits in well with your project requirements and also with your plans for the summer.
You and your mentor can decide together (with the organization administrator’s approval) that you wish to extend the project longer than the standard 12 weeks (for medium and large projects) up to 22 weeks. Be sure you have a clear path and expectations on how the work will be divided over this new adjusted timeframe. Maybe there is a full month in the middle where you have finals or are expecting a child and know you won’t be able to fully commit to GSoC during that time, that can be okay as long as you and your mentor have agreed on a plan together.
The following are some suggestions that can help you to manage your time well:
Community Bonding Period
There’s already a complete section in the guide on this. (It is that important.) Use this time to get familiar with your community, setup your development environment and get an early start on the code development. This is time where you’re getting to know your mentor and other GSoC contributors. Chat with them in chat rooms, ask questions and share ideas on projects and get ready to begin the fun ride ahead.
Be upfront about your time commitment
GSoC needs an investment of about 90 hours for small projects, 175 hours for medium size projects and 350 hours for large projects. If you know in advance that you’ll need to take a few days or even weeks of vacation/break during the Summer of Code, you should communicate that with your mentor beforehand and plan to make up for lost days by extending the standard 12 week program or having heavier coding weeks to accommodate the missed time. You and your mentor have the opportunity to add some flexibility into your schedule up to a point. However, you both will need to agree on any planned breaks, an adjusted end date for your project, etc.
Regular meetings with your mentor
You should absolutely, absolutely make sure you’re interacting often with your mentor through mutually agreed upon communication channels. It is extremely important that you and your mentor are on the same page in terms of the project status and plans. Your mentor is your biggest resource and you should make sure that you capitalize on that well.
Have mini-goals for each week
It always helps to set short-term goals that you can discuss with your mentor. Breaking down your project into smaller tasks helps in many ways:
It gets you started!! You have a smaller, well-defined task to work on which is easier to manage.
Mini-goals help create a road map to get to the final output you’re trying to produce.
Smaller goals are less daunting, and completing a small goal gives you the confidence to tackle the next one.
Regular code reviews
Regular code reviews are extremely important for staying on track. Don’t be afraid to ask for them as frequently as you need them. It is much better to ask for a code review after 10 or 20 lines instead of hundreds of lines. If your mentor tells you that you are going about something the wrong way, you don’t want to find out after writing a ton of useless code.
Maintain a log to keep track of your progress
Keeping a log of your progress is a great way to monitor progress both for yourself, your mentor and anyone else. It also turns out to be valuable in cases when you need to go reconsider a decision and figure out why you made that choice in the first place. Blogging is a good way to achieve this, since you may get good advice in the way of comments from people that you normally wouldn’t communicate with, and it gives you a bit of limelight as well.
Handling the time-zone differences
It’s very likely that your mentor is in a different time zone than you are. Be sure that you take this into account while you’re preparing your plan. Time zones should be included for any meeting times, and UTC is often the best time zone to use, since it is not affected by Daylight Savings Time.
Be prepared for the unexpected
Things usually don’t go the way you plan them. Make sure you have room for the unplanned changes. It’s always best to keep aside some buffer time that you can use in case you do digress from your original plan and save yourself from considerable pain and panic attacks.
Of course, do remember that GSoC is not just all coding and working. It’s about having fun too! If you manage your time well, you will have a great Summer of Code, meet interesting people and have lots of fun.
Strategies for getting your code committed
A key goal of GSoC is to produce useful code that is integrated into the code base of your community. Every organization has different standards for code submissions, but there are some general rules you can follow that will help make your code easier to integrate:
Follow the documentation guidelines. Some organizations have a policy that code must have some documentation before it can be committed.
Make sure the tests pass! You have tests, right?
Include lots of useful comments in your code. Comments make people happy.
Tests are sensitive to the versions of software, operating system and libraries you are using. It is a good idea to run your tests on a few of the most commonly used versions of libraries or prerequisites, if possible.
Document exactly what kind of environment you wrote the code in, and whether certain things may be dependent on your operating system or platform. For example: “This patch was tested on Linux x86 and OS X Intel, but may have some issues with FreeBSD”
Read through recent commits to the repository that you would like your code to be in. You will often learn about something relevant to your code, such as a macro that makes your life easier or a special trick for avoiding bugs.
Commit often. You can always maintain a local branch of the code to which you keep committing regularly. This keeps you from losing work; it also gives you something concrete to show your mentor and get feedback on.
Take the feedback on your code positively. Appreciate the comments and suggestions you receive and use them for your next commit. It certainly helps you write better code and grow as a developer.
There’s something really satisfying and fulfilling about getting your code accepted and seeing it used by many others. Getting your code submitted is your first step towards achieving that accomplishment! More importantly, it helps you in honing your skills as a great developer and contributor.
Pro Tip: You can also ask other GSoC contributors to review your code for you and give you feedback. Use other students in your community and the GSoC program as a resource.
Proposal Example 1
“Database Abstractions” By Kanika Vats, Systers, 2009
Abstract
Systers use GNU mailing list manager Mailman2 which currently uses Python pickle files to store its data. Systers moderators have customized it to make use of PostgreSQL database. They make use of raw SQL statements and python db-api which makes the code :
Dependent on the existing database
Reduces the efficiency and maintainability
The project idea aims at making the code :
Independent of the database by making the use of python classes and objects to interact with the database rather than direct SQL statements.
This will be achieved with the help of an ORM (Object Relational Mapper). Storm will be our choice of ORM.
Also, Systers aim at bringing this feature upstream and incorporating this feature in the yet to be released version - Mailman3 (which will switch to use a database) - so that the open source world can benefit themselves with the addition of this feature.
Thus, mapping existing schemas of the Systers database to an object oriented paradigm and determination and incorporation of necessary modifications in the database needs to be done so that it fits cleanly and nicely into Mailman3’s Architecture.
Proposal Timeline
Before April 20:
To familiarize myself completely with Mailman2’s functionality and architecture.
Study of the customized files of Systers Mailman available in the Launchpad Baazar version control.
To familiarize myself with Storm(ORM that we will be using)
April 20 – May 23 (Before the official coding time):
To do self coding with Storm to improve my further understanding and ease of use with this ORM and database(PostgreSQL)
During this period I will remain in constant touch with my mentor and the Mailman community. I will remain active on IRC and Mailing lists to discuss and finalize on the modifications (if any) that needs to be on existing schemas and design of new schemas (if needed to fit cleanly with Mailman3’s Architecture)
Thus with the help of my mentor I will become absolutely clear about my future goals,the final database implementations that need to be done as well as the approach that I will follow to map the schemas to the Object Oriented Paradigm.
May 23 – June 18 (Official coding period starts):
Define all the required Relations(Tables) in my local database using STORM.
Define all the corresponding Python Classes and Objects that will store,modify and retrieve data in database.
Define all the interactions that Systers perform with their database (virtualize or stimulate all interactions) in STORM that will deal with my local database.
This will help in testing of the proper working of the entire basic code changes that we will later on incorporate in Systers Source code.
June 18 – July 5:
Bringing about the decided changes in the Relational Schemas of Systers database.
Replacing parts of the above code in their respective places in the Systers source code. (This should not take much time as most of the functionality has been implemented in the previous step).
Testing the overall working of each and every module of the modified source code with the help of Python Test Suites.
JULY 6th MID TERM EVALUATION
July 6 – July 15:
- Making further changes in the code to improve the Functionality, Exception handling, Bug Removal.
July 15 – July 25:
To be in constant touch with the Mailman3’s developers and to let them know about our progress.
Most of the time will be consumed for rigorous testing and bug fixes.
July 25 – July 31:
- For Documentation
A buffer of two weeks has been kept for any unpredictable delay.
Proposal Example 2
“Reactome-Wikipathways Round-trip Format Converter” by Leontius Adhika Pradhana, GenMAPP, 2010
Problem description
Reactome is a “free, online, open-source, curated pathway database encompassing many areas of human biology”. Each pathway in Reactome is manually curated – peer-reviewed and cross-referenced with other database – and thus has great reliability. Another pathway database website WikiPathways, by contrast, lives on the “wiki spirit” allowing anyone to edit and annotate pathways in the website. This makes WikiPathways an ideal venue for staging new pathways to be included in the official Reactome database, as well as a place for the community to review and make changes to pathways which may end up as an official amendment in Reactome.
However, the two websites use markedly different data structure to store their pathways: WikiPathways uses GenMAPP Pathway Markup Language, a vector graphics format similar to SVG; Reactome internally stores the pathways in a proprietary semantic database schema. The formats differ not only in their presentation but also in their focus of data stored, making information exchange difficult.
Recent development of Reactome introduced a new proprietary graphical XML format akin to GPML. This XML format adheres to SBGN specification which semantically defines symbols representing biological systems. This project will provide the means to convert to and from GPML and the new Reactome XML format.
Implementation plan
The project consists of three components:
GPML to Reactome XML layout converter
Unlike the Reactome XML format, GPML mainly describes the graphical representation of pathways and does not contain semantics of the reactions. To produce Reactome XML, therefore, the converter must employ certain heuristics to infer semantic relations from graphical representation and eliminate ambiguities. The heuristics will follow SBGN as close as possible while still retaining compatibility on other formatting conventions.
Reactome XML layout to GPML converter
The Reactome XML layout contains further pathways data that are not viewable in GPML. Therefore, the resulting GPML after conversion will contain additional comments containing the Reactome data or at least their identifiers, so that when a back-conversion (from the GPML to Reactome XML) occurs, data will be preserved.
During the conversion, SBGN semantics will be employed to provide unambiguous back-conversion to Reactome XML later when necessary. Some additional shapes might need to be implemented in GPML, or alternatively comments can be written to differentiate SBGN symbols that do not have corresponding graphical representation in GPML.
During the development of this converter a schema for Reactome XML will also be made so that converted test files can be easily validated.
Automatic update mechanism between WikiPathways and Reactome
A separate script will be made that periodically pulls updates from WikiPathways and convert it to Reactome XML layout. The script can be set to automatically update the pathways in Reactome if correct credentials are provided. This will mainly be done for pathways that are already tagged to be high quality.
The script will also pull updates from Reactome and push new pathways to WikiPathways. Only Reactome pathways that have XML layout will be pushed to WikiPathways.
Deliverables
an XML schema to validate the new Reactome XML format;
a GPML to Reactome XML layout converter and Reactome XML layout to GPML converter, which will be available both as command line tool and a library that can be integrated with WikiPathways infrastructure;
a system using the above converter, integrated to WikiPathways, that will periodically check for updates on both WikiPathways and Reactome and update the websites accordingly;
proper documentation and tests for the above-mentioned components.
Timeline
This week-by-week timeline provides a rough guideline of how the project will be done.
3 – 16 May
Familiarize with the code and the community, the version control system, the documentation and test system used, and the new Reactome version.
17 – 30 May
Write the Reactome XML layout schema and the command line Reactome XML to GPML converter, keeping in mind that the internals are to be used subsequently as a library.
31 May – 6 June
Test and document existing code more thoroughly.
7 – 20 June
Determine algorithms used to convert GPML graphical representations to Reactome XML. Then, write the command line GPML to Reactome converter, keeping in mind that the internals are to be used subsequently as a library.
21 – 27 June
Test and document the GPML to Reactome XML converter and the heuristic algorithm more thoroughly.
28 June – 11 July
Ensure that round-trip conversion works flawlessly (i.e. no data is lost when converting GPML to Reactome XML to GPML again, and vice versa). Also test and document round-trip conversions.
12 – 25 July
Integrate the converters to WikiPathways. A system that periodically check for updates on both WikiPathways and Reactome and update the websites accordingly is written.
26 July – 1 August
Test and document the periodic push/pull mechanism more thoroughly.
2 – 16 August
Further refine tests and documentation for the whole project.
Glossary
https://google.github.io/gsocguides/student/glossary.html#waterfall-model