GSoC Ideas 2009

From Audacity Wiki
Revision as of 08:00, 19 March 2009 by Galeandrews (talk | contribs) ("accepted to be" > "accepted as")
Jump to: navigation, search
Audacity has been accepted as a mentoring organisation in Google Summer of Code 2009. This page contains our ideas for suitable projects. Prospective students should review all our GSoC documentation listed below and contact us now to discuss their proposal.
For general information about our GSoC involvement, please join our developers mailing list
Related article(s):
  • Remember, write to our summerofcode e-mail address and discuss your ideas with us now. This greatly increases your chance of being accepted.


The Audacity audio editor is downloaded around 18 million times each year. It's a large, mature and clearly popular open source project. In 2008 we participated in Google's Summer of Code. Some very cool additions were made to the code base.

This year, 2009, we're looking for students who will help us with what we now need most. We need the 'beta' (1.3.x) branch of Audacity to become the new 1.4 stable release, to replace the now ageing 1.2.x line.

So how does this work in the GSoC setting? Well, to get things started there's a Bugfix Superstar project idea proposal from last year, a proposal to "de-niggle" (polish) the UI by investigating and implementing many small fixes, ideas for tools to help us release and a skeleton idea for feature completion. You're invited to base your proposal on one of these - or come up with something completely new of your own. Be aware though that this year we are only interested in projects which will bring us closer to a stable release. Also this year we are much scaled back on the number of projects we're geared up to mentor. We have two people able to commit to being mentors versus seven last year, with the rest of the Team able to help out in the way that people on the Team normally do with new contributors.

We expect the students to enjoy the process, as well as enjoying working hard, getting paid and seeing their code in actual use. We're looking for people who will get satisfaction from this, and who are enthusiastic enough about open source and Audacity in particular that they will still want to contribute something to our program after GSoC completes.

GSoC Ideas

Subheadings for each idea:

Possible Mentors These are, in order, the most likely or best mentors for this project idea.
Skills For nearly all project ideas, wxWidgets and C++ programming are essential. Some projects need additional skills too.
Difficulty 'Easy', 'Moderate' or 'Hard'.

Hard tasks can be made easier by solving a simpler problem. That's a decision that needs to be made early on. 'Easy' problems are lower risk. They are better suited to being done in separate smaller pieces if the going gets tough. So take the 'difficulty' grading with a grain of salt. It's only a guideline of how hard we think the problem is.

Early Spinoffs We regard it as vital that projects have early spinoffs that can be completed well within the time. These early spinoffs help to ensure that the code is useful to us. We don't want to end up with 'almost complete' code that we cannot use!

Bugfix Superstar

Possible Mentors:

Description: Various significant bugs and numerous 'minor' issues are preventing us getting a new stable release out. We could very much use help fixing these. Have a look at the priorities on our Release Checklist and our list of "aim to's" which we currently aren't able to progress.

This project would involve fixing - and where possible simplifying - the existing code. This is how established Open Source developers work when they are not adding major new features. You will gain a great overview of all our code in this project, as well as being our "Superstar".

The difficulties for this proposal for GSoC are:

  • The 'plan' showing what you intend to do - particularly so we can assess whether you have done it and you can get paid. Sometimes an apparently small issue reveals wider dependent problems, such as related code that destabilises if the original issue is fixed in a particular way. The plan needs to have flexibility in it. One way to do that is with a 'points system' for the issues, where you say something like 'I plan to have 60 points worth of issues tackled by the half way stage, and 100 points worth by completion'. This allows you to move on from an issue if it turns out to be way harder than was thought.
  • The second difficulty is convincing us that you can work in this way. You'll need to convince us that you've understood some of the issues on our lists and that you can tackle them. Show us you've understood both the issue and the code involved.

This a project for someone who is serious about helping the Audacity project. It may have less short-term excitement than adding or starting on a major new feature, but it is what we and our users most need at this stage, so we have a stable base for adding new features after 1.4.


  • wxWidgets and C++
  • A knack for asking the right questions.
  • Comfortable with visiting many different pieces of code in a large project.


  • Moderate to Hard.

Early spinoffs from this work:

  • At least three of the most significant 'P1 or P2 issues' solved.
  • At least seven smaller 'P3 to P5 issues' finally closed.

UI De-Niggling

Possible Mentors:

Description: Audacity is popular in part simply because what it does, working with sound, is something that many many users want to be able to do for free. It has a generally good user interface, but some would say that the interface is marred by numerous small niggles. These prevent a good program from being a great program - or a great program from being a completely awesome program, depending on how upbeat you are.

This project consists of numerous SMALL tasks, each complete in itself. We're not looking for a UI re-write here. Please read that again. Examples of the kind of small changes needed:

  • Allowing "split new" and "duplicate" to add to an existing track rather than always create a new one
  • Finding out why we can't turn monitoring on by default and fixing it
  • Finding out why Audacity isn't as responsive when many tracks are in a project

We want to make many small changes like this, because though minor in themselves, large numbers of niggles in the program "add up", and so can considerably detract from the overall user experience.

The niggles may not necessarily be already-identified bugs, but real life, day-to-day irritations that need investigating and improving upon. For ideas, take a look at our Release Checklist, and also see Release checklist not aiming for 1.4 and Feature Requests for the many kinds of small practical improvements we haven't had time to make, but could do with your help.

The difficulties with this project are:

  • Keeping the tasks small and self-contained
  • This is a wide-ranging project because it is not about implementing a functionality, but about the entire existing functionality. It involves testing and optimizing all the various areas of the codebase, so you won't be able get cozy with one section of code.
  • Planning the project so that each change will be usable live in a beta. We don't want 'progress' that shows the potential. It needs to actually deliver that potential.


  • wxWidgets and C++
  • Excellent planning skills. That doesn't mean a GANT chart and day-by-day breakdown of work to do. It's more about accurately reporting on what is known-and-understood, and what is unknown and risky in the work to do. It involves enthusiasm to pre-investigate tasks far enough to see what the likely issues are.


  • Moderate to Hard.

Early spinoffs from this work:

  • For this project we expect spinoffs all the way along, not just at the half way stage. In your application you will need to give a clear statement of what you can commit to having done by the half way stage.

Release Tools

Possible Mentors:

  • TBD

Description: Audacity stable releases have help and translations accompanying them. We're using a MediaWiki Audacity Manual Wiki for the help and have an ad-hoc system for the translations.

We can't yet produce html help files from the MediaWiki. There are existing scripts which ought to get us a long way there, but they will need adaptation for our needs. Similarly for translation and creation of the .po files.

Work in this area will ALSO require work on Audacity code itself. It's not just support code. For example there are issues around long help messages, around plurals in foreign languages, and assumptions made in code about word order that just don't hold in some other languages. We're also 90% of the way into transitioning from .chm help - which requires source code changes in Audacity.


  • PHP, wxWidgets and C++


  • Moderate.

Early spinoffs from this work:

  • Either all help-flow issues addressed or all translation-flow issues addressed.

Feature Completion

Possible Mentors:

  • TBD (depends on details)

Description: Identify a feature of Audacity which is in development CVS but is in some way incomplete. A project proposal should describe how the feature would be much improved and brought to release candidate readiness.

Some features we have in CVS that are not yet ready for our stable builds include:

  • Transcription Toolbar - The algorithms for finding word boundaries are rather buggy and slow.
  • Themes - Too difficult to use as they stand, not all items are covered, does not allow theming of backgrounds yet.

Additionally there are features, some of which were added in GSoC 2008, which are usable but which need more polish for a stable release.


  • wxWidgets and C++


  • Moderate to Hard.

Early spinoffs from this work:

  • To be specified in the proposal.

More Ideas

See Release Checklist for an understanding of what we need to do...