Why Should I Apply?

So you've found out about this Google Summer of Code thing that requires you to submit a lengthy proposal and write a lot of code. Why bother about it at all? Well, here are some reasons why you should start writing your proposal today!

The $$$, the fame and the t-shirt
One very tangible and obvious advantage of participating in GSoC is all the cash that you make while working with amazing people on a great project. Being a successful GSoC student is in fact a prestigious achievement. It's another way to make your resume more impressive. And of course you get a really cool t-shirt too!

An absolutely amazing learning experience
GSoC is a place where you don't just get to apply your your skills but also get to acquire a bunch of new ones. And the learning is not just limited to technical knowledge. GSoC introduces you to a new paradigm about building code collaboratively. Not only that, GSoC is a platform which lets you build on your current skills and hone them. There is a project for all skill levels at GSoC!

"GSoC is one of the best professional experience a student can have during his college years. I've participated twice already, but now I'm starting to regret I didn't do this every year! Awesome! Thank you Google! "
Evelina Vrabie, Sunlight Foundation, GSoc Student 2010

"This is a big opportunity for all the students like us to use the things that we are learning in colleges in a practical manner. Thanks Google and all the mentoring organization for allocating your valuable time."
Kasun (Lakpriya) Hettige, Apache Software Foundation (ASF), GSoC Student 2010

Sense of achievement
There is something very fulfilling about getting your first patch committed upstream in some application that will be used by thousands of other folks all across the globe.

"I just want to say...it feels *awesome* when your first patch goes in.  Really awesome. "
Mike Conley, Review Board, GSoC Student 2010

Hone your developer skills.
Students who are already active developers can apply themselves to a specific project. You'll get direct feedback from your mentor.

"At this time one of the most memorable incident happened in my life, where my mentor proposed me as a committer, and my ambition to become an Apache committer finally became true. "
S. Suhothayan, ASF, GSoC Student 2010

Getting involved and building your network
During the 12 weeks of writing good code, you interact and share ideas with some great people. At the end of it, you've made some great friends from all over the world with whom you can discuss fun projects, get feedback on your code, and just about anything. 

"Exciting and challenging. I met kind, knowledgeable and smart people all gathered in a single place, united, working for a single goal. "
José Luis Vergara Toloza, KDE, GSoC Student 2010

"Summer of Code is about much more than just code. The sheer fun of integrating with the open-source community and your mentoring organization can in fact outweigh the gratification of actual coding. "
Kamran Khan, Ubuntu, GSoC Student 2010

Your spring-board to the open source world
GSoC is a great place to get you jump started and up to speed on the basics of the open source community. This paves your way forward for making big contributions. It's a great way to make your first entrance on the open source stage and get noticed.

"GSoC2010 was my first real foray into the Open Source World -- I had been teetering at just the edge of actual contribution for a few years, having tried out WordPress, etc. but had never actually ever submitted a patch, or released a project. "
Kunal Bhalla, WordPress, GSoC Student 2010

For the love of code
If you enjoy coding and feel passionate about writing good quality code and building great software, GSoC is THE place for you give way to your passion. After all, what better way is there to celebrate your love for the code by participating in a summer of code.

Am I good enough?

Do you have some programming experience at the university level? Then, yes, you are good enough! No, you don't need to be a Computer Science or IT major. Students from all subject areas are successful GSoC students. Have work experience programming but spend your time studying philosophy full-time? Yes, you are good enough to be a GSoC student!

"Although at first I was a little inexperienced in the world of mobile applications and a bit overwhelmed by the challenge, I can positively say that four months later I've gradually overcome all the obstacles. I had a great mentor, that's for sure!"
Evelina Vrabie, Romania, Android Project - GSoC 2010

Every project has a different criteria for selecting students and subsequently different skill level requirements. If you meet the below list of general skills you are likely to find a GSoC project to which you can feel comfortable applying:

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 student.

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 think you all ready know everything about everything in the world of programming for open source programs?  Then you probably aren't good enough for GSoC!

The technical stuff

You can install and configure software packages on your own
If you don't know how to download and install packages on your own, you'll need to figure that out, stat.

You have access to a functioning computer 40 hours a week
If your computer regularly dies, or you don't have dedicated access to a computer you'll need to figure that out before you start your project. Also, GSoC is a full-time job. Don't expect an hour or two a day in an internet cafe to be enough!

You've got experience using the programming language and operating system of the project
Depending on the project, the skills necessary will range from beginner to expert, but you do need some experience.  One of the great things about GSoC is that there is a large variety of organizations and projects to chose from. Chances are very good that you can find a project that meets you at your level.  Even if you are a beginner! If the project primarily uses Linux for development and distribution, then you need to be comfortable with basic Linux usage. Sometimes, you'll see projects looking to expand onto other platforms, in which case you may be able to bring in new expertise.

Every project has additional characteristics that they look for when selecting students and projects - however, if you meet the above basic criteria - chances are good that there are GSoC projects and organizations to which you can feel comfortable applying.

Pro Tip: Don't be afraid to apply to projects where you only meet 51% of the listed requirements.  Include a section on how you'll compensate for or learn the missing skills - and demonstrate during the application process that you are working on acquiring those new skills.

Choosing an Organization

You now have a pretty good sense of what GSoC is all about. You've got the time available to commit to a summer project (even if it's not summer where you live). And you're pretty sure you've got what it takes to contribute to an open source organization. Now, where do you start?  How do you choose a project/organization? The path to finding the right project or organization starts with knowing thyself...

"You can do much more than what your university rank says. [The] World is full of opportunities. Google Summer of Code is one such a opportunity to find an answer for, "Who am I?" "
Kapila Bogahapitiy, Network Time Protocol Project, GSoc Student 2009, 2010

Who Am I?

The very first requirement for a successful GSoC experience is finding a project/organization that interests you. Take a few minutes to consider the following questions. You can use the answers to these questions to search and filter through the organizations participating in GSoC.

Who Are They?

After the GSoC program is announced each year, a list of accepted organizations is published on the GSoC web site. Compile a list of organizations based on your answers above. The projects are also tagged with categories of programming language, platforms, topics and applications. Use the tags to filter organizations based on your skills and interests.

For each organization, take some time to learn more about what they do (i.e., Google them!). The organization's mission, it's size and range of applications may all influence your interest in working with them. Realize that through GSoC you will be joining an open source community. Ideally, you'll find an organization that you are enthusiastic to be a part of. 

Making First Contact

When you walk into a party what do you do?

Interacting with an open source group is sort of like walking in on a party where it seems like everyone else knows each other. People are discussing topics you may be interested in, or sometimes they could be discussing topics you neither know or care about.

If you're the type of person that would walk right up and introduce yourself at a party, then the best approach to getting started is to do what you'd do in real life. Contact the project, introduce yourself and ask questions related to your project.

However, if you're more likely to hang back and watch people for a while, spend some time observing community interactions before you jump in. You can also try to contact an organization admin for guidance, or with help introducing you to a community. If in doubt, have a look at the organization's ideas page for hints on where to go for help.

How to observe community interactions

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

No matter what, don't wait until you apply to initiate contact! Engage with multiple communities once the participating organizations are chosen to get a feel for how different groups work.

Finding the Right Project

Each organization will have a project Ideas Page linked to from the official Google list of accepted organizations. Browse the list of project ideas for each of the organizations for which you are interested. The ideas should give you a clear sense of the range and depth of projects being targeted and the expectations in terms of prior experience and programming skills. In addition to the list of project ideas, many organizations encourage original ideas proposed by students.


There's a big sea of projects out there for GSoC. Start by compiling a list of potential project ideas that catch your interest. For each idea, take some time to carefully consider what is being proposed, how its scope might be better defined, and how it might fit in with the larger picture.  

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 web sites) 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 summer 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 guy: Cut and pasting an idea from the organization page and turning that in as your project's description is a 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

This is a competitive program, each year Google turns down many more students than it funds. While pre-proposal activities are key to improving your chances of success, a poorly-written proposal is an easy way to fail. There is much you can do to ensure that your project proposal catches the attention of organization reviewers in a positive way.

The Basics

First and foremost, make sure you meet Google’s formal requirements for participation in Summer of Code. 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, and counting credit-hours of University instruction. GSoC should be treated as a full-time job.  If you have more than a few hours a week of extra commitments, you probably should skip GSoC; it is unlikely that you will be successful. In any case, be completely clear about outside time commitments as part of your proposal. Do not surprise an organization with your time commitments later on.

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 Summer. It is not necessary 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 email addresses, websites, IRC nick, postal address and telephone number. Also provide full contact information for a friend or relative that the organization can contact to find you in case of emergency.

Your title should be short, clear and interesting. The job of the title is to convince the reviewer to read your 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?

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 your 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.

Outside the Project List 

Some organizations allow students 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 student 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 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 customer.

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 they will get at least one good piece of work out of you.

Incoherent proposals
The organization needs to see a clearly delimited, 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 student 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 on the number of submitted proposals, you are encouraged to submit as many high-quality proposals as possible. If you have several strong possibilities for the same organization, consider submitting several proposals. Organizations will figure out which one they like best. 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 complete is usually sometime in mid-August. This will come sooner than you think.

Being Turned Down

You've done your homework, found an exciting project, and you've written the best proposal you could. And you didn't get into GSoC.

Don't despair! The beauty of engaging in the GSoC process is that you're learning about groups of people that extend beyond just GSoC. Making contact with potential mentors and a software community sets the stage for future opportunities for participating in community-developed open source software projects.

What to do now?

First don't take it personally. Just like when you apply for a job, there are reasons why you might not get in, some that have nothing to do with you. Mentors may not be available, the organization may not have enough space for your project or it may just not be the right time for your proposal. 

So, where to go from here? There are several strategies you can consider to go forward positively. 

Ask for feedback on your proposal
Just like in job interviews, gathering information about why your proposal wasn't accepted is a great thing to do to improve your next application. Some example questions to politely ask if your proposal is turned down include: 

Following up and getting more information about what you might be able to do differently next time is a great pathway to success.

Approach an organization about doing the project anyway
For those students with the drive to forge ahead without GSoC financial support, you may find that a community really is interested in your project anyway. Don't be afraid to approach your community, GSoC org admin or mentors you communicated with about future contribution.

Perhaps you can work on a smaller portion of your idea over a longer period of time on your own, or find another project better suited.

Some successful students have even found business sponsorship of their work later on.

"This story is about how after about one year and half I became a Linux Kernel Maintainer [of] the Bluetooth Subsystem. On the 2009's GSoC, I worked in important new feature in the kernel side of the Bluetooth stack. The work was too big and I wasn't able to finish it, then after some months a big company hired the company I worked with to have me finish that work. [Now] all work is merged in the Linux tree."
Gustavo Padovan, BlueZ, GSoC Studnet 2009, 2010 

Stay connected
If you've already invested time and energy getting to know a community, stay involved! Subscribe to relevant mailing lists, participate in IRC or fix small bugs that you have time for.

There are also many non-code ways you can contribute to software. If you're interested in documentation, graphic design, release testing, public relations or marketing, most projects welcome contributions in these areas. Taking on small non-code projects can be a great way to stay connected and build a reputation in a community.

Try a new organization
Maybe that project wasn't the right fit! Part of selecting a project is selecting a community that works with you. (Also see the chapter on "What does community mean")

"I had a look and approached many organizations, and finally decided to hook up with Sakai Foundation. The mentors and the people I interacted with from the community really encouraged me and I felt very comfortable with their coding practices [and] the programming languages."
Ashish Mittal, Sakai Foundation, GSoC Student 2010

Keep trying
Just keep trying. The next proposal just might be accepted...

"*Never* give up. It took me 3 years and 12 proposals to finally get into the program. If none of your proposals gets accepted, sit back and relax. You have a whole year ahead to improve your role with the open-source community by writing more code."
Kamran Khan, Ubuntu, GSoC Student 2010

How GSoC Works

Google Summer of Code moves in phases after you are accepted. The first phase is the Community Bonding Period in which you get to know your community and get familiar with their code base and work style. The Google Summer of Code administrators take this time to get payment cards printed and then make up packages to ship to you. The next phase is the initial phase of coding which is evaluated with a midterm evaluation a little more than halfway through the Google Summer of Code term. The final phase is your time to complete your project. There will be a second evaluation at the end of the term; you will also need to submit a sample of the code you produced. This is posted on code.google.com and associated with your mentoring organization.


Introductory Package
Your introductory package will include some goodies for you as well as your payment card for the year. You will need to activate the card in order to get the money from it throughout the term. The packages are individually shipped around the world and should arrive right around the start of coding for the term.

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 student 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.

Payment is in three pieces, comprising 10% of the overall stipend, 45% of the stipend, and 45% of the stipend. The first payment of approximately 10% of the overall stipend is a "welcome to the program" payment that comes when your payment card is first activated. The second and final payments are sent to your card after Google has received a notification that you have passed your evaluation for that cycle. All of these payments take a few business days to become active on your card.

T-shirt and Certificate
You get a t-shirt and a certificate of completion at the end of the year. The program administrators again have to ship each individual package to your house, so please be patient. Mail systems are particularly hard to navigate if you live in a place like India or Brazil. Most of these packages arrive about 1 month after the end of coding.

The rest of your experience with the program will be determined by your interactions with the community within your mentoring organization. Most students consider the interactions with their mentor and the rest of the open source community they're involved with to be the most important part of the Google Summer of Code experience.

Participant Roles

There are four roles in the Google Summer of Code program:

This is you! A student participant in GSoC is typically a college or university student; the only academic requirement is that the accepted applicants be enrolled in an accredited academic institution. Students must be at least 18 years of age to participate. Students come from a variety of academic backgrounds, and though most students are enrolled in a Computer Science program there is no requirement that they be studying CS. Past students have come from disciplines as varied as Ecology, Medicine, and Music.

Organization Administrator 
Org admins are the "cat herders" for GSoC open source projects. Some org admins also mentor students during GSoC. Org admins are the final authority about matters such as which student projects will be accepted and who will mentor whom. If you're having difficulties communicating with your mentor or making progress, an org admin can help.

Mentors are people from the community who volunteer to work with a student. Mentors provide guidance such as pointers to useful documentation, code reviews, etc. In addition to providing students with feedback and pointers, a mentor acts as an ambassador to help student 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, and send out the all-important program t-shirt. Program administrators do not select which student proposals are accepted into Google Summer of Code.


It is a goal of Google Summer of Code that the student participants stick around long after the program has ended and continue contributing to their project communities. Great mentors continue working with their students and encourage them to do so. In the end, mentors and students take a well-deserved break before the GSoC cycle starts again.

What does community mean?

The word "community" gets thrown around a lot in open source. So what does it mean?

People involved with open source community have differing political, social, economic and ethnic backgrounds. They range from elementary school students to the elderly. They work across timezones, languages, and cultures.

Some developers may work on only a small part of the project codebase, while others know every line from memory. Communities also include people who don't work on the source code directly, such as graphic designers or testers.

When talking about community, it helps to focus in on political and social structure. The project participants you talk to may or may not formally represent the project. Assume, unless otherwise stated, that people represent and speak only for themselves when you interact with them. However, identifying the leaders and the project structure can help you to better interact with all members of the project team.

Community leadership structure

Much of the authority in a project rests with those people who control the community code. At least, it starts there. Actual organization varies widely, but there are some common structures that may help you find your bearings. 

Benevolent dictator
Many projects start with a single developer. As time goes on, this person, often called a "Benevolent Dictator" maintains control of most or all commits to the core code, taking patches or branch pushes as they see fit. As more contributors are attracted to the project, the Benevolent Dictator may not do so much dictating, but is often guide for new folks. When there's conflict, the Benevolent Dictator usually makes the final call.

Many committers, rough consensus
Some projects allow almost anyone to change their codebase. These groups are likely to give commit access to GSoC students as part of a project. When deciding which features to work on or what code is committed to the master code repo, decisions may be made by the group or left to a few trusted individuals. When there's conflict, majority approval may be requested before further action is taken.

Decisions are often made based on who has working code, rather than on a theoretical basis. Groups may not formally document how they make decisions. In this case, a little time spent with the group can help you learn the culture and how to work together. If you end up working with a group like this, your mentor will help you acclimate!

Formal organization
As groups grow in size, some kind of organization becomes necessary. The type of formal organization varies widely across social, cultural and political boundaries.  Some ways of organizing include:

These groups can have documented processes for assuming leadership roles, and may put more effort into non-code activity. Generally speaking, formal organizations have governing documents, and a clearly documented leadership group that changes from time to time.

Community is people

Apart from project leaders, open source projects tend to be full of independent, capable people who like to learn. Long-term collaboration tends to turn strangers into friends. Part of what people enjoy about open source development is that they have the opportunity to choose their colleagues. Developers often participate for fun, relaxation and friendship.

When you're talking to a software community, realize that you're really just talking to people, albeit some of the most interesting people who create software. Enjoy the experience and be a good neighbor, and you'll almost always fit right in.

Open Source Culture

When you encounter an open source group for the first time, it may be a bewildering experience. Whether posting to a mailing list for the first time, blogging about the project you're taking on or hanging out on an IRC channel - the way people interact, and what they expect from each other is pretty different than in classroom or with friends and family.

Openness and Sharing

Open source communication can vary a lot. A core value held in common is that sharing code is good. Regardless of license, language or indentation style, open source developers create, share and modify source code together.

Working on code together means a lot of things: transparency, directness and cooperation are words that are often mentioned by developers when describing the process. It can involve bug reports, code refactoring, implementing new features, documentation, project management and advocacy.

Amazingly, the ways in which people actually share code are as varied as the individuals involved. Even if you have previous experience with other open source projects, keep in mind that you still need to take the time to learn how the new open source project works, and acquaint yourself with their particular brand of sharing.

One aspect of "open culture" is that people are informal. People address each other by first name. They tend to speak directly to one another, regardless of social status or formal title. Disagreements about code, whether as profound as which algorithm is most appropriate, or as seemingly mundane as how many spaces are used for indentation, are aired in public. This process is very intimidating to newcomers, who might be concerned about having their words immortalized on the Internet, and worse, saying something wrong or embarrassing. The only way to get over this fear is to practice and participate publicly.

Although "open culture" is generally informal, it is important to remember that you still need to mind your manners when participating in conversations. 

Remote Communication

Many projects involve individuals who are working not only in different cities, countries and continents, but collaborating across major cultural and language differences. And rather than having procedures or policies on how to interact with one another handed down from HR departments or other authorities, communication practices evolve between individuals over time.

Because there are few rules around working together on open source projects, there is a lot of freedom to share directly with one another. This freedom is at the core of what attracts many people to open source software. Multi-cultural projects offer an incredible opportunity to share knowledge between individuals directly. With sharing, however, comes a responsibility to inform new participants about expectations for communication and ways to solve misunderstandings to the benefit of all.

Be mindful of cultural assumptions about race, gender, sexual orientation and disability. People often make assumptions, have stereotypes or are biased in ways that no one can control. The best practice is to assume that people don't mean any harm, and when they're told respectfully that they've offended or hurt someone, that they'll stop whatever it is that they are doing that is harmful.

All that tolerant rhetoric aside, it is never productive for an open source project to allow individuals who consistently try to cause harm to others to do so. If you are causing undue problems don't be surprised if you are asked to discontinue your participation regardless of your contributions. It's often better for an open source project to ask someone to leave, than to allow them to harm others and in turn, cause other productive members of your team to depart.

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:

Volunteerism and Gift Economies

Donated time are the life blood of open source projects. Many individuals contribute their time and energy without any expectation of compensation or even a simple "thank you" in return.

Contributions to projects are often self-directed, with developers having a personal itch to scratch in the form of a new feature, by correcting a bug that they've encountered or by implementing something from a TODO list. Projects operating in this way may seem chaotic if you are only familiar with top-down management - where teachers, professors or bosses tell you what to do and when. Of course, some projects do have clearly defined project management, with milestones and tasks meted out carefully.

Because many (or in some cases all) contributors are volunteering, methods of coercion available to businesses are not available. The best way to collaborate is to behave in a way that encourages others, and ultimately, makes people want to contribute. Some easy ways to encourage volunteerism include:

Consider treating every patch like it is a gift. Being grateful is good for both the giver and the receiver, and invigorates the cycle of virtuous giving.

Overall, your goal is to help create and maintain an atmosphere around contribution that is enjoyable. What that means will vary significantly depending on the project, but certainly the above points apply to any project. 

Communication Best Practice  

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:

How to Use a Mailing List

Every community uses mailing lists differently. It is extremely important that you spend some time understanding how to participate in a way that is acceptable to the community. Read the mailing list archives, observe for awhile first and be sure to inquire about and read any codes of conduct or guidelines before you post.

Some specific guidelines that should apply across communities:

Like a bullhorn 

When you post to the GSoC student list you are essentially using a bullhorn to broadcast your words to 3,000 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!


Some additional guidelines:

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. 

Get Your Development Environment in Order 

Each project has a unique set of tools and packages required to work with developers. These often include:

Some organizations require testing on multiple operating systems and/or platforms. Make sure you know what is expected of you as early as possible. Read the available development documentation and contact your mentor to figure out exactly what tools you need to succeed. Also learn the the bug-reporting process that your organization uses and also understand the the project's release management strategy.


Once you get your development environment setup start practicing! This includes getting familiar with the coding standards, codebase, and testing and documentation policies of the open source project community. Do a few practice commits and work on understanding how source control works within your project. Brush up on any new skills and start asking questions.

Do Some Background Research

Look through the projects bug database and read through the user list to understand your end users. Peruse the mailing list archives and go through the project's existing documentation. 

Start Interacting

Take advantage of the community bonding period to connect with your mentor, and other students in the program. Set up a blog, get involved on relevant forums and mailing lists and in general, start interacting with the development community. Make sure you have what you need to succeed, and if you don't, ask your mentor for help.

Start Working with Your Fellow Students 

GSoC is not only about working with your mentor. There's this amazing group of outstanding and motivated students too. 

Student mailing list
Google has a private mailing list for the GSoC students. Go ahead and introduce yourself on the student mailing list. Talk about your project ideas, get feedback on your proposal. The mailing list also has GSoC participants from earlier lists. Use the 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.  

They're just like me!
There are many students who have faced or are facing the problems like you. Don't be scared to ask your questions. This is more true for the students 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 irc 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 students 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. It's always good to put a face on 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.

Working With Your Mentor

Once your project is accepted you are assigned a primary mentor and potentially secondary mentors as well. Consistent access to mentors is one of the most valuable parts of the GSoC program. Your mentor is going to work with you throughout the GSoC program to help you be successful, but you also need to make sure you are contributing to and helping to manage your relationship with your mentor.

Community Bonding Period

The community bonding period is when you work out further details of your project plan, schedule regular upcoming meetings with your mentor, get your development environment set up and start to engage with the project's open source community. This is the time to work with your mentor on setting expectations for your interactions and how your progress is measured during the GSoC program. Hopefully, you have already participated in many discussions with your mentor, clarifying the project and expectations during the application period, but now is the time to finalize your plans.

Staying on Track

Ideally, you have already worked with your mentor to layout a clear schedule for regular meetings, reports, code check-ins and any planned time off. If you haven't, do this now!

Your mentors are busy people too. They are juggling many tasks and GSoC is one more added to their load. If you rely solely on your mentor to keep track of and enforce the schedule of work, your project is almost guaranteed to fail. Be proactive in keeping the schedule you've agreed to and proposing modifications before deadlines pass.

Be Respectful of Your Mentor's Time

Your mentor is volunteering her time to help you with your GSoC project. Regularly missing scheduled meetings without prior notice and failing to come prepared to meetings is likely to cause your mentor to not want to continue helping you with your project. Remember your mentor is your most valuable resource to help you complete your project successfully, treat them accordingly.

Using Your Mentor

During the coding period, you should continue to make full use of your mentor. As you implement each phase of your project plan, ask your mentor for feedback on the code as you go. Avoid working for two weeks on a chunk of code that is headed in the wrong direction.

Never be afraid to ask questions, but remember you are going to be more successful in receiving a good answer if you try to be specific and do a bit of background investigation first. Take a look at logs and try to think through the error or problem before asking for help. Equally important is to not wait until you are significantly behind in your project to ask for help.

Asking For and Receiving Feedback

Hearing criticism can be hard. It can be even harder to not respond defensively. Asking for and receiving constructive criticism about your project from your mentor, the larger open source project community and your peers is an invaluable exercise to help you write the best code possible.

How do I ask for feedback?
During the community bonding period you and your mentor should have established a schedule for regular communication about your project progress. But what if you want additional feedback or maybe you aren't getting a very detailed response from your mentor. How do you go about asking for additional critique? A general "how am I doing" is going to probably get you a general "you are doing fine" response back. Instead, do your best to ask specific questions about specific areas.

My mentor is wrong! My project is going great! What do I do?
First, take a deep breathe. OK, now take another. Chances are your mentor is not wrong and you need to listen to their advice. This is a great opportunity to start asking questions. Try not to be defensive but rather, "I really don't understand what you mean, would you please explain?". Remember that the open culture surrounding most open source projects encourages and thrives on discourse. Don't view the feedback as negative criticism, but rather an opportunity to explore how to do something different and make your project better. Do your best to listen, learn and incorporate feedback into how you work. 

Dealing with Problems

One of the best things you can do when working to solve real or perceived problems with your mentor relationship is to stop and remember that your mentor(s) is a volunteer and has non-GSoC responsibilities. 

Where did my mentor go? 
So you haven't heard from your mentor in a while, what do you do? First, did your mentor miss a scheduled meeting or did he just not respond immediately on IRC or to an email?  

If you didn't get an immediate response outside of scheduled meeting times either on IRC or email, be patient. 

If your mentor missed a meeting, then a gentle email along the lines of "did I mix up our meeting time" to your mentor is a great idea. Chances are you'll hear back shortly and things will continue on as planned. If you don't hear back, then try contacting your secondary mentor and if there is still no response, then contact your org admin.

Why is my mentor so mean?
Remember that everyone has different communication styles and you might both be communicating in a second language. Providing project critique is part of a mentor's job. That being said, if you feel like your mentor is being unduly harsh and it is effecting your project success the best approach is to talk with your mentor about his communication style in a non-confrontational manner. If you still feel like your mentor is being unduly harsh -- after your conversation -- talk to your org admin.

Why is my mentor so friendly? 
Again, this could be a disconnect based on different communication techniques within different cultures. Make sure you let your mentor know what about their style is making you uncomfortable. If things don't change for the better, contact your org admin. 

Time management for students

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.

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 manual 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 students. Chat with them on IRC, ask questions and share ideas on projects and get ready to begin the fun ride ahead.

Be upfront about your time commitment
GSoC is a job and needs an investment of about 40 hours a week. If you know in advance that you'll need to take a couple of days during the summer of code, you should communicate that with your mentor beforehand and plan to make up for lost days.

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 in smaller tasks helps in many ways:

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.


Evaluations occur twice: midterm and final. They are your opportunity to evaluate your mentor and your mentoring organization's performance. This is also your mentor's opportunity to evaluate you.  

The pass or fail decision from an evaluation should not come as a surprise. You and your mentor will already be communicating, and you should be discussing the quality of your code, your participation in the community and your progress on your project to that point. If you aren't getting this feedback, ask for it.

How Evaluations Work

Evaluations are a survey that both you and your mentor fill in during the evaluation period. Google publishes the evaluation questions for both students and mentors in advance.  

Evaluations are administered via Melange, the webapp you used to submit your project proposal at the start of the term. Evaluations will take about an hour to complete. The questions focus on the scope of your project, the quality of your interactions with your mentor and your community. You, your mentor and org admins will receive an email after the evaluation window closes that tells you whether you've passed.

Your evaluations are only visible to your mentoring org admins. Program administrators from Google have access to evaluation data. In some cases, Google's program administrators may need to share some details of evaluations with you and your mentor. This may happen, for example, when evaluations indicate a payment should not be made. If this happens, everyone is notified in advance.

If you or your mentor do not submit an evaluation, you fail and will be removed from the program. Similarly, failing a midterm or final evaluation means you are immediately removed from the GSoC program.

Final Evaluations and Code Samples

At the end of the Google Summer of Code term you are required to submit a code sample you created during your current GSoC participation, in addition to your evaluation. What you include in the code sample is up to you and your mentor.

Depending on what portions of code are included in the scope of your project, you may need to submit diffs between code that you've written and others have written, or even include an entire branch of the code base. Discuss this with your mentor and your community and use your best judgement.

Payments - Be Patient!

Successful completion of your evaluations triggers the payments made to your payment card. This takes a few business days to process. Please be patient. 

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:

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 students to review your code for you and give you feedback. Use other students in your community and the GSoC program as a resource. 

Staying Engaged with Your Community

A glorious summer has ended. GSoC is now over—but only officially. Your obligation to the program has been met, but your opportunities still abound. Make the "summer" last by staying involved in your community. Yes, it's now your community. Make the most of it. We have a couple of suggestions that can help you make your experience last beyond the summer.

Maintaining Your Project

You worked on a wonderful project during the summer. You can't abandon it just because the summer ended! After all it's your baby. One way to make sure that your project keeps on growing is by maintaining it well, adding new features to it. There might be a few loose ends that you weren't able to tie up during the coding period. If there's anything in (or not in) your code that's keeping you awake at night, you can always work on that after the coding period ends.

"Please do the communities a favour by not abandoning your projects after the GSoC results are announced, or the boogeyman will get you.[!!!] "
Lalith Suresh P., Network Simulator 3, GSoC Studnet 2010

New Projects

Do you have other amazing ideas for projects? Why wait until next GSoC to get started on them. You should start working on them right away. You know the folks in your community well now, and you know where to shout for help. Just get started on your wonderful new project idea; you can even get it accepted as a GSoC project next year!

Retreats and Hackfests

A lot of organizations host opportunities to meet face-to-face throughout the year. Attend if there's one happening close by. They're great fun! In fact, you can help organize such activities or even start a local chapter of your community in your area if you have enough people around.

Spread the word

You had a great time this summer. It's your turn now to tell your friends about it. GSoC is also about growing the open source community. Share your GSoC success story with others and inspire them too!

Present your work

You can present your project at some of the open source conferences. The open source community is very much interested in finding out about the cool things that people have been working on. Conferences are a great way of doing that. If possible, you should attend a conference and use the opportunity of presenting your project to other people. It gets you great feedback on your project and helps you find out about other cool things happening in the open source world.

Next Summer

There are so many ways that you can help your organization and the open source community for the next Google Summer of Code. You can submit project ideas, apply again as a student or even become a mentor for a project. You can even contribute by just idling in the IRC channels, helping out the new students who come looking for advice.

Stay connected

Everyone likes to hear back from friends and people they've worked with. Be sure to stay in touch with your mentors, other students and the many great friends that you've made during GSoC.

"GSoC may be over, but I'm really hoping my contribution to the Congress application will go beyond that. I'll be sure to stay in touch with Eric and the Sunlight Foundation. "
Evelina Vrabie, SunLight Foundation, GSoC Student 2010

About This Manual

This manual was written during a Book Sprint sponsored by Google and facilitated by FLOSS Manuals. The manual was written in two days but the maintenance of the manual is an ongoing process to which you may wish to contribute. A second sprint occurred in 2010 to update the manual (adding the Org Admin section) and to write the Students Guide ("Flipping Bits not Burgers").

Since the manual may be updated at any time, you may wish to periodically check here for updated versions:

You can also find the electronic book (for use with Android ebook readers software, Sony Reader etc) here:

How to Contribute to This Manual

If you would like to contribute then follow these steps:

  1. Register On the front page (http://www.booki.cc) by clicking on Sign in / Create Account at the top of the screen.
  2. Under Create Account add your desired details

  3. Click Create Account.
  4. Booki will generate the account and display a Your account has been created message before redirecting you to your Profile Page. Your user page is also accessed through My Profile on the menu.
  5. Contribute by visiting http://www.booki.cc/gsocstudentguide/_v/1.0/edit/. Press 'edit' and start work on a chapter.
  6. Mailing List
    For discussing all things about FLOSS Manuals join our mailing list:

For more information on using FLOSS Manuals you may also wish to read our manual:

About the Authors

This manual exists as a dynamic document on flossmanuals.net, and over time will have an ever-increasing pool of authors and contributors.

Except were noted the following individuals were part of both the 2009 and 2010 GSoC Book Sprint. We thank them for their tireless efforts to create this first-of-its-kind volume.

Alexander Pico
Alex works at the Gladstone Institutes in San Francisco as a Bioinformatics Software Engineer. He holds a PhD in Molecular Neurobiology and Biophysics and has over 10 years of bioinformatics experience in data mining, analysis, visualization and integration. Over the past 5 years he has led the GenMAPP pathway analysis project, managing software development and coordinating research projects involving wet lab biologists and senior programmers. Alex is a member of the Cytoscape core development team, a creator of SNPLogic.org, and a founder of WikiPathways.org. He has also administered GenMAPP's participation in the Google Summer of Code program for the last 4 consecutive years.

Bart Massey
Bart Massey graduated Reed College in 1987 and spent two years as a software engineer at Tektronix, Inc.  He received his MSc in Computer Science from University of Oregon in 1992 and his PhD in 1999 for work with the Computational Intelligence Research Laboratory there.  Since then, Bart has taught at Portland State University, where he is currently an Associate Professor, and for the Oregon Master of Software Engineering program. Bart is Secretary of the X.Org Foundation Board; his current research interests include open tech, software engineering, desktop interfaces and state space search.

Jonathan "Duke" Leto
Jonathan is an open source hacker who currently focuses on the Parrot Virtual Machine and Rakudo, Perl 6 on Parrot, as well as being the maintainer of many CPAN modules, many with a focus on scientific computing and cryptography. He first was a mentor for Math::GSL in GSoC 2008 and then became organization administrator for The Perl Foundation's involvement in GSoC 2009 as well as being the mentor for Math::Primality. Jonathan received a masters in mathematics from University of Central Florida and has published several papers in the field of differential equations. Currently he works in the Bioinformatics sector and consults for Git migrations and training. He enjoys discovering wheels within wheels.

Jennifer Redman
Jennifer is the founder and CEO of Buunabet, a technical consulting company that helps businesses and organizations integrate open source software into their computing infrastructure. Jennifer is currently the Associate Systers-Keeper for Systers, the oldest International online community of technical women. One of the founders of the Systers open source project, she participated in GSoC 2009 and 2010 as an org admin and mentor. Previous careers include canvassing for Greenpeace and as a staff member on a national (and successful) presidential campaign. She also likes to travel and reads a lot of books.

Selena Deckelmann  (2010)
Selena is a major contributor to the PostgreSQL project. She founded Open Source Bridge conference, a conference for open source citizens. She helps run PDXPUG, a PostgreSQL Users Group, and is part of Code n Splode, a programming group whose goal is to get more women involved in open source. In her spare time, she likes to mix drinks for her local user groups, and fetch eggs from her chickens.

Carol Smith
Carol works for the Open Source Programs Office at Google administering the Google Summer of Code program. She has worked at Google for 5 years in a variety of positions. She has a degree in photojournalism from California State University, Northridge and is an avid cyclist.

Malveeka Tewari  (2010)
Malveeka is currently a graduate student in the CS dept at UC, San Diego. She participated in GSoC 2009 as a student for Systers and again as a mentor for Systers in GSoC 2010. She is also a member of Systers and WIC (Women in Computing) group at UC, San Diego and has helped in organizing events in her school for engaging and encouraging women in computing. Her favorite past times including hiking, cooking and reading books. She is a big fan of P.G. Wodehouse and Agatha Christie.

2009 Particpants

Olly Betts 
Olly is the lead developer of the Xapian search engine library. He's been working on Xapian for 10 years, and makes a living as a freelance developer and consultant on Xapian-related projects. In GSoC, he's represented SWIG as a mentor in 2008, and a mentor and co-admin in 2009. Olly is originally from the UK where he studied mathematics and then computer science at Cambridge University, but now lives near Wellington in New Zealand. He once broke a toe falling off a cliff in Majorca. 

Leslie Hawthorn 
Leslie held various roles at Google before joining the Open Source Programs Office in March 2006. Her first project after joining the team was spinning up Google Summer of Code 2006 and she has managed the program ever since. She also conceived, launched and managed the Google Highly Open Participation Contest, an initiative inspired by GSoC that helps pre-university students get involved with all aspects of open source development. Mentoring in open source communities is one of her personal passions, along with humanitarian uses for open source software. She loves to cook, read and can occasionally be found pining for illuminated manuscripts. She also likes to think of herself as a superb filker. 

Facilitation (2009 & 2010)

The Book Sprints were facilitated by :

Adam Hyde
Adam is the founder of FLOSS Manuals and project manager for Booki. FLOSS Manuals is a community of 1500 (at the time of writing) volunteers that create quality free documentation about free software. FLOSS Manuals is pioneering the Book Sprint methodology that enables the development of well written manuals on free software in 2-5 days. Adam has facilitated over 15 Book Sprints on Free Software including Inkscape, OLPC, Sugar, CiviCRM, Firefox, Introduction to the Command Line, Digital Foundations (conversion to free software examples), Ogg Theora, How to Bypass Internet Censorship, Open Translation Tools, PureData, Video Subtitling and now the Google Summer of Code Mentors Guide. Adam is also the Project Manager for the development of 'Booki' - the free software Collaborative Authoring Platform (see below).

The Platform

This book was written using Booki and output to templated HTML, book formatted PDF, and epub by the same platform. Please consider helping us develop this wonderful collaborative authoring and book production software. It is GPL and more info available at http://booki-dev.flossmanuals.net. You can also see booki at http://www.booki.cc.

History of GSoC

Google Summer of Code began in 2005 as a complex experiment with a simple goal: helping students find work related to their academic pursuits during their school holidays. Larry Page, one of Google's co-founders, was pondering the age-old problem of scholastic backsliding: students work hard and learn a great deal during the academic year, but without the right employment opportunities or other pursuits outside of school, technical skills atrophy rather than get honed and expanded. Larry wanted Google to help solve this problem.

The obvious solutions failed on geographical grounds. If a student wasn't in the optimal location, obtaining a useful internship could be difficult if not impossible. Finances were also a problem; many internships are low paying or entirely unpaid, making it difficult for students to take the right job while still paying the bills. Finally, even if a job was available in a technical field, it would not necessarily introduce a student to the broad set of skills required to do software development well. For example, creating a website for a local non-profit requires technical skill and would no doubt be personally gratifying, but wouldn't necessarily require using an IDE, checking into source control, or creating tests.

The perfect answer came from encouraging students to participate in open source projects. Open source development occurs online, both solving the geography problem and giving students the chance to work in a globally distributed team. Working on an open source project provides exposure to the entire software development process and tool chain. Students could enjoy the added benefit of having a body of reference work available to future employers or committees. Even better, students would get the chance to work on a code base under active development rather than a lab project or other single use assignment.

A cash stipend from Google allowed students to focus on their development work rather than getting a job unrelated to their academic pursuits. The final part of the puzzle was finding projects who were excited to find new contributors and to provide helpers to get these new folks up to speed both technically and socially. The first year 40 projects participated; 400 students began the experiment.

In 2010, the sixth Google Summer of Code wrapped up with the best results yet. More than 89% of the 1,026 student participants in the program successfully completed their projects. Best of all, most of the organizations participating over the past six years reported that the program helped them find new community members and active committers.

You can find more information about each year of Google Summer of Code on the program statistics page of the GSoC Knowledge Base: http://code.google.com/p/google-summer-of-code/wiki/ProgramStatistics

Additional Resources

We've collected our favorite and most useful resources specific to GSoC here.

General Resources

You want to take a look at the Program Frequently Asked Questions each year to make sure you have a good idea of the rules for the program. There's a wealth of information included in the FAQs each year, even for experienced participants. You can always find the latest information, including a link to the FAQs, at http://code.google.com/soc/.

Additionally, these resources are quite helpful:

Program IRC Channel
Several knowledgeable folks hang out in #gsoc on Freenode and would be happy to give you a pointer in the right direction.

Blog Posts
You can find material related to GSoC on the Google Open Source Blog at http://google-opensource.blogspot.com/search/label/gsoc. Your project may have a blog or newsletter where GSoC information was published in the past, as well.

Knowledge Base
If you're looking for advice for mentors or students, program promotional materials, presentations about GSoC, etc., start with the knowledge basehttp://code.google.com/p/google-summer-of-code/, particularly the wikihttp://code.google.com/p/google-summer-of-code/wiki/WikiStart.

List of Organizations
Each year, the community creates a list of categorized list of mentoring organizations. You can find it linked from the Knowledge Base: Advice for Students page.


Mailing Lists

There are four program mailing lists.

Announcement Only List
For announcements from Google's program administrators only. Used infrequently.

Program Discussion List
Open subscription list for the program. General talk about the program, light traffic except during the launch phase of the program each year. Typically this list is not hugely relevant except just prior to the announcement of accepted organizations and accepted students, as neither organizations nor students have access to the private lists until acceptance unless they have previously participated in the program. It is always excellent for you to stop by and encourage a newbie, though, so please don't totally ignore this list. 

Students List
Private, invite-only list; students are subscribed to the list soon after they are accepted into GSoC. Successful student participants from previous years and students currently working on GSoC are subscribed to this list. Students who are dropped from the program are also removed from the list. While this list is supposed to give students a private place to discuss anything and everything so they aren't worried about looking silly elsewhere, more often than not the list traffic is mostly discussions of tracking numbers for shipments, tax forms and grumbles about t-shirt loss. 

Mentors List
Private, invite-only list; mentors are subscribed to the list after their organization is accepted into the program and they register as mentors in the GSoC online system. This list is higher traffic at the beginning of the program and around the times of evaluations. Some great advice can be found on this list and in the archives, but it can also be noisy at times. 


Producing Open Source 
Written by Karl Fogel. Excellent guide to Open Source development. Its available free online. 

Google Summer of Code Mentors Guide

Google Summer of Code Students Guide

Teaching Open Source
by Karsten Wade

Associated Projects

Teaching Open Source 
irc : freenode #teachingopensource

What to Do When the Unexpected Happens?

  1. Contact your Mentor. He or she can help you figure out what to do next or contact Google for more help.
  2. Contact the Org Admin.
  3. Talk to Google's Program Administrators. They have plenty of experience with all the corner cases and strange issues that can arise during GSoC. Email ospoadmin@gmail.com for help if you can't find one of the program admins in #gsoc on Freenode.

Proposal Example 1

"Database Abstractions" By Kanika Vats, Systers, 2009


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 :

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.

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:

April 20 – May 23 (Before the official coding time):

May 23 – June 18 (Official coding period starts):

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:


July 6 – July 15:

July 15 – July 25:

July 25 – July 31:

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.



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.



The shortest way in the geek world to say "I agree with this" or "This is a great idea". It is often used when others have already fleshed out the details and a consensus of how many agree/disagree with the sentiment. It is worth noting to your students if your project uses this as a voting signal so they do not accidentally comment on issues when, as newbies, they should be observing rather than commenting/voting.


The opposite of +1. Often accompanied by an explanation why, if you are lucky.


An individual who has special rights in an open source project. While the scope of this term varies by project, the general idea is that this individual is able to check in source code to the project's main repository.

Community Bonding Period

The period of time between when accepted students are announced for a particular year of GSoC and the time these students are expected to start coding. This time is an excellent one to introduce students to the community, get them on the right mailing lists, etc. See the "Mind the Gap" section for more details.


Distributed version control system. A version control system that does not require talking to a centralized server.


Free/Libre Open Source Software. Likely the most inclusive acronym to describe the software produced for GSoC.


Google Summer of Code


Integrated Development Environment


Instant Messenger


Internet Relay Chat


Just Fabulously Do It. Use your imagination. Ask for forgiveness, not for permission. :)


To spend some time watching. Often used in reference to a mailing list where you will read the posts but not make any posts yourself or an IRC channel where you watch how people interact but don't say anything. 


Someone who helps a student with their project proposal. See the What is GSoC section for more details.


An open source, free software or technology-related project that mentors students for Google Summer of Code. Also known as a mentoring organization.

Organization Admin (Org Admin)

Cat herders for each open source project participating in the program. Often abbreviated to org admin. See the What is GSoC section for more details.

Program Administrator

Google employees who run the program. See the What is GSoC section for more details.


Read The FLOSS Manual ;)

Secondary Mentor

A person who helps out a student's assigned mentor. At time of writing this manual, the GSoC online system only allows one mentor to be officially assigned to a student proposal, as one person must be responsible for submitting evaluations, etc. However, it is quite common to have multiple mentors for one student.


Simple Matter of Programming


Not so much a season as a state of being. While the program is run during the Northern Hemisphere's Spring and Summer, the "Summer" in Google Summer of Code is actually a play on the "Summer of Love.


Test Driven Development

Use Case

A use case describes what a user can do with a particular software system.


Coordinated Universal Time.

Waterfall Model

A sequential software development process that usually doesn't work.


Note : "Google Summer of Code" (GSoC) is a trademark of Google Inc. 

All chapters copyright of the authors (see below). Unless otherwise stated all chapters in this manual licensed with Creative Commons SA-BY 3.0

What is Google Summer of Code? 
© Google Inc And The Contributors 2010
dukeleto - Jonathan "Duke" Leto 2010
carols - Carol Smith 2010
adamhyde - adam hyde 2010
booki - Booki Book 2010
selenamarie - Selena Deckelmann 2010
BartMassey - Bart Massey 2010
malveeka - Malveeka Tewari 2010

Why Should I Apply? 
© Google Inc And The Contributors 2010
AlexanderPico - Alex Pico 2010
malveeka - Malveeka Tewari 2010
booki - Booki Book 2010
adamhyde - adam hyde 2010
selenamarie - Selena Deckelmann 2010

Am I Good Enough? 
© Google Inc And The Contributors 2010
selenamarie - Selena Deckelmann 2010
jenred - Jennifer Redman 2010
booki - Booki Book 2010
adamhyde - adam hyde 2010
carols - Carol Smith 2010
malveeka - Malveeka Tewari 2010

Choosing an Organization 
© Google Inc And The Contributors 2010
AlexanderPico - Alex Pico 2010
booki - Booki Book 2010
malveeka - Malveeka Tewari 2010
adamhyde - adam hyde 2010

Making First Contact 
© Google Inc And The Contributors 2010
AlexanderPico - Alex Pico 2010
adamhyde - adam hyde 2010
selenamarie - Selena Deckelmann 2010
malveeka - Malveeka Tewari 2010
dukeleto - Jonathan "Duke" Leto 2010

Finding the Right Project 
© Google Inc And The Contributors 2010
AlexanderPico - Alex Pico 2010
malveeka - Malveeka Tewari 2010
adamhyde - adam hyde 2010
dukeleto - Jonathan "Duke" Leto 2010

Writing a Proposal 
© Google Inc And The Contributors 2010
selenamarie - Selena Deckelmann 2010
BartMassey - Bart Massey 2010
malveeka - Malveeka Tewari 2010
adamhyde - adam hyde 2010
dukeleto - Jonathan "Duke" Leto 2010

Being Turned Down 
© Google Inc And The Contributors 2010
adamhyde - adam hyde 2010
selenamarie - Selena Deckelmann 2010
jenred - Jennifer Redman 2010
booki - Booki Book 2010
AlexanderPico - Alex Pico 2010
malveeka - Malveeka Tewari 2010

How GSoC Works 
© Google Inc And The Contributors 2010
jenred - Jennifer Redman 2010
carols - Carol Smith 2010
booki - Booki Book 2010
adamhyde - adam hyde 2010
selenamarie - Selena Deckelmann 2010
BartMassey - Bart Massey 2010
malveeka - Malveeka Tewari 2010
AlexanderPico - Alex Pico 2010

What Does Community Mean? 
© Google Inc And The Contributors 2010
jenred - Jennifer Redman 2010
selenamarie - Selena Deckelmann 2010
BartMassey - Bart Massey 2010
adamhyde - adam hyde 2010
dukeleto - Jonathan "Duke" Leto 2010
AlexanderPico - Alex Pico 2010
malveeka - Malveeka Tewari 2010

Open Source Culture 
© Google Inc And The Contributors 2010
jenred - Jennifer Redman 2010
adamhyde - adam hyde 2010
malveeka - Malveeka Tewari 2010
AlexanderPico - Alex Pico 2010

Communication Best Practices 
© Google Inc And The Contributors 2010
jenred - Jennifer Redman 2010
malveeka - Malveeka Tewari 2010
selenamarie - Selena Deckelmann 2010
dukeleto - Jonathan "Duke" Leto 2010
adamhyde - adam hyde 2010
AlexanderPico - Alex Pico 2010

How to Get a Head Start 
© Google Inc And The Contributors 2010
adamhyde - adam hyde 2010
selenamarie - Selena Deckelmann 2010
dukeleto - Jonathan "Duke" Leto 2010
jenred - Jennifer Redman 2010
malveeka - Malveeka Tewari 2010

Working with Your Mentor 
© Google Inc And The Contributors 2010
jenred - Jennifer Redman 2010
selenamarie - Selena Deckelmann 2010
AlexanderPico - Alex Pico 2010
malveeka - Malveeka Tewari 2010
dukeleto - Jonathan "Duke" Leto 2010
adamhyde - adam hyde 2010

Time Management for Students 
© Google Inc And The Contributors 2010
selenamarie - Selena Deckelmann 2010
malveeka - Malveeka Tewari 2010
dukeleto - Jonathan "Duke" Leto 2010
adamhyde - adam hyde 2010
jenred - Jennifer Redman 2010

© Google Inc And The Contributors 2010
adamhyde - adam hyde 2010
carols - Carol Smith 2010
selenamarie - Selena Deckelmann 2010
jenred - Jennifer Redman 2010
AlexanderPico - Alex Pico 2010

Getting Your Code Committed 
© Google Inc And The Contributors 2010
selenamarie - Selena Deckelmann 2010
dukeleto - Jonathan "Duke" Leto 2010
malveeka - Malveeka Tewari 2010
BartMassey - Bart Massey 2010

Staying Engaged with Your Community 
© Google Inc And The Contributors 2010
adamhyde - adam hyde 2010
AlexanderPico - Alex Pico 2010
malveeka - Malveeka Tewari 2010
BartMassey - Bart Massey 2010

History of GSoC 
© Google Inc And The Contributors 2010
carols - Carol Smith 2010
adamhyde - adam hyde 2010

Additional Resources 
© Google Inc And The Contributors 2010
carols - Carol Smith 2010
malveeka - Malveeka Tewari 2010
adamhyde - adam hyde 2010
AlexanderPico - Alex Pico 2010

Proposal Example 1 
© Google Inc And The Contributors 2010
adamhyde - adam hyde 2010
selenamarie - Selena Deckelmann 2010
AlexanderPico - Alex Pico 2010
malveeka - Malveeka Tewari 2010

Proposal Example 2 
© Google Inc And The Contributors 2010
adamhyde - adam hyde 2010

© Google Inc And The Contributors 2010
dukeleto - Jonathan "Duke" Leto 2010
AlexanderPico - Alex Pico 2010
carols - Carol Smith 2010

© Google Inc And The Contributors 2010
adamhyde - adam hyde 2010