changes in Kubuntu

I’ve been running Kubuntu ever since I decided to switch to Linux on my computers. Kubuntu is what got me hooked on KDE’s software. I was on it’s council for 2 years. It has a special place in my Free Software world.

At FOSDEM I had a long chat with Jonathan. He told me that he’ll no longer be able to work full-time on Kubuntu soon. This was sad news because I know how much it means to him.  For more details read his blog. While this is sad it is also good news. It clarifies Canonical’s position and gives the team behind Kubuntu more power.

I’d like to thank Canonical for sponsoring Jonathan for the past years. It was important for Kubuntu and for KDE. Kubuntu is important for KDE because a diverse distro eco-system is vital for us. Let this be a much-needed wake-up call and take it into our hands.

Hop over to #kubuntu-devel on freenode and see where you can help out for the next cycle.

Something to keep in mind for outreach…

Quote from last night in #gsoc:

<Ophiuchi> The insight that most people in open source didn’t get “allowed” to work on stuff but just didn’t run fast enough at the right moment seems to be rare.

It is a common theme there and also in Season of KDE and in fact any other such endeavor I’ve been a part of.

Whenever you do outreach for your project keep in mind that one of the biggest obstacles you will face is the fact that people think they are not allowed to work on your project. Let’s call it the allowed-trap. You are losing a lot of potentially excellent contributors to it. The reasons for it include:

  • thinking that they are not good enough to make a significant contribution
  • feeling that your project already has enough people working on it
  • thinking that their particular skills are not needed in your project
  • getting the impression that everyone is too busy to take care of a newbie

You can do something about that though: Whenever you see someone falling into the allowed-trap go and invite them personally. Tell them that they are indeed good enough. Tell them that their skills are indeed very much needed in your project. And if you are doing a general outreach event go and address people you want to attend personally and tell them they should take part. Helping someone realize that they are indeed “allowed” here will make their day and yours hopefully too.

PS: Less than a week left to apply for GSoC. Go and apply! You are indeed allowed to 😀

Flattr this

KDE accepted for Google Summer of Code 2011

I’m thrilled to be able to announce that KDE once again will be taking part in GSoC this year. This is our 7th year in the program. Also check out the other 174 orgs – great projects! Let’s make this a rocking summer once again.

If you are a student now is the time to start working on your proposal. You can either come up with your own idea or get inspired by the ones on our ideas page. Once you know what you want to work on start investigating and write your proposal. Get feedback from the team you want to work with regularly. If you want to write a proposal for your own idea I urge you to get in contact with the team very soon to make sure it is something they want and to get input. If you have questions you can always come to our IRC channel #kde-soc on freenode or join the mailing list For details about specific ideas try to contact the respective team directly first via their IRC channel or mailing list please. For more general information about GSoC please visit – pay special attention to the timeline.

If you are a mentor your next steps are: 1) subscribe to  2) sign up on and apply as a mentor for KDE  3) contact one of the admins to approve your requests. For questions you can reach the admin team in #kde-soc or email them at And of course you’ll have students approach you with questions about their proposals 😉  Below you can find a flowchart with the most important steps of the program. Please check the timeline of the program.

Flattr this

Google Code-in – KDE is in!

KDE has been chosen as one of 20 organisations to mentor students for Google Code-in this year. Wohoooooo. We’re looking forward to working with a bunch of 13 to 18 year olds 🙂 Let’s see how they’ll rock our world. And the most awesome thing: It’s not just about code this time but also documentation, outreach, quality assurance, research, training, translation and user interface.

We’ve been collecting task ideas in the wiki. These tasks need to be transfered into Melange (the webapp that is used for GSoC and Code-In) now. So if you proposed a task there I’ll email you shortly with instructions. If you do have an idea that so far is not in the wiki and you’re willing to mentor it then please email kde-soc-mentor-owner at with the details.

The students can then start claiming tasks from different organisations starting 22nd. The contest runs until January. Students can claim one task at a time and have a certain amount of hours to complete it. If they complete tasks successfully they get 100$ for each 3 tasks up to 500$ max. And there is a trip to Google’s HQ for the 10 best students \o/ For more details check out the FAQ.

If you’re a student and interested in taking part in Code-in feel free to hang out in our IRC channel #kde-soc on freenode and join our mailing list kde-soc at if you have questions.

I promise we don’t bite – just like this fellow I met 2 weeks ago on Google’s campus 😛
2010-10-24 11-45-18

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”!

OpenHatch: Making the first step easier

Baby, originally uploaded by gabi_menashe.

(This is a 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. A few months ago, he imported some bugs in KDE’s bug tracker into the OpenHatch volunteer opportunity finder. I invited him to write about it for my blog. OpenHatch has its own blog, too.)

KDE is doing something wonderful with its Junior Jobs. These are issues (often small feature requests) that are appropriate for a first-time contributor. When maintainers create these opportunities, they take information that would otherwise be trapped in their head — how easy or hard an issue is — and make it available as hint to new contributors. Conveniently, creating a “Junior Job” doesn’t take any special work: maintainers just have to find the relevant bug in KDE Bugzilla and add the junior-jobs keyword.

But KDE Bugzilla isn’t necessarily a friendly welcome mat. Probably everyone reading this post can remember a time when Bugzilla seemed like a difficult, arcane tool. Bugzilla works well (enough) as an interface for project maintainers to share the status of what they’re working on with each other.

But imagine you are a prospective contributor. Aim your web browser at the list of junior jobs. (To get that link, I went to KDE Bugzilla and clicked the “Junior Jobs” link on the left side.) This is what I saw when writing this post:

Here are some questions I might have as a new contributor (and some commentary as myself):

  • What do “wis” and “UNCO” mean?
  • Who is JJ? (Maybe that’s a person’s initials; maybe he or she plans to fix it.)
  • What project are these bugs in? (I can guess from the assignee….)
  • Where do I get the source code? (The wrong answer might lead the new contributor to submit a patch against the most recent release; that patch might not apply against trunk.)
  • If I get started on this, who can help me when I get stuck? (Otherwise, a new contributor might make an effort, become confused by something, and fall away.)

I like to joke that bug trackers say lots of information about what the problem is, but they don’t provide any information on how to solve it.

We at OpenHatch noticed that a great number of projects were in a similar situation: they label bugs as “easy”, “bitesize”, or “Junior Jobs” and point first-time contributors straight at the bug tracker. So we created what we call the volunteer opportunity finder to help people find something to work on. It wakes up late at night to download issues from bug trackers representing hundreds of projects. (Since OpenHatch is itself a free software project, we also import the bitesize bugs from our own bug tracker.)

When you browse the available issues, you can click on the project name and see its page on OpenHatch. (We make one for every project that someone says they’ve contributed to, or where we’ve imported bugs for it.) The pages showcase the people who have listed themselves as possible mentors. Contributors can also write instructions or suggestions for how to get involved; for example, the page for Gally does a great job of answering “Other than writing code, how can I contribute?”

If you don’t know how to get involved, you can also browse opportunities by programming language, the kind of help you want to give (such as writing documentation) or flip through a few projects you might want to work on. You can narrow your search to just the ones we call “bitesize” (“Junior Jobs” in KDE, bugs labeled as “easy” in the Python programming language, and so forth).

So OpenHatch is a project to think through how people join free software communities and to build technical tools and social structures to make that better. This browsing tool is one thing we’ve built. It’s a community project, so you can help out! Say hi on IRC or email if you want to join in.

I’d like to hear (in the comments on this post) from you guys and gals: What do you think about our “volunteer opportunity finder”? What works about it for you? What would you change?

If Lydia invites me back, I plan to write about getting non-coders more involved in free software projects. During the weekend I first met Lydia and Jeff Mitchell of Amarok, I had a crazy idea for something you can build on top of OpenHatch. If you want to stay in touch until then, join our IRC channel or subscribe to us on!

KDE SC 4.5 release parties – let’s get them started!

I’m back from conference touring (which was awesome btw – more about that later) and Tom reminded me that the release parties for 4.5 are not planned yet. And the release is planned for August 4th, so in a bit more than a week. OMG!

Clearly it is time to fix this situation and give the world a chance to meet some cool KDE people. So go to the 4.5 release party planning page and check if there is one near you already. If there is one then sign up for it and have fun. If there is none yet it’s time to start one. Pick a date and time (preferably within 3 weeks of release) and reserve a place in a local restaurant, bar, meeting room, university, whateverelsefits. Add it to the wiki page, spread the word and then have lots of fun.

Of course it’s my pleasure to announce the first of hopefully many release parties: Stuttgart, Germany on 7th of August. Exact place and time is still to be determined. Check the wiki page every now and then for updates.

For those who have never planned or attended a release party: You can do pretty much everything you want from simply getting together for a beer and chatting to full day event with talks, workshops and so on. It’s up to you. You can find a few tips on the community wiki. Everyone is welcome from active contributor to interested user. Just let the person organizing it know you’re coming so they can plan better.

It’s been fluffy

I’m back at home from the multimedia and edu sprint in Switzerland (yea the one some people call cheeseland and others chocolateland) and things are finally getting back to normal so time for a bit of blogging. It was productive, fluffy and awesome! Those three pictures sum it up pretty well 😉
view from my room
Check out my Flickr page for more pics.

Having a lot of projects at the sprint was really great. For example I’ve worked with j-b of VideoLan fame on some announcements and website restructuring and helped the edu team with promo and community building advice. A lot of progress has been made on the VLC backend for Phonon which will hopefully solve a lot of the small pain points we still have in Amarok. Besides getting the VLC backend in shape the next weeks in Amarok land will be spend on improving startup time for example. New script bindings by Ian and Richard should help quite a bit with that hopefully. Colin did not have an easy job being the PulseAudio guy but he was a really good sport in not-so-friendly territory ;-). We also had a telephone meeting with the QtMultimedia guys in Brisbane which cleared up quite a few things even though the setup of the meeting was a bit adventurous. Sharing knowledge not only inside the KDE teams but also meeting with other free software teams like this is invaluable and should be done more often.

A big thank you to everyone who helped make it possible. You’re fluffy.

Oh and btw: Car trains rock.

Ada, meet Katie’s posse!

Role models are key to getting more women and especially young girls interested in science and technology and specifically open source. And here are some of KDE’s finest 🙂  Will you be one of them next year?

Ada Lovelace Day, video by fabulous Alexandra

Unfortunately not in the video but still very awesome: Alex, Ana Cecília, Ana, Chani, Claudia, Sabine, Valerie, Valorie, Vera and many more.

KDE accepted for GSoC 2010

KDE has once again been accepted as an org for GSoC. Yay! This means we’ll once again be welcoming a bunch of great students into our team to make KDE software rock this summer.

So what to do now?
If you’re a student who wants to take part in GSoC this year: Go and check out the ideas page and pick one you like or come up with your own idea. Then get in touch with the team working on the program you want to contribute to over the summer. Work with them to write a kick-ass proposal and then hopefully make it reality this summer. To keep up with all things GSoC you can also subscribe to the mailing list.

If you’re a potential mentor: Go and check out the flow chart below. It has everything you should need to know about how we’re doing GSoC this year. Then go and subscribe to the list. Further announcements for mentors will be made there.

If you have any questions please join us in our IRC channel #kde-soc on freenode or send an email to the kde-soc mailing list.

KDE GSoC process 2010