GSoC Ideas 2009

From Audacity Wiki
Revision as of 12:28, 26 February 2009 by James (talk | contribs) (Benefits of Ninja spelled out.)
Jump to: navigation, search
This page contain our prospective ideas for Google Summer of Code 2009. Follow these links for ideas offered in 2008 and for the five projects that ran in 2008.
For more information about our GSoC involvement please join our developers mailing list. 

Edit hint: This is a draft... It's open to edits...


The Audacity audio editor is downloaded around 12 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 stable release version replacing the 1.2.x series.

So how does this work in the GSoC setting? Well, to get things started there's a Bugfix Ninja project idea proposal from last year, 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.

Generally, do get in contact and discuss your ideas with us well in advance. This greatly increases your chance of being accepted.

NB: We have not yet applied to be part of GSoC 2009, and there is no guarantee that we would be accepted as a mentoring organisation.

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 Ninja

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

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 actually opens up a big can of worms. 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 you've understood both the issue and the code involved.

This a project for someone who is serious about helping the Audacity project. It's less whizz bang than adding a major new feature, or adding part of a major new feature, but it is what we and our users most need at this stage.


  • 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 one of the meatier 'P1 or P2 issues' solved.
  • At least five smaller 'P3 to P5 issues' finally closed.

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

The Release Checklist shows what we are currently battling with to get a stable release out. It's a good place to mine for ideas.