|Google Summer of Code (GSoC) is Google's program for promoting Open Source Software development. Audacity was a mentoring organization for five students for Google Summer of Code 2008, and mentored two students in 2009. This page answers the most common questions we're asked by potential GSoC students. Also see Google's own comprehensive GSoC FAQs, and the GSoC 2009 Timeline.|
|For information about our future plans and about Audacity software development, please join our developers mailing list|
- 1 Basic questions on GSoC and the application process
- 2 More detailed questions
Basic questions on GSoC and the application process
What sort of projects can be chosen?
For Audacity this year we want development that will help us get to a new formal release. Some very helpful suggestions can be found on our GSoC ideas page.
We know that most programmers will be wanting instead to add one big new feature. Well, in our opinion there is as much if not more creativity and skill in the 'less glamorous' side of development. The fact that we expect fewer people to apply as a result of our focus on quality this year means that people who are interested will have more chance.
The organisations and projects that were offered in 2008 can be found here:
How much time per week will I need to put in for Audacity?
We want you to treat it like a full time job. We have some flexibility, in that it is results rather than time that matters, but for Audacity don't plan to be doing a full time job or writing up your thesis and GSoC in your spare time.
What level of technical expertise is required to participate in GSoC?
The level that could reasonably be expected of better than average computer science degree students after their first year. Realistically, given that GSoC is competitive, we'd regard the minimum programming skill to be such that at least one programming project of 1000+ lines should have been completed as part of coursework. Applicants should mention at least one significant program they have completed on their application. If you don't enjoy writing and debugging programs, don't apply.
We're not expecting students to already be familiar with the speciality of sound processing for Audacity work, or with writing GUI code, or with audio file I/O, or with preferences etc etc. We are expecting somebody who will 'have a go' at any of those, calling on expertise from the team as appropriate.
What is the role of mentoring organizations?
See Google's GSoC FAQ for precise details.
- We select the applications we like the best.
- We provide a mentor. The mentor is there to advise on implementation choices, making sure the student has the information they need.
- We, particularly the mentor, evaluate the work and confirm to Google that the student has done the work satisfactorily, which is the basis on which Google pays the student.
- We help as best we can via our developers' mailing list.
How do I make a "good" application?
Whatever mentoring organization you choose, the best way is to get in contact with its developers and discuss what you would like to do as a project with them. Do this well in advance of sending in your application. The results of that discussion will lead to a much stronger application. To discuss your project ideas with the Audacity developers, please write to our summerofcode email address.
Expect to revise your application in the light of comments from potential mentors. We'll need evidence from you that you have compiled Audacity and made some small experimental change, ideally addressing some known issue. We'll expect you also to join our audacity-devel mailing list and take some part in our development discussions. That list is also the place to get help compiling Audacity first time around - that's what happens with experienced developers joining too.
To write that winning proposal, think first and foremost about what selection criteria the mentors will be looking for. Second, include concise details of all your relevant academic, industry, and/or open source development experience, and of your proposed development methodology. The following are worth a read:
- How To Write the best Application in the Pile
- Inkscape SoC Selection Criteria and Writing Project Proposals
- Google's Advice for GSoC Students page
More detailed questions
These are brief answers to some of the more detailed questions we've answered on audacity-devel mailing list. Have a look at our audacity-devel archive to check all that's been asked and answered about GSoC. If you have a question you can't find the answer to, please ask us as soon as possible.
- Q: Am I good enough for GSoC?
- A: Convince us you are! If you give us evidence that you've compiled Audacity and then made some modification to Audacity, you're ahead of most people.
- Q: Where can I find out about the architecture of Audacity?
- A: Look on this Wiki in ArchitecturalDesign and then at the pages in the For Developers category.
- Q: I don't know wxWidgets. Is that a problem?
- A: wxWidgets can be learned very quickly. See their documentation, including a 700-page book: Cross-Platform GUI Programming with wxWidgets (this is also available as a PDF download). If you've not used wxWidgets before, spend some time getting familiar with it, so that knowledge shows in your application. If you're unsure, talk it over with us.
- Q: How do I fix this compiler error that I see....
- A: Check our compilation instructions and the Windows and Mac compile.txt files in the source code if you have not already, then ask us on audacity-devel. Asking questions about getting Audacity compiled won't harm your chances. It shows we don't need to worry about you getting stuck and not letting us know.
- Q: I want to tackle this HARD problem from your ideas list. Is it too hard for me? Is it even possible?
- A: Only you can tell if its too hard for you. We believe the basic idea is perfectly achievable by an advanced student. Talk it through with us, and spend time understanding the problem. Convince yourself you can do it, so you know how much to offer to do, and then convince us you can. Beware of not giving us evidence that you can compile and modify Audacity whilst you focus on the harder stuff. Beware of not giving us evidence that you can interact with our community.
- Q: I would like to do THIS project from your ideas page. Has it already been taken? Is there a mentor for it?
- A: Until the application deadline there is no such thing as a project being 'taken'. As you will have seen from our Ideas page we are mainly interested in getting our next formal release out. If your idea does not address that then you are very unlikely to get chosen. We have mentors for listed projects.
- Q: I've not written a program with more than 1000+ lines before. Is that a problem?
- A: Yes. Talk it over with us. There may be a way forward all the same. What we really need is evidence that you will be successful in your project. If you're relatively inexperienced and also leave contacting us to the last possible moment, there's no chance at all.
- Q: I've posted an application using the GSoC Student Web app, and I'm being asked to clarify what features I'm committing to and what features are optional 'if time permits'. What does it mean to commit to a feature? Does it mean I'll fail if I don't deliver a feature I commit to?
- A: At the application stage we need clarity about what you expect to achieve. What you commit to is what we expect to see, and the committed to outcomes need to interest us. If we fail a student who committed to a feature and then didn't deliver, it would usually be because they'd also claimed skills/experience they didn't actually have, not submitted status reports (at least weekly), or otherwise not kept in touch with us throughout their project. We pretty much don't expect the 'if time permits' features to be done, as everyone underestimates how much work is involved in programming. In discussing the proposal we might ask that an 'if time permits' feature be made central and a planned feature we're less interested in be demoted.
- Q: I want to send in some source code too, along with my application. Do I send it with the application or do I link to it?
- A: Clear bullet points are often better than pseudocode to specify what the code will do. Real code should usually be hyper-linked to, and in your application make sure to tell us if it already runs in Audacity or is a separate program. We currently have some questions for Google about content that is linked to - can we access it when we browse the mentor app, or does it change after the application deadline? - so use it for evidence to back up your claims on your proposal, rather than for content that absolutely has to be read for your proposal to have a good chance.
- Q: Do I really need a gmail (or googlemail) account?
- A: Yes, we require this, although other mentoring organisations do not, and it's not required by Google. We can fail an applicant if we don't get a prompt reply to emails, so we want to reduce the risk of this being due to an unreliable service provider. If you're blaming gmail for your failure to communicate, Google have the option of looking into it if we ask.
- Q: I'm pressed for time. Is there a simple way to keep up-to-date with what's going on with Audacity and GSoC?
- A: If you're too pressed for time now, will you be too pressed for time to participate properly in GSoC during the time it runs? We expect you to treat GSoC like a full time job during the time it runs. In terms of keeping up to date with audacity development, you need to subscribe to audacity-devel.