dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Wiki > Main > GSoCOrgApp2013 (compare)

Difference: GSoCOrgApp2013 (r3 vs. r2)

Our organization application for Google Summer of Code 2011

Organization Name:


Organization description:

The Rockbox project is a complete portable digital audio player replacement firmware - including operating system, GUI and application suite. It has been in development since 2001 and receives new features, tweaks and fixes every day to provide you with the best possible music listening experience. Rockbox aims to be considerably more functional and efficient than your device's stock firmware while remaining easy to use and customizable. It is a goal to not only offer a wide range of functionality, but where possible make sure that this functionality is presented in a consistent manner that is easy to learn and use. Rockbox runs on a wide range of platforms including devices from Archos, Apple (iPod), iriver, Cowon, Olympus, Toshiba and SanDisk with more in development. The development team consists of over 50 active committers and nearly 600 individual contributors. See for more information.

Rockbox, from the beginning, has been about freedom. Rockbox makes closed hardware free and open for development by all to do as they wish. At a time when hardware manufacturers are increasingly placing more and more restrictions on devices (especially where DRM is concerned), an open platform that frees these devices and replaces features that have been disabled is needed. Thanks to previous Google Summer of Code projects, Rockbox is staying relevant with the changes in digital audio listening. The "Rockbox as an App" movement began, to provide the same freedom in audio tasks as we have for years past in dedicated digital audio players. This movement has been successful, and Rockbox now runs as an application on multiple smartphone platforms. We have large userbases in the blind community as well. Since Rockbox has a spoken interface, it has provided them with the ability to navigate and listen to their audio on the go. Audiophile users use Rockbox for its many "tweaks" that can be done to audio, to say nothing of our massive audio codec support. Open source and freedom lovers enjoy the ability to make their devices do whatever they wish it to do, as well as get away from many proprietary and closed formats. Rockbox also has developed the most comprehensive collection of open source, fixed point and ARM optimized audio decoders in existence. Our project has optimized more than 30 open source decoders for minimum memory requirements and very high power efficiency on embedded devices. Additionally, we have developed several new fixed point decoders which have been incorporated into libraries such as ffmpeg and VLC, and into mobile phone applications.

Working on Rockbox provides several opportunities that can not easily be found elsewhere. There is work close to the hardware, possibly involving reverse engineering. Other people may prefer working on audio codecs - either porting existing code to work in rockbox using only fixed point calculations, or optimising codecs that are already supported. Students who want to improve their SCSI or USB knowledge and skills can do so. All of this, and much more, is done within the constraints and challenges of embedded systems. We even offer opportunities to work on Android applications. Not just the typical SDK, but also using the Android NDK. There is an active development community, with people who are very knowledgeable in each of these fields and more ready to help others work and learn. We feel that Rockbox provides a unique experience to potential students.

Organization home page url:

Main Organization License:

GPLv2 (Yes, I know we are "or later", however this is the closest thing to what we are on the drop-down list)



Backup Admin:

Zagor, scorche or kugel depending on who submits the app, I assume. -- ThomasMartitz - 29 Mar 2013

If you chose "veteran" in the dropdown above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year:

* I know this is a long answer, but it is especially important to us - please read through! *

We took part in the Google Summer of Code program during the summers of 2007, 2008, 2009, 2010, and 2011.

In 2007, we accepted four projects. The code that was generated was extremely useful to our project as well as to others. Our new fixed point WMA decoder has made Rockbox more useful for our users, was incorporated into the Open Neuros project, and has attracted attention from other groups. We also hope to see it included in ffmpeg once it is mature enough to be merged into their current decoder. Our metadata buffering project led to support for album art in rockbox and paved the way for further improvements in our playback system. Finally, the USB project took some initial steps towards for a flexible software USB stack which (which has now since been enabled completed in SVN for all builds - finally freeing us of having to use the original firmware's USB facilities in many devices. devices). Unfortunately, one project - a text to speech engine - did not succeed. Over all I think GSoC2007 gave us a real boost as a open source project and we learned a lot about the process and how to act as mentors, etc. to bring with us for future years. Pass rate: 3/4

In 2008, we were assigned 5 slots, however we accepted 4 projects (giving one back to the pool) after duplicate resolutions. The first project dealt with localizing plugins to make Rockbox more accessible for blind users and speakers of languages other than English. Even now, there is still ongoing work on this and the student is a committer who has continued to work on this and other projects. The second project was to create an application for a user's computer that would assist theme creators in creating themes instead of simply editing a text file. The work was merged into SVN. The third was a project to create an ARM Emulator that we, and likely many other projects, could use in debugging/reverse engineering hardware. The student essentially disappeared right away and came back during midterm evaluations to tell us that he felt that he should not pass and to apologize for "over committing himself this summer". The last project aimed to make rockbox run as an application on devices like phones, PDAs, etc by providing a frame work for compiling rockbox as an application. The student completed some initial work towards this end, however seemed to grow disinterested in the project and instead devoted his time towards making vast improvements in Rockbox's WMA codec ultimately making it the fastest transform codec on ARM. As this work was not towards the actual project, he did not pass. While this student did not pass GSoC, he is still an active contributor to Rockbox (quite large projects too!), too!) and has been a GSoC mentor later on, so we consider this project a massive success (though not for these metrics). Pass rate: 2/4

In 2009, we were assigned 7 slots, but gave 2 slots back to the pool due to a student pulling out and after having another contribute to another organization for the summer. A more in-depth summary can be found here: . We consider this a definite improvement over 2008. Even though we did again face issues with students disappearing (which we hopefully will improve upon this summer), Rockbox was indeed improved nonetheless. Most of our students from this summer are still with us as committers. Two of our students even seemed like they were going to complete their challenging projects before the GSoC work period even began and improvements are still being made upon their work. For this summer, we decided to accept a slightly riskier project as well that did not turn out as well as we had hoped. New ports of Rockbox can have many risks with it and our student unfortunately became trapped into some of these pitfalls (different hardware revisions, bricked devices, etc). Rockbox gained wider codec support, enhanced USB support, and a few more apps in progress from this summer. Pass rate: 3/5

In 2010, we were assigned 3 slots, however, there was a fourth project that we thought showed great promise. We requested and received a fourth slot to allow the successful project to work under GSoC. The first project was to make it possible to run Rockbox as an application on mobile devices, with a special emphasis on Android. This project was a great success, and although Rockbox is not yet available on the Android Market, many people do use it daily on their phones today. The second project, support for additional WMA audio codecs, was also a success, although since we already support many codecs it was not as visible to end users as the Android port. This project, however, has produced code that has been incorporated into various other open source projects including VLC. In the third project, a nice graphical theme editor was produced. We were less fortunate with the last project: integrating a text to speech system. The project started well, but the student then started hitting some increasingly difficult roadblocks, and then disappeared despite multiple messages, emails, and attempts by our project to keep in touch. This was particularly surprising as this student had been in communications with Rockbox for over a year before GSoC started, so we were relatively sure he would stick around. All three passing students are still active in Rockbox making valuable contributions to both their projects, and other Rockbox work. Pass rate: 3/4

We still had one disappearing student in 2010, so we clearly did not entirely achieve the improvements we were hoping for. Communication with students was much improved however, and we did have regular contact with all students (including the one who disappeared, up to the point of his disappearance). The main lesson we see in our experience from 2010 is that we need to improve on keeping students motivated if things don't go well. We do believe that our screening process is quite intensive and if students make it through the process and we still have a good feeling about them, they should stick around. As we have had issues with disappearing students in the past, we brought this particular case (of the un-successful student) up in the mentor summit discussions, however the general consensus of these conversations is that we did all we could have to keep the student active. We are, however, trying to come up with ways to improve our GSoC arrangements for the benefit of both the students and the project itself.

In 2011, we were assigned 2 slots. The first project aimed at introducing a handle-based dynamic memory allocator, because classic malloc() is not an option for Rockbox. This project enabled, for example, themes with unlimited resources to be loaded and displayed. It achieved successful results with the student still contributing! The second project which was also a success seperated all of Rockbox' audio codecs in to a separate library for use by third party applications. Although there is no known third party application using this library yet the test application created by the student is functional and the build system links this library into the Rockbox binary. Pass rate: 2/2

For 2012, we decided to abstain from participating in GSoC to re-evaluate our committment to the program. We did not apply because we did not believe we would do our students justice for that year. Our org admin sent this email to our development list: . From this "year-off", we have made a number of changes to our outlook. Rockbox development is honestly not as strong as it used to be, and we have re-evaluated ourselves and identified with smaller organizations. GSoC is an incredibly important program and has granted our project many benefits and "fresh blood". While in the past we have aimed for somewhere around 6 slots, this year we are scaling things back and aiming to have 1-2 projects that we can dedicate all of our resources upon. Through this, we can avoid over-extending ourselves and provide an even richer experience to our students.

Our involvement in the project has extended beyond our GSoC projects though. Our org admin (scorche) has been an admin for other orgs as well and has mentored other mentoring orgs to enrich their programs. He also is one of the few non-Googler ops in #gsoc and has helped many in that channel even when Rockbox was not participating in the program. Others in our org have helped spread the word about GSoC? (both in translating flyers, and in giving presentations to local universities).

Why is your organization applying to participate in GSoC 2013? What do you hope to gain by participating?

Being that Rockbox is a project that consists entirely of volunteers, GSoC has had quite an effect on our project. We hope to grow our community of developers through our participation in GSoC and get more people in general involved in the project to some extent. We also hope to have some interesting and useful code contributions from the student projects that will have a positive impact on both the codebase and the users' experience as well as code that is shared by multiple projects in the open source community.

What is the URL for your ideas page?

What is the main development mailing list for your organization?

rockbox-dev at is our main development mailing list - subscription info here:

What is the main IRC channel for your organization?

#rockbox on (though we also have a social channel for community-together-ness)

What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible:

All full committers who volunteer are eligible to act as mentors - final choices will be made after we have a list of student applicants, so that we can choose mentors suited to the specific areas of the projects that are actually being accepted.

The volunteering mentors all have many years experience of both the Rockbox project as well as in depth knowledge of the source code and general concepts - after five years of participating in GSoC, many have been involved in one or more summers as well and will bring that experience to the table.

What is your plan for dealing with disappearing students?

We will have a number of requirements that will be discussed up front with the student and that the student must meet. These include a constant IRC presence, multiple communications with the mentor and the community each week and a weekly summary of the project, completed tasks, and future plans mailed to the developer mailing list. The students will need to join and participate in the community, in the mailing lists, IRC, and forums so that they feel a part of Rockbox and not just another summer project to help reduce the risk of them disappearing. We also probe for possible scheduling conflicts/happenings during our interview process.

Should a student disappear, we will use multiple methods of communication to get back in contact with the student. We have been in this situation multiple times before. The first "semester"/portion of GSoC is incredibly vital and partitipation in it is required. If a student disappears without any warning or communication and reappears before the midpoint, we have a strict no-tolerance policy and will not be able to pass them at midterm. Experience tells us that projects passed under these circumstances almost always result in issues down-the-road. While it is possible for students to bounce back, we feel that it is best to not put ourselves in such a position in the first place.

What is your plan for dealing with disappearing mentors?

All mentors are full committers, who have maintained a long term association with the project. Outright disappearance is therefore vanishingly unlikely.

In case of mentors experiencing unexpected time pressure, we have implemented a multi-tiered support structure for the student. The first tier is, of course, the primary mentor. The second tier is a secondary mentor that will be assigned to each individual project. The third tier is the community itself, whether they be on IRC, the mailing lists, the forums, etc. Except in strictly mentoring duties (such as evaluations, etc), the community will actually be serving as the first tier. This is so that the student experiences more of being involved in open source (interacting with the community, etc) this way rather than just reporting to one "leader" (the mentor). We have a large pool of active and skilled project members that should be able to cover temporary "outages" of single individual mentors. It is through this process that the student will ALWAYS have someone to talk to.

What steps will you take to encourage students to interact with your project's community before, during the program?

We'll inform the possible students that interaction with the Rockbox community will be considered a strong plus when selecting applications. We already have multiple students that have come forward and asked questions regarding their project application. During the community bonding period, mentors will suggest and encourage students to engage in further detailed design discussion about their chosen task if they have not already and will be directed to any documents or areas that they may need to read to learn about specific elements of their project, familiarize themselves with specific areas of the code, or any other such purpose.

Throughout the coding period, mentors will encourage students to make their in-development code available for comment and review on a regular basis. Everything that happens in the Rockbox project happens online, in public forums, etc so we will, of course, assume and insist that program participants join in and follow this set tradition in open source development

What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes?

By mentoring the students into this world and style of acting, we hope that they will see and understand the benefits of working the "open-source" way. We also hope that they will then continue doing so even after the project's completion - perhaps not just in open-source projects, but in their chosen career paths. Many of our students from past GSoC programs are still contributing to Rockbox and/or are involved in our community to this day!

We accomplish this by providing a fun, helpful, and fruitful environment for our entire community. Even past committers who have not been able to make code contributions to Rockbox for some time stay active in our community, as bonds exist.

If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here.

Not applicable.

If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here:

Not applicable.

r3 - 29 Mar 2013 - 17:34:12 - FrankGevaerts

Revision r3 - 29 Mar 2013 - 17:34 - FrankGevaerts
Revision r2 - 29 Mar 2013 - 17:16 - AustinAppel
Copyright by the contributing authors.