How to write a kick-ass proposal for Google Summer of Code

In a few weeks students can begin submitting their applications for Google Summer of Code 2012.

KDE is applying to be a mentoring organization again this year, and I’ve already been contacted by several students looking to do a Google Summer of Code project with KDE (and specifically Amarok in my case). Prospective Summer of Code students usually have lots of enthusiasm, and they often write great proposals with little or no help, but sometimes these proposals might not be structured so well or lack key information.

I’ve been a Google Summer of Code student with KDE three times (four if you count Summer of KDE) so I’ve been in the very situation prospective Summer of Code students find themselves right now. I’ve also been on the other side of the fence: I haven’t been a Google Summer of Code mentor yet, but I have mentored Google Code-In students and I’m a professional software engineering instructor (since 2008), so I like to think I can relate with both students and mentors in this case.

This post is for students who wish to take part in Google Summer of Code.

Google Summer of Code is a kind of like a scholarship program, and a very competitive one: if you get picked, you’re one of just a thousand students in the whole world (1075 last year, 51 of those with KDE) who get to spend their summer hacking on Free Software while learning from the very best hackers, and get paid for it too! In order to do that, you need to submit an application to Google. An application is essentially a bunch of information you enter in a form, the most important part of it is your proposal.

A Google Summer of Code proposal is a document, it can be rich text but it’s best to consider it a plain text document because the web application that handles proposals has only basic formatting features.

The KDE community maintains a wiki page specifically targeted at Summer of Code students with very useful information on how to get started. Read it. Really, read it, please. Yes, all of it Done? Great! Assuming you’ve gone through points 1-3 of the Recommended steps list, it’s time to prepare your proposal.

Writing a good proposal is not easy, especially if you’re a student making first contact with an organization, in this case your proposal is your best advertisement. You have to convince the organization (or at least some key people inside it) why YOU are the right person for the job! What follows applies to KDE, but it should work for other organizations as well.

I used to structure my proposals the following way (worked well 3 times). It’s not a rule! You can structure your proposal otherwise, but I think this is a good guideline if you need some inspiration:

1. Introduction. Every software project should solve a problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. This is somewhat like an elevator pitch.
2. Project goals. This section should again be short and to the point, and it might be a good idea to format it like a list. You should propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the three months of Google Summer of Code term is what counts.
3. Implementation. This section can be longer and more detailed. You should describe what you plan to do as a solution for the problem you defined earlier. You don’t need to provide a lot of technical details, but you do need to show that you understand the technology and illustrate key technical elements of your proposed solution in reasonable detail.
4. Timeline. This section is easily overlooked, yet it’s arguably more important than the previous section. With the timeline you show that you understand the problem, have a solution, and that you have also broken it down into manageable bits and are have an actual plan on how to approach it. With this section you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is much better than a timeline that promises to move mountains. Mentors can spot unrealistic timelines.
5. About me. If you’re done with the other sections this will be a piece of cake. Just put down your contact information and write a few sentences about you and why you think you’re the best for this job. It’s ok to brag a little

Overall, submit your proposal early, keep it short but include all the necessary information. Get it reviewed by the right people in the organization, well before submitting it to the Google Summer of Code web application. In KDE’s case you should submit your proposal to the contributors’ mailing list of the relevant subproject as published on the ideas page. I can’t stress this enough: get feedback. Organizations want good proposals and good students, and are usually eager to help you improve your proposal. Just write a brief and informal email, attach your proposal and ask for feedback. No need to write “Dear Sir” and such, we’re cool

I hope this advice proves useful. We have also gathered some accepted proposals from past years, you might find them useful as inspiration.

You can submit more than one proposal to the same organization or different organizations to increase your chances, but don’t overdo it: quality is better than quantity.

Good luck!

 

Amarok 2.4.3 “Berlin”

So fine, we skipped a number!

As you may remember, the last beta release was 2.4.2 beta 1. After that, we did roll a 2.4.2 (final) tarball, but because of some issues which were fixed right after the tag we decided to make another tarball and call it 2.4.3.

That being said, I’m happy to announce the immediate availability of Amarok 2.4.3 codename “Berlin”.

So, what’s new in this release?

There’s a whole bunch of UI tweaks with the aim of making the main window less crowded. The 90s called and they wanted their status bar back, so we ditched it and replaced it with relevant notifications where necessary, recovering a bit of vertical space. Also, the Dynamic Playlists feature has undergone an overhaul which should make it easier to use. A bit of work has been done on Internet Services and Podcasts. Moreover, we have accepted quite a few patches from external contributors, and we have squashed lots of bugs, both during the Randa sprint and after.

Read the full announcement here.

 

Amarok 2.4.2 Beta 1 “Nightshade”

Summer in the northern hemisphere is not an easy time for the Amarok team, 35°C in the shade is definitely not the ideal operating temperature for most hackers. Nevertheless, work on our Google Summer of Code projects and regular Amarok development is proceeding at a frantic pace.

GSoC projects won’t be merged and released until later, so what we are releasing right now is a beta release of what we have cooked up during the spring, including the Amarok sprint in Randa, Switzerland.

Prominent changes include several redesigned user interface elements and dynamic playlists, and a significant number of bug fixes.

Read the full announcement here and don’t forget that to make Amarok 2.4.2 even better, bugs.kde.org is the place to be

 

GSoC: Beginning Amarok Mobile

When the Google Summer of Code program was announced again this year I decided to submit a proposal for a project that would hopefully take Amarok in a new and interesting direction.

My proposal was accepted, so this year I’m a GSoC student again, for my third time, working on an Amarok port for mobile devices, primarily tablets.

Why mobile? In the past few years some profound changes have been set in motion in the computing market. What we still call “desktops” might soon become mostly workstations and gamer rigs. We’re not there yet, but computers are already becoming increasingly mobile, invisible and wearable, and computing is becoming ubiquitous. In this changing environment, complex desktop apps like Amarok 2.x will have a harder time staying relevant, and are being challenged by leaner, simpler and flashier mobile counterparts.

Amarok has a strong brand and a good reputation as the ultimate music player for GNU/Linux systems, prominent features where Amarok innovates and excels are web services integration and smart context-sensitive information. I believe the Amarok team can take advantage of that and make a successful entry into mobile markets.

There is certainly a lot of work involved: the existing GUI simply would not work well on touch screen devices, and a lot of the underlying stuff is also not so well suited for a mobile app because it provides a very extensive feature set and requires a lot of dependencies.

The foundations for a mobile version were laid down about a year ago, when Amarok developer (and my GSoC mentor) Jeff Mitchell made some deep changes to separate Amarok’s core logic from “everything else”, including collections, the user interface, etc. However, not much happened after that besides maintaining this separation, so I simply figured that if we indeed want to see Amarok running on tablets and handsets the actual porting work had to begin.

So what am I aiming for? At this point, a platform that is accessible almost immediately is MeeGo (and Maemo 6), represented by the upcoming Nokia N900 successor and Intel x86 based tablets, as well as devices which come with other operating systems out of the box but have a MeeGo port. While during this GSoC project I’m focusing on MeeGo, when making technical decisions I will be taking into account their impact on possible future ports to other platforms.

This port will require a completely new GUI, but since I’m not a QML GUI designer (yet), so far I’m only promising to deliver the underlying stuff.

Until now, I’ve done a bit of work on yanking out Amarok’s core and building it with a minimal set of dependencies, and setting up a MeeGo development environment. The next step will be porting this core to MeeGo, and then building the required functionality on top of it while keeping the whole app light but smart

 

Amarok 2.4.1 “Resolution”

Building on the foundations of a fun and innovating 2.4 release, the Amarok team is proud to announce the immediate availability of Amarok 2.4.1, codename “Resolution”, the first maintenance release of the 2.4.x branch.

Many bugs have been fixed, and we even managed to sneak in a few new features, including remote NFS/CIFS collections and a gpodder.net service.

Check out the full release announcement here to see what’s new in this release.

 

Amarok 2.4.1 Beta 1 “Ringscape”

Hot on the heels of a great 2.4.0 release, the Amarok team is proud to announce the immediate availability of Amarok 2.4.1 Beta 1, codename “Ringscape”.

Aside from the usual load of bug fixes, this beta release brings several new features, such as a new preview mode for the Organize Collection dialog, integration with the gpodder.net web service and remote NFS and SMB collections.

This is a beta release, which means that although it’s quite usable for daily use, it might still contain serious issues, eat your chocolate brownies, melt your ice cream or set your microwave on fire. Read the full announcement here and if you wish to help us make Amarok 2.4.1 even better, please report any new bugs you encounter at bugs.kde.org.

 

Running KDE SC on the next big thing

A week ago I got a Tegra 2 based 10.1″ Android tablet called Point of View Mobii Tegra. Its brand is just badge engineering, the same device is sold throughout the world under a variety of other names, including Advent Vega, Smartbook Surfer 360, WSL Xvision and Dreambook ePad P10, and apparently it is based on a reference design by Nvidia. The hardware is quite fast but the bundled Android software feels, well, a bit weird. I say “weird” simply because Android 2.2 is an operating environment for handsets rather than for tablets, and while it’s fast and it does the job, it is hardly the best tool for the job: compared to a smartphone’s 3 or 4 inches, 10 inches of touch screen provide a lot more space for all sorts of touch-friendly widgets and a call for a somewhat different user experience. This is especially noticeable when looking at common widget placements on the screen: Android often expects you to hold a smartphone with one hand, and places relevant widgets close to where your thumb should be. These kind of assumptions fail miserably when running Android on a 10″ tablet.

Anyway, like a true fan of KDE my priority was trying to figure out if there’s a way to get KDE SC running on it in some form. This was remarkably easy, thanks to the efforts of some MoDaCo community members, who provided an Ubuntu-based rootfs and a kernel. All I had to do was figuring out how to flash the device with Nvidia’s tools the right way. After that it was just a matter of installing some KDE software from Ubuntu’s armel packages.

My PoV Mobii Tegra (Advent Vega) running KDE SC 4.6

So the point of this post isn’t technical, it really didn’t take much to have a KDE desktop running on the Tegra tablet. It’s just a bit of proof that it can be done.  The user experience with the regular Plasma Desktop is surprisingly fast but overall not very good, and Plasma Netbook doesn’t make it much better. The UI feels too small and is not well suited for use with fingers. I suppose it would work somewhat better with a stylus, but that’s not what these kind of tablets are about. I haven’t had the chance to try Plasma Mobile yet, but even if it brought a huge improvement, I would also need finger-friendly apps.

Right now I can see that there’s a vacuum in the tablet market as far as operating environments are concerned. Android is obviously late to the party and WebOS and MeeGo even more so. Could this be an opportunity for KDE?

A sensible beginning might be designing a set of finger-friendly widgets and a Plasma workspace optimized for 10″ and 7″ tablets, and defining a list of UI guidelines for tablet-friendly KDE apps.

 

The importance of mentorship in Google Summer of Code

I’ve been asked by Lydia, the ultimate social media ninja of KDE and Amarok’s community manager to put together a brief post about my opinions on the importance of mentorship and organization in a student outreach program such as Google Summer of Code based on my experience as a GSoC student. I’ve been a GSoC student twice and a volunteer Summer of KDE student the year before that, so I hope I can provide some insight from a student’s point of view. The KDE GSoC admins&mentors team has done a terrific job so far, and I’m very satisfied with their performance. Thank you, GSoC admins&mentors!

I have tried to gather a list of situations where as a GSoC student I could greatly benefit from good mentorship:

• Planning. While I surely did have a vision and a somewhat clear direction where I wanted to take my project, I wasn’t always sure about the details of the implementation, and specifically how and where to tie my stuff in with the existing codebase. My mentor helped me a lot with planning and design, and we shared a design document in Google Docs that was to be kept up to date for the duration of the GSoC program. I believe that while the strong motivation of a student pushes the project forward, the direction has to be overseen and frequently discussed with the mentor to make the student’s project useful for the organization and to avoid rookie mistakes when laying out the design.
• Code review. When I started with GSoC I was very much a noob about Qt and I didn’t have a lot of coding experience. Regular code review by my mentor and the other team members was very important to improve the quality of my output. I believe that at least occasional code reviews in the first weeks of the GSoC program (unrelated to the final review before merging the branch) can straighten out important details before they become serious issues later on.
• Team interaction. When I started with GSoC I didn’t know anybody in the Amarok team. I didn’t know anything about the social structure and most importantly, I didn’t know which team member I should poke about specific parts of the codebase. In those times it was very important for me to have someone (mentor, community manager) to ask questions such as “Who has knowledge about this bit of code? Can I make change X on code Y or would that make person Z angry?”. I did ask those questions pretty often.
• Technical questions. The life of a GSoC student can be pretty intense, between coursework, exams and coding. For this reason, while my output was quite consistent, coding could happen at any time of the day. I’m very grateful that my mentor Nikolaj Hald Nielsen was almost always available to answer my questions, and when he wasn’t, there was a clearly appointed second-in-command I could go to. This is perhaps the most important entry in this list. Rules such as “the whole team will mentor you” or “ask in the IRC channel and someone will answer” just won’t do with first time students! I know I wasn’t very comfortable with asking just any question in IRC, especially if I felt that the answer could be something that “anybody ought to know”. Sometimes I just needed a confirmation to make sure I was doing the right thing.

To sum it up, I believe that KDE has a great admins&mentors team, and I can testify that also because of this doing GSoC for KDE was a very rewarding experience.

However, it has come to my attention (also during this year’s Google Code-in) that for the fairly small admins&mentors team a large scale student outreach program such as GSoC creates a huge workload.

KDE contributors are encouraged to help with the organization to make the recently announced GSoC 2011 the most successful GSoC ever: feel free to add your ideas to our GSoC 2011 ideas page, and if there’s an area of KDE you know well, why not be a mentor this year?

The KDE GSoC team is looking for good mentors with lots of cool ideas, and especially if you’re a former GSoC student and you’re not a student any more, you might be the perfect candidate to become a GSoC 2011 mentor. To apply as a mentor visit #kde-soc on Freenode.

 

Amarok 2.4 “Slipstream”

On behalf of the Amarok team I’m pleased to announce that Amarok 2.4 codename “Slipstream” has just been released.

This release finally brings some of the Google Summer of Code stuff we have been blogging about a few months ago, many new features, as well as many performance and usability improvements. We are especially proud of the new, completely rewritten and much more reliable collection scanner, and I’m personally very happy to be able to show/hide the menu bar again

Check out our release announcement to learn what we’ve been up to for the past few months.

 

 

What to do with an old Nokia N810?

Like quite a few KDE community members who attended Akademy 2008, I got a Nokia N810 internet tablet. Sadly, shortly after we got the devices we stopped receiving OS updates and the Maemo Diablo platform was basically abandoned in favor of a bigger better faster and quite different Maemo Fremantle, to be used on the N900 with the hope of eventually having a community supported port for the N810. Unfortunately, the Mer project, which aimed to bring as much Fremantle as possible to the N810, was cancelled back in 2009, leaving N810 owners with a nice piece of hardware and a dead software stack.

Don’t get me wrong: while the browser is still slow as molasses and the battery drains quite quickly when WiFi is on, Maemo Diablo works, but it’s not moving and in 2011 it’s not fun any more. Lately I’ve been using it just as a music player and rarely for quick note taking or Skype over WiFi.

So thanks to the efforts of the Nitdroid project, I installed an Android 1.6 Donut build on my N810, hoping to get something fun to tinker with. Even though Donut is old, it might still have been an improvement over Maemo Diablo. From what I’ve picked up, the Nitdroid project is focusing on the N900, and I can testify that Android on the N810 is unusably slow.

I have managed to open Planet KDE on my third attempt, the first two times stuff just crashed randomly:

As for MeeGo, a fellow Amarok developer says it’s slow even on the N900, so does it even make sense to try running it on the N810?

What are my options if I want a fun, fairly recent and at least a bit usable system on my N810?

I know people even managed to run KDE on it, but is it fast enough to be usable?

What do you use your N810 tablets for in 2011?