|
|
AdviceforStudents
Advice for GSoC Students
Welcome to the Advice for GSoC Students Page
Whether or not you're new to open source development, the work you'll do as part of the Google Summer of CodeTM program is not the "usual" way people are involved in developing free software. The information on this page, written by GSoC students and mentors for students, is meant to help you choose a mentoring organization, write your application and hone your skills as an open source developer.
In addition to the advice here, Patrick Barnes, organization administrator for the Fedora Project, has posted some helpful hints in the Google Summer of Code Discussion Group.
Alex Russell from the Dojo Project has also posted some great advice for students.
Bart Massey with Portland State University has posted PSU's application guidelines, which also contain some good overall tips for effective proposal writing in general. Great advice from a mentor and organization administrator who has been with us for many years. :)
The folks at the Drupal project also have some great application guidelines for students.
Laurynas Biveinis has written an excellent introduction to life as a Summer of Code student.
Applying to GSoC
Choosing a Mentoring Organization
Alex Pico with GenMAPP created a categorized list of mentoring organizations for GSoC 2008. The list is admittedly somewhat subjective, it may be of help to you in narrowing down the list of organizations you'd like to investigate.
You may also want to check out this list of mentoring organizations categorized by programming language.
While you'll want to choose a mentoring organization based on your technical skill set, there are many other factors to consider. Further, several organizations will require similar expertise from their students, so you may find yourself facing some challenging decisions about where to spend your time applying. Here are a few suggestions to help you determine which organizations will be the best ones for you:
- Hang out in the organization's IRC channel.
- Subscribe to the organization's development mailing list.
- Read any introductory documentation on the code base.
- Poke around in the issue tracker.
When exploring these areas, ask yourself a few questions:
- Do you feel like there is sufficient documentation available to help you get started?
- Can you follow the IRC and mailing lists discussions or are you having trouble understanding them?
- Do the personalities of the developers and community match well with yours?
- If you have a question, are you comfortable with the way it was answered? Was the response helpful to you?
- Do the organization's development philosophy and goals match yours well?
If you don't find yourself answering yes to most of these questions, you may want to consider contributing more to this project outside of Google Summer of CodeTM.
Additionally, some organizations are considering additional due diligence beyond just the application, such as interviews in IRC. If you're asked to interview with an organization, remember that this interview is like every other interview you'll do throughout your career: both you and the organization are deciding if there is a good fit between the two of you. Make sure to ask plenty of questions about the organization's expectations, development methodology, and any other matters that will help you decide if the organization is right for you. Remember, the ultimate goal of Google Summer of CodeTM is to help you find a community that you'll be happy to continue contributing to long after the program ends, so the more investigation you do up front, the better.
Angie Byron says:
For a long time I've had an interest in activism, and helped contribute graphics and posters to the Spread Firefox community for awhile. The first thing I do whenever I visit a new site is "view source" to see what's being used to generate it. I found references to Drupal, so that organization stuck out in my mind when I saw it on Google's mentor list.
After some more research, I discovered that the CMS was used by a number of political and grassroots organizations and so, coupled with the fact that it was written in PHP (which is my primary language of choice), I knew that Drupal would be a great fit as a mentoring organization.
Choosing a Project
Remember, GSoC takes place over just three months, so choose a project that is reasonable to complete in that time frame. While we've built additional time into the program to allow you to get up to speed on your organization's community and documentation before you start coding, we repeatedly hear from mentors that their students undertook projects which were too complex to complete within the GSoC time frame. Undertaking an ambitious project is laudable, but don't choose a project and submit a proposal that will end up being too challenging and, therefore, frustrating for you. If you're having trouble determining whether your idea needs further distillation or refining, consider talking with the organization's developers and asking for their thoughts; it's an excellent way to get to know them.
Angie Byron says:
Remember to allow time for learning the various "support" activities around the project, such as version control systems, unit testing, and so on. If you're not already using these in your everyday development, getting up to speed can present a challenge. And even if you're actively using them, you still need to know how your organization does things and how it might be different from what you're used to.
Also, if you're not already familiar with the source code of your organization's project of choice, remember to to allow time for simply learning the code. This "getting into someone else's head" and understanding why code works the way it does can be especially challenging for students coming from an academic setting, where reading someone else's code is considered "cheating" and projects are done individually.
Ideally, you should have a thorough grasp on all of these before you even start on your project.
Writing Your Application
Your mentoring organization may have a template they would like you to use, which will be available when you apply using the GSoC web app. However, a template is just a start, and writing a proposal is very different than writing code or even an essay. Don't forget that your online application can and should be supplemented with additional materials, such as links to your Curriculum Vitae, repository locations for other open source code you've committed, etc.
Here are some suggestions to help you write your application, in addition to the suggestions in the FAQs:
- Promote your idea. Describe your idea in detail. What is its ultimate goal? What components will it have? What benefits does it have for the project itself and its community? How do you plan to achieve completion of your project? If a specification already exists, what will you do that will go above and beyond expectations?
- Promote yourself. Talk about what makes you stand out from the rest of the crowd. Talk about your past experiences, what makes you tick. Why are you interested in open source software, and your given project in particular? What interests do you have, and how do these interests relate to the project for which you're applying? There is a basic assumption that people applying for Summer of Code will have at least some programming skills already. So rather than spend a lot of time elaborating on these (though by all means, do talk about what you know), spend time talking about you.
- Show enthusiasm. Summer of Code is a very exciting opportunity, and open source development itself is extremely exciting. Most mentors are not just looking for people who want a summer job to pass the time, but for devoted people who have an intrinsic passion for open source, and are (or will become) zealots for the given mentoring organization in particular. ;)
- Tailor your application to the project. It is painfully obvious when someone copies/pastes parts (or even the entirety) of an applications to multiple organizations. This can be seen from a mile away, and it is a sure-fire way for your application to not be taken seriously. Each application you send should be targeted and tailored for the specific mentoring organization and project to which you are applying.
- Get feedback on your idea from the community. Discussing your idea with some established folks in your target organization's community is vital. If your idea duplicates existing efforts or code (and does not provide a very convincing reason for doing so), it will be rejected. Try to have your application reviewed by someone before you submit it, whether that be the mentor for a particular project itself (in the case of already generated ideas on the following pages), or a person with expertise in a certain area. Don't be afraid to ask the organization's community for help; they want you to succeed just as much as you do. :)
- Don't wait until the last minute. Most organizations get a huge flurry of submissions on the last day. Students who get their applications earlier will generally have their applications reviewed more thoroughly, and also have time for revisions. Start planning your application as soon as possible!
Tim 'Mithro' Ansell says:
- Don't wait until the last minute!!! (Yes, that is worth 3 exclamation points.) I can not stress how important it is to not wait till the last minute. Applications can be updated right up to the deadline. If you submit your application early, many organisations will give you feedback allowing you to improve your application!
All the successful applications for Thousand Parsec had at least 3 revisions before the final deadline.
Angie Byron says:
I spent about a week writing my application, in between other things. I went after one of the bounties offered by my mentoring organization: a Quiz module for Drupal.
First, I read all of the background material and discussion that had taken place on the forums and mailing list around the idea. This helped me to better understand the motivations for the project, and also helped me to learn the names of some of the people interested in it, who I could later contact for additional feedback/insight and as testers. I also did some general skimming of Drupal's documentation: the handbooks, the API docs, and so on, to get a "feel" of the project. Finally, I checked to see if they had any specific SoC requirements beyond what Google had outlined.
Next, I e-mailed the mentor for the Quiz module bounty to let him know that I was interested in applying, and to introduce myself to him. In this way, we got to know each other a little bit even before I had applied formally, which helped my name to stick out a bit from the rest. I asked if he'd be willing to look over an initial draft of my application, and he said he'd be happy to. He also gave me some helpful tips on additional places to look for information, and some things to specifically mention in the application.
Next came actually writing up the application. I first described the goals in detail to get across my understanding of the project, but was careful not to just blatantly copy/paste stuff from the description; rather, I re-wrote it in my own words, and also added some more things that I thought of which could make the project better. I also tried to draw attention to personal qualities I had that made me suitable for the project, such as my experience both as a student and a teacher, my knowledge of XHTML/PHP/SQL, and my diverse IT background outside of web programming. I also spent time focusing on the benefits that the module would have for the Drupal community itself, in terms of widening its appeal, and how the module could also be useful outside of the academic setting.
Finally, came submission time. I sent the application to a teacher first for some last-minute proof-reading, and then onto the bounty's mentor as a final check. He gave the thumbs up and I submitted it. Then I spent pretty much every waking moment of the next few weeks with my stomach clenched in anticipation/fear. ;)
Responding to Requests for Further Information
Often, a mentoring organization may ask you for further information or clarification on your proposal. When responding to these requests, keep your responses concise and targeted. Organizations are reviewing literally hundreds of proposals, so your ability to communicate clearly and effectively will be a great asset to you.
Augie Fackler says:
Try to be prompt in responding to requests for information - if you take too long, it may be seen by the potential mentors as a lack of desire on the project.
Getting Started in GSoC
Getting to Know Your Organization's Community
While it's a great idea to due diligence in this area before submitting your proposal, should your application be accepted, you will definitely need to spend some time integrating with your organization's community. How to best bond with your new developer colleagues will vary widely, but it's essential that you do so; this aspect of participating in GSoC is so important that Google is announcing the program over three months before coding begins to ensure that all students have time to get to know their organizations developer (and user) communities.
Angie Byron says:
I found what helped me the most with getting integrated in the community was helping with user support and documentation. This is stuff that tends to get a bit neglected in open source projects, so when someone steps up in these areas, the rest of the community really appreciates it. It's also a great way to understand the project better.
I hung out in the support IRC channel, and whenever anyone asked a question I'd challenge myself to try and find an answer. At first, I was mostly just learning things from other people, but gradually I found I was able to answer a couple questions myself, and pretty soon I was actually answering a couple developers' questions. :D
In addition to this, whenever I'd discover something new that wasn't already in the documentation, I'd document it. Nothing helps to ensure you really understand something more than trying to teach other people about it. :)
After awhile, this kind of thing earns you a reputation in the community, and your reputation in an open source community is your best asset.
The Intimidation Factor
Whether or not your proposal is accepted, you'll likely find yourself in a pretty intimidating situation: posting questions on mailing lists where the project's founder or other famous developers are subscribers. This prospect can be plain terrifying; no one likes to look stupid, and getting flamed isn't the most pleasant of experiences. While we hope that you'll receive positive and useful responses to every question you posit, sharp retorts or responses of RTFM are par for the course in open source.
So, a word to the wise: you will say things that you will later wish you'd thought through more. You will post questions that are not as articulate as you'd like. You will make mistakes that you will later look back at and cringe, thinking "how could I have written this code?" These situations are just a part of life and are not unique to open source, so roll up your sleeves, thicken your skin and remember that failures are as much a part of gaining knowledge as successes.
Angie Byron says:
I was terrified the first time I went to introduce myself in the developer channel on IRC -- especially after I got flamed off the face of the planet for being off-topic. ;) A couple different things helped:
a) I started just idling in the channel and watching how the developers interacted with each other. I got to see patterns of what types of questions comments were/weren't allowed, when it was okay to chit-chat vs. when it was time to be quiet because developers were working on hashing out a serious problem, and so on.
b) Whenever someone asked for a patch review, or to have a bug validated, or started a discussion that was at my level, I would join in and try and participate. This helped me to meet other developers on a 'contributor' level, which helped me to earn their respect.
Communication
While your mentor is your primary point of contact with the organization, don't forget that there's an entire community out there to help you. Communicate early and communicate often, both with your mentor and the community as a whole. Distributed development can be more difficult by its very nature, as you can't simply talk to your mentor in a hallway to get good advice; get used to being proactive in your questions,
Remember too that documenting your design decisions and any changes to your milestones or development plan, etc., will not only be useful to you, but will help to keep you and your mentor on the same page regarding expectations for your work.
Angie Byron says:
The hardest lesson I had to learn about communication was that it's okay to ask for help. Sounds silly, right? But you feel a lot of pressure for being one of the few who is accepted into SoC. It's easy to fall into the trap of trying to impress your mentor and community by not asking questions so that you come across as smart, only to spin your wheels hopelessly on some silly problem and waste valuable time.
Obviously, don't go around bugging people about every little thing (always try to figure it out yourself and do some basic troubleshooting first), but also don't feel like if you ask questions people are going to think any less of you. Remember that SoC is a learning experience, and your mentor and the rest of the community are there to guide you along your journey. Also remember that even the "super hackers" in your community asked lots of questions to get to that level. :)
Marty Connor says:
Your mentor almost certainly volunteered to do GSoC, and helping you succeed is probably a good part of why. Learning to communicate on a regular basis with your mentor will help them help you. I have found questions from my students to be very helpful in improving design, implementation, and documentation of our software.
Time Management
Even for someone who positively thrives in an academic setting, having a big, open summer with far-away deadlines where you are forced to structure your own time can be very challenging. Many talented, smart, driven people end up not making it through Summer of Code because of this difficulty.
A couple things can help with this:
- Before you start writing a line of code (ideally, this is part of your application itself), lay out a basic schedule for yourself, identifying major milestones and when they should be done. Remember to try to allow ample time for unexpected things that might come up.
- Set up a schedule with your mentor to do at least weekly status reports. It'll be much harder to fall behind if you know you have to get at least "something" done by Thursday, for example. It also ensures that you are keeping communication up, and that you're both on the same page regarding your progress.
- Break the project down into smaller, more manageable tasks that are actionable. The more specific the task is, the easier it is to accomplish on its own, and the faster you reach your end goal.
Angie Byron says:
The best advice I can give students regarding time management is to break their projects down into smaller, bite-sized chunks. "Finish my SoC project" is not a good thing at all to have on your to-do list. It creates one big, amorphous ball of "stuff" you have to do, and it's is easy to get demoralized when you see it staring at you every day. You can fall into a procrastination trap thinking, "Ugh... I don't even know where to start with this... I'll try again tomorrow..."
Instead, break your project down into smaller, more manageable tasks like, "Research into foo thing to evaluate different approaches," "Write a function to do bar with baz and blah inputs that returns boing" and "Create icon for the yadda yadda button." This process accomplishes three things:
a) It will almost lay out a 'roadmap' to follow from start to completion if you do it thoroughly enough.
b) You'll end up with far fewer surprises at the end because you're almost forcing yourself to think through everything up front.
c) Each time you check something off, you're that much closer to being done!
Some people use fancy-schmancy project planning tools and GANTT charts and all that kind of stuff to do this. I use post-it notes. :P I write down, "This is the stuff I have to do today," prioritize it by urgency, then take the first thing on that list and try and "think-through" what it would take to finish that, and write that on a separate page. Then I just go through and mark things off as I finish them, and voila! I can look back and see that I actually made progress today! ;)
Luca Barbato says:
Some projects enforce in a strict way the "commit early, commit often" model, sometimes adding the constraint of having the commit not break the build, that is more or less a generalization of what Angie suggested and you should consider using both: split your project in tasks, complete each task by small traceable steps/commits. Even if this method is quite effective, it is usually clashing with the tendency to perfect the code before even thinking about commit: - Do not be afraid of pushing some code, getting feedback is important and fixing issues early usually spare lots of work later. - Do not be afraid of being considered dumb because a commit is: everybody does make mistakes, just few are good enough to accept that and fix them timely. Having smaller commits, one or more for each conceptual change, helps the mentors tracking your progress, makes you spare quite a lot of time bug hunting since there are many semi-automated tools to bisect the history and overall makes the casual observer feel there is lots of activity.
Tim 'Mithro' Ansell says:
I had "if it isn't committed, it doesn't exist" policy with my students. The "commit early, commit often" idea is a very good idea if you are new the project for a number of reasons. Most importantly, it allows the community to give you feedback on your code. This can save a huge amount of time later if you are going down the wrong path. Nothing is more frustrating than pushing a hundred line patch you spent hours working on and finding out someone else knows a single line way!
Advice for Non-US Students
There are a number of unique challenges facing students outside the USA. Most students outside the USA do not have the long summer break that the USA students enjoy. This is specially true for students who are located in the Southern Hemisphere, where it isn't even summer! Don't despair, a huge number of both accepted and successful students are not in the USA.
This section is specially for tips specifically for non-US students.
- Be upfront about what your commitments will be over the period (including when your exams are). Showing that you have thought about your commitments will give your mentor more confidence.
- Include your timezone in your application, this will help the organisation match a mentor in a compatible location.
- Project management is much more important because of the more limited time, make extensive use of the tips listed above.
- Start working early, including during the "community bonding" period.
Sign in to add a comment
Hi,
Have you read the FAQs? There is plenty of information there :)
Brilliant tutorial. The "Writing Your Application" section should really be the master outline that everyone should if the organization doesn't provide one for you. It's thorough and complete.
It gives me a sense of confidence when writing the apps now.
Agreed yankees. Very good article. Helps clarify a lot of questions and get insight from successful candidates aswell.
This is a very well written advice page. I am pursuing my master's from Indian Institute of Technology and am on the last leg of my thesis for which I plan to add some J2ME support for moodle (moodle.org). Just struck me that moodle also floats GSoC projects and that I can find some mentors.
Hi, I have question How i apply to GSOC with other people to be a team work. Question in another form WE (me and my colleague) have application ,How can we apply with the same GSoC project.
Hi,
can I submit my OWN project topic and choose any of the listed organization for that project topic.
hi ,
Hi,
thanks looking forward for your help..
Hello,
is there anything wrong about that ? and could you advise me of some of the useful skills that I should acquire to have a good chance next year ?
Thanks in advance, MT : mtarek16@gmail.com
...I think we have some spamming from India...that's so wrong...please react...