Google Code-in preparation

Google Summer of Code has been a huge success for KDE in the last 6 years. Google is now accepting applications for Google Code-in. It is a contest for high-school students aged 13 to 18. Students can work on tasks in 8 different areas:

  • Code: Tasks related to writing or refactoring code
  • Documentation: Tasks related to creating/editing documents
  • Outreach: Tasks related to community management and outreach/marketing
  • Quality Assurance: Tasks related to testing and ensuring code is of high quality
  • Research: Tasks related to studying a problem and recommending solutions
  • Training: Tasks related to helping others learn more
  • Translation: Tasks related to localization
  • User Interface: Tasks related to user experience research or user interface design and interaction

and tasks are categorized as easy medium and hard. Students will be able to claim those tasks and work on them for a given timespan. After that the mentor can decide if the task was successfully completed or goes back into the pool for other students to claim it. Cool prizes are waiting for the best students at the end of the program.

For KDE to have a chance at taking part in Google Code-In this year we need to prepare an ideas page with a lot of great ideas to claim during the program. Please help me fill this page before Friday: Go Go Go!

If you want to find out a bit more about Google Code-In you can check or come to our info session on IRC this week. (Akarsh will blog more about it soon.)

It’s Roktober!

2010-10-02 13-44-56

It’s getting colder outside and like in previous years it is time for the Amarok team to look back on the past 12 months. It’s been an astonishing ride including over 4000 commits, a Quick Start Guide and 6 new releases of Amarok.

Now this would not be possible without financial support from our users. This is why we are calling for your support during this year’s Roktober again. We are aiming to raise 5000 Euro to pay for our server and the team’s expenses during development sprints and trade shows. You can help us with that. As a sign of our appreciation for your support we will add donors agreeing to this to the About Dialog of each Amarok release in the next 12 months. Help us Rok the World and get your share of Amarok 😉

You can find more detail about how to participate at

A big Thank You! from the whole Amarok team.

When was that football match again?

As you might remember we had these little smiley machines at Akademy in Tampere in the conference area where people could walk by and express how they feel:


I’ve finally gotten hold of the data – wohoooooooo – thanks Matti! 😀

For everyone’s amusement I made a few graphs. Enjoy!

Overall we seem to have enjoyed Akademy quite a lot 😉

Now the really important questions are: When were the football matches? Can you see indicators for the social event, the day trip? Which talks made people happy? When did we get ice-cream? 😀

Designed not to scale

(This is the second guest post by Asheesh Laroia of OpenHatch, an “open source involvement engine”. OpenHatch is a website and ongoing project to help new contributors find their place in free software projects. If you like this sort of thing, you could subscribe to the OpenHatch blog.)

Now we'll never find him   (Explore)

For most open source projects, just one new contributor would mean a huge increase in energy. As a team member, what can you do to find that person?

Typically, we configure computers to converse with prospective helpers. This “scales” — a new contributor requests a page from your wiki or searches the OpenHatch volunteer opportunity finder, and you don’t have to do anything at all. If things work out, the patches flow in.

This time, I want to talk about outreach strategies where human effort is the bottleneck.

Fedora Design Bounties

With the aim of bringing in one new contributor, Máirín Duffy sometimes writes a “Fedora Design Bounty”, a long description of something she could do herself.

Look at the first one and you’ll get a sense of the process she underwent. She created a splashy web page and discussed a specific issue at length (rather than simply linking to a ticket). She singled out a specific task for a newcomer and provided context showing why it was important that the work gets done. In the “What’s in it for you?” section, she explained how you’ll totally be cooler if you do it. Finally, she made it a contest: anyone can try working on it for 48 hours, and if they don’t succeed, the next person in line gets a shot.

Then she crossed her fingers in hope, hit “publish”, and waited anxiously.

In this case, there was an outpouring of response. Within only a few hours, a fellow named Jef claimed the “bounty”, and a few days later, Máirín congratulated him on the success.

From one perspective, her actions were incomprehensible. If she wanted someone to help her, why didn’t she just file a ticket in the Fedora Design Trac? If she wanted to publicize it, why spend hours writing all this up and making a contest when she could have just blogged a link to the ticket?

And all this time, Jef could have applied his design skills to the team’s work by looking for a suitable ticket in the tracker. Why didn’t he?

There are some intriguing aspects of her strategy:

  • Her request for help feels unusually human. She spells out the tools to use and documents to read. That kind of information (and tone) isn’t even appropriate for a ticket tracker.
  • By creating a time-limited contest, she creates a sense of urgency. Hers is an opportunity for self-improvement, not a red “Overdue” marker in a bug tracker.
  • She worked to put her request in front of lots of people. It hit Planet Fedora, Planet GNOME, and her microblog.

And it worked. She’s created lasting contributors. Jef and Emily, the two successful “ninjas”, have gone on to contribute to the Fedora Design Team in other ways. (Jef even landed an internship at Red Hat!)

A supportive environment with friendly people and “borrowed” resources

In college, I led the Johns Hopkins Association for Computing Machinery, our computer club, for a few years. When I was chair in fall 2005, students’ computers in dorms could not run servers; the firewall would block inbound connections to them. One enthusiastic-yet-timid freshman came by and seemed like he wanted to tinker with running a Linux box. The ACM office is a great place for that, and we had spare hardware on shelves. But we were running out of IP addresses, and most existing machines were too critical for me to hand out root access to a freshman.

We lucked out when we found a discarded computer in the hallway. A sticker declared its hostname, We brought it back to the ACM office. Since no other machine was using that IP address, we decided to keep using the address until someone complained. So we plugged it in, installed a fresh OS on it, and he got to fiddling.

Now, five years later, he’s a developer in DragonFly BSD and contributes patches to Ogg Theora, Plan 9, and a host of other projects.

The presence of Linux geeks in the ACM office provided an environment that encouraged asking questions and trying personal projects.

What if the ACM had been inactive? The restrictive Hopkins firewall would have blocked his ability to experiment with SSH and learn about UNIX-like systems. And the spare (albeit dodgy) IP address meant that the ACM sysadmins were never tempted to re-purpose the machine to serve the entire ACM membership.

(Also, I think that IP address is unused again…)

What I take from these examples

Fedora Design Bounties and incubating students in the computer club are time-intensive activities. At a great amount of effort, locked within a short period of time, they reach a tiny number of people.

But for that small number of people, they can have a huge impact.

For a project leader like Máirín, one new contributor can boost the energy level of the community. With that as her goal, working hard to find that new contributor makes perfect sense. I believe there are other projects in similar situations, so Danny Piccirillo and OpenHatch are incubating a similar project called Starling Bounties. To prove to the community it can work, we’ll take on the writing effort.

For me, watching people “get it” has always been rewarding. Not all students have access to a support network knowledgeable about open source. So this past weekend, I visited the University of Pennsylvania to try to create one there. With help from other teachers, we gave 30 students hands-on instruction in GNU/Linux, IRC, git, and other concepts key to open source participation.

These mechanisms can only grow as fast as humans pour effort into them. When you want a substantial change from someone, a costly signal shows dedication.


After reading all these words, you must be exhausted. Go get yourself a glass of water.

For you lovely readers who stuck it out this far: What do you think of the Fedora Design Bounties? Would you be interested in trying a Starling Bounty with your own project? And I want to hear about the fun things you do to help grow the free software community, even if they “don’t scale”!

Next Community Working Group Office Hour


Since the last Community Working Group office hour was well received we decided to continue with them. The next one will be on Saturday, 09 October 2010, 18:00:00 UTC in #kde-cwg on freenode.

Please join us and ask whatever big or small community related question you have or get feedback on your ideas.

PS: We will of course continue to be available via email and private chat for urgent/sensitive matters.