Guest post: Google Code-in experience #5 (José)

KDE is once again taking part in Google Code-in this year, a contest to bring 13 to 17 year-olds closer to Free Software. I asked some of our students to write about their experience with KDE. Here’s the fifth one by José.

Many of you may have heard about the Google Code-In. In this opportunity, I am writing you about this, not as an spectator of the contest, but as a participant. As today, I have been participating with KDE, an organization which has a super huge community. Basically, what you have to do here, is claim some tasks (in different areas such as coding, outreach/research, analysis/statistics, etc.) and work on it with your mentors, in a specific period of time designated by them. Once it’s finished, the mentor will approve the work and mark the task as completed. But it’s not only about that, you can win the great prize, which includes a trip to the Googleplex!

Well, participating with KDE has been a great experience until now. In my two tasks (third counting this one) tasks I’ve had with KDE, the community and my mentors have been greatly helpful, which added to my efforts in doing the best possible work, ended up in what I think are great results and work. By doing this I don’t think you may only be able to win the prize, the simple and maybe abstract fact of helping a community, which is the main purpose behind all of this (from my point of view) is what makes your work valuable. Knowing there’s a community and people behind it, thanking you for what you’re doing, only that feels great. I know I may not be able to win the prize, but for me, helping the KDE community is more than enough to be satisfied for the work I’m doing, and I will continue doing.

The two tasks I chose with KDE were done with the Amarok team, which develop a music player in KDE. The first one involved reviewing 30 old bugs to see if I could reproduce them again. So, after some hours of work that involved screenshots, and typing in every single detail I saw, I got it done.

In the case of the second task, I had to do a report on a database that has been storing feedback for a long time. I had to review it, and classify it, making some nice charts about the general and specific statistics of each part of the database, and compare it to the last report, that had been done about a year before. This was a little more complicated, as while in the task, I got stuck in an airport for hours, and couldn’t do much. Anyways, I ended up finishing the task, and my mentors were satisfied and happy because of it. I also learned that people get to understand bar charts better than pie charts!

Anyways, I am 100% sure that the KDE community is more than grateful with all the efforts each person taking a task from them is doing. I would also like to remark the fact that many of you may have been collaborating with some other different organizations, which is completely fine in this case. The organization I prefer after considering many different aspects is KDE, so don’t feel discouraged if I’m talking about a different organization, it’s part of the contest. But overall, I can say that my experience until now has been great, and I don’t regret my choice.

Guest post: Google Code-in experience #4 (Thomas)

KDE is once again taking part in Google Code-in this year, a contest to bring 13 to 17 year-olds closer to Free Software. I asked some of our students to write about their experience with KDE. Here’s the fourth one by Thomas.

Google Code-In 2012 marks the first time in which I have participated in the Code-In or any similar program. Having some experience with smaller organizations and personal development, I did not know what to expect, but I signed up ready to learn and be challenged. Less than two weeks into the program I have completed two tasks (and now a third!) with KDE. More specifically, I have worked with the team behind ownCloud, a personal cloud
service, to help test and design new features for an upcoming release.

My first task was to help test and debug a RSS reader for ownCloud that was actually developed as part of this year?s Google Summer of Code program. The News app runs within the ownCloud instance and allows for each user to have their own RSS reader with multiple feeds. The app was operational, but lacked key features and was too buggy to be released as part of the ownCloud package. My mentor Alessandro Cosentino (zimba12) helped guide me with testing tips and practices. I also suggested features and changes to the existing help to make it more appealing for users. I personally do not use an RSS feed reader, but I found the news app to be easy to use and enjoyable.

My second task with ownCloud involved designing mock ups for a redesign of the software?s application administration panel. The current panel doesn?t use space effectively and has an excessive amount of whitespace. My second mentor Bernhard Posselt (Raydiation) introduced me to Balsamiq, a mockup creation tool. I designed the new control panel with a much more user-friendly features such as drag and drop and contextual menus. The design looks somewhat reminiscent of Google Chrome?s new tab page, with tweaks to make the interface more powerful for administrators. I also had the opportunity to design potential new features such as system-wide settings per app and an integrated app market. Feedback from the designs has been positive so far.

My experience with KDE through GCI has been phenomenal so far. The community of developers who I have had the opportunity to work with have been very helpful and supportive with my efforts to complete the tasks assigned to me. Alessandro, for example, guided me in setting up ownCloud on my own system for testing. Without my mentors? help and guidance I would not be able to be as successful with the tasks. The information and skills that I have developed through these and future tasks are invaluable to me as a student in both my academic work but also when I develop my own software. I look forward to working with the ownCloud and other KDE organizations in the near future as part of GCI and other programs.

Guest post: Google Code-in experience #3 (ctaka)

KDE is once again taking part in Google Code-in this year, a contest to bring 13 to 17 year-olds closer to Free Software. I asked some of our students to write about their experience with KDE. Here’s the third one by ctaka.

“What have I gotten myself into with the Google Code-In?! I’m smart. I get good grades. I’m good at learning stuff. Yet I kept running into little problems on every task. What makes it so frustrating is that it’s basic stuff. I feel like I’m learning to walk again. And look, now I’m talking to myself …”

Ohhhh, the stories my mentors could tell you! Fortunately, the three of them are sworn to secrecy. 😉 [Note: This includes you too, Lydia … although I have yet to do something eye-roll-worthy. But the task isn’t over yet. Just give me time!!! hahaha] What I am at liberty to say, is that working on the tasks and getting things done is very satisfying, but the best thing about the Google Code-In has been getting to know the mentors. KDE has some really amazing people.

My first mentor, who shall remain nameless (hint: his name rhymes with Mascha Sanns!), welcomed questions and suggestions. He laughed at my misconceptions and good-naturedly pointed out reality. He was very patient and appreciative, and it felt great to have my work acknowledged. (THANK YOU, Mascha!) Even after the task was over, he encouraged me to learn DocBook, as it is widely used in industry. So I’m working on that. Lafar, whose name I have so cleverly encrypted (I’m a walking Enigma machine), works for CERN. He may as well have said, “I work on Mount Olympus.” It’s the same thing. Still, he found the time to explain APIs, answer my questions about CERN, and offered very constructive feedback. And then there’s Anne-Marie, who is very efficient at diagnosing problems. It took her all of three questions to figure out what I was doing wrong. Of course, that was after patiently waiting while I muddled through learning to use IRC. Note to others: If you want to chat with someone, don’t bother looking for a nice, big “Click here to reply” box or button. It’s about 5mm tall and is disguised as part of the bottom border. 😛

I’m impressed with how well my mentors communicate in English, and am inspired to continue studying Spanish until I become as fluent. I am aware that they are helping us with Code-In tasks in addition to their regular jobs, and this encourages me to become more selfless. I love the idea of free and open source projects; I had no idea this type of collaboration was going on. Welcoming students to work on their projects makes me feel like the world is not so big and far away, and that we can work as one to advance society. As a result of the Google Code-In, I am developing more than code; I am developing into a better person.*

@ Anne-Marie: Don’t forget our virtual pinkie swear.
@ Lafar: One basket of cookies delivered to your altar every third waxing gibbous moon when the sum of the digits of that day is evenly divisible by 3. Got it.
@ Mascha: Just remember that I have your email address … and I’m not afraid to use it!
@ Lydia: Please disable the mentors’ “reject” button. If they don’t currently have that option (for when students request tasks), you might be getting some requests! LOL =D

*Disclaimer: I have not done any actual coding yet, as I am waiting for winter break and a task I think I can do without causing too much pain to my mentor—HAHAHA. But linguistically, it seemed like the perfect phrase.

Guest post: Google Code-in experience #2 (Sumit)

KDE is once again taking part in Google Code-in this year, a contest to bring 13 to 17 year-olds closer to Free Software. I asked some of our students to write about their experience with KDE. Here’s the second one by Sumit.

“I come from India, where one in every five of the world’s children lives. I come from India, where 400 million children and young people below the age of 18 live; this is larger than the population of America, Argentina and Australia put together. “ – Derek O’Brien

I’m a 16 year old kid from Kolkata. I started learning how to code when I was in grade 7, while stumbling across a few YouTube tutorials on Java. 3 years later, Google Code-In was the first time I was exposed to the world of open-source, and I must say, it has been truly marveling.

My first task with KDE was relating to ownCloud. I learnt how to use IRC and immediately after, got in touch with Michael Gapczyski(MTGap) , my mentor. I encountered many helpful souls in the IRC chat, who were a great resource when the task seemed daunting at first. They helped me understand what the task wanted, and how I was supposed to go about all my work. This was one of the most counter-intuitive things I had learnt in my life. That people will go out of their way to help you out just because you ask. I discovered how truly wonderful the open source community was. But coming back to the task, my job was to write a short overview of describing the different types of apps available on ownCloud. After spending several hours using the ownCloud demo online, experimenting with internal and 3rd party apps, reading source gode on git, I finally began writing my summary. After several proofreads, I felt ready to upload my file online. MTGap thought that my summary needed a little more work, and helped by adding the text to TitanPad, where both of us could edit it simultaneously. After a little more research and some edits, my work was finally approved. I felt proud. It was my first task on Google Code-In, and I was glad it went well. Immediately after, I searched for another task. Maybe it was coincidence, but my 2nd task also ended up with KDE. Once I switched, over to Ubuntu, I downloaded Kamoso, which was the crux of my 2nd task. Kamoso is a program to use your webcam to take pictures or make videos. I fired up Kamoso on Ubuntu and started fiddling with all the features. Once I felt I had explored it fully, I started my task of writing documentation for how to use it. Some problems arose as I never got a chance to speak to my mentor, Alex Fiestas, and even long after I had completed the task, nobody reviewed my work. But it was a very minor issue, for when I inquired with GCI, they immediately spoke to KDE, and my work was approved. KDE was extremely swift at getting my work approved and I was equally contented by the fact that I had now completed 2 tasks. I was enthralled by the experience of open source software.

KDE has given me my debut to open source development, and, hopefully, I have a long way to go from here. I felt a little lost coming into Google Code-In, but I can safely say, I know what to do a lot better, and can take on tasks without feeling ill at ease, and it’s all thanks to KDE.

Links to my work :
ownCloud :
Kamoso :

Thank you.

Guest post: Google Code-in experience #1 (Adam)

KDE is once again taking part in Google Code-in this year, a contest to bring 13 to 17 year-olds closer to Free Software. I asked some of our students to write about their experience with KDE. Here’s the first one by Adam. More will follow in the next days.

I don’t know C++. I don’t know anything about Qt. And yet with the support of Google Code-In mentors, I managed to contribute to a project in a language I don’t know, in a toolkit I am clueless about, in an unfamiliar codebase. And I managed to dive into KDE, even though diving into development can be difficult with so many different tasks to be solved. Google Code-In helps a ton in reducing the initial workload to getting involved with the KDE community. Instead of the titanic mass of the bug tracker there are a few simple, easy tasks that are not too hard for someone like me to get involved and to start solving problems.

One of these problems was in the anagram app, Kanagram. Kanagram simply gives the user an anagram to solve and a button to show the answer. The bug was a simple one in which the reveal anagram button still appeared after the user had either figured out the anagram or solved it. It was a minor detail and yet an important one, as it was confusing to have a button to reveal an anagram when there is no anagram to reveal. This was a minor inconsistency, and becuase of the simplicity of the problem, a good place to start for me. I apt-getted kubuntu-desktop and I was ready to start my first bug. I, being unfamilliar with Qt, turned to Google to try to solve the problem and came up with an idea. I posted it, and the mentor for that task, Laszlo Papp, looked over the code, and told me what I was doing wrong. A few more changes and I had got in working. I reposted it, and again I had a variety of code-style problems. One more iteration and it was accepted. The mentor turned this from what would’ve been a rather frustrating experience to a much simpler and easier one. In addition, once he marked the bug as fixed he continued to talk to me about what I did wrong with integration, further educating me about KDE and C++.

Another great plus to working with KDE is the reality of the problems I’m solving; in short, I know that what I do makes a difference. It may be a tiny bit of QA or it might be the removal of a button; either way, that change I made directly helps people around the world. And it has taken me just a few days to get started with the KDE community with virtually no hassle, beyond some minor kinks with setting up a build environment, though once set up KDevelop + Git really worked well. Even though KDE does a lot of things well there are some problems for a newbie KDE developer. Many of these are tiny details like the lack of a unified account for the wiki and the bug tracker, but in total they pose an obstacle.  Overall the combination of mentors and the list of tasks materially reduces the difficulty of getting started with KDE development.

Guest post: Newcomer experience in KDE and other FOSS communities – Survey

This is a guest post from Kevin Carillo, a researcher I’ve been working with to help us improve KDE’s newcomer experience. If you fit the criteria please do take the survey. It’ll help improve the experience of new contributors and thereby help improve KDE. Thanks!

My name is Kevin Carillo. I am a PhD student currently living in Wellington (New Zealand) and I am doing some research on Free/Open Source Software communities.

If you have joined the KDE community after January 2010 (within approximately the last 3 years), I would like to kindly request your help. I am interested in hearing from people who are either technical or non-technical contributors, and who have had either positive or negative newcomer experiences.

The purpose of the research is to work out how newcomers to a FOSS community become valued sustainable contributors.

The survey can be found at:

A quest for community citizens

KDE is a successful community that keeps attracting new contributors and that has a reputation of being extremely newcomer-friendly. But is this enough to make sure that KDE remains a healthy and growing project?

Suppose a community manages to attract 20 new members every month and suppose a large number of them do not comply to the code of conduct, commit changes without considering the people or modules/components being affected by the commits, do not attend or contribute to any of the community events, do not assist any other members when they seek for help, do not treat other members with respect … It will not take a lot of time until the health of the community will be affected and the future of the project seriously jeopardized.

The main assumption that motivated this project is that attracting new members has become crucial for a large majority of FOSS communities but this is not a sufficient condition to ensure the success and prosperity of a project.

So, yes … it is important to attract newcomers but a community needs to make sure that a certain proportion of these newcomers become ‘good’ contributors from the community perspective. ‘Good’ in the sense that they shall contribute to the well-being and growth of the community. ‘Good’ as good community citizens.

What do newcomers have to say about their experience?

Keeping all that in mind, FOSS projects have thus to do a good job at ‘socializing’ their newcomers and turning them into contributors. Doing a good job here means that FOSS projects shall ensure that they help generate those citizenship behaviors from newcomers by designing appropriate newcomer programmes and procedures.

KDE has a lot of initiatives to facilitate the integration of newcomers with its active involvement in GSoC or SoK, the availablity of a wide array of resources dedicated to helping newcomers, or the use of junior jobs to help involve new contributors.

However, it seems that the other side of the coin is less understood by communities: the actual experience of newcomers.

How are the contributions and the behavior of a new member affected if he or she has received formal mentoring by one or several experienced members? Are junior jobs really helping integrate newcomers? How important is the support of a community towards its newcomers? This is what I am trying to find out.

How is this study going to help KDE?

The data will help gain insights about the experience of newcomers within the KDE community. In addition, it will allow to understand how to design effective newcomer initiatives to ensure that KDE will remain a successful and healthy community.

The dataset will be released under a share-alike ODbL license so that KDE contributors can extract as much value as possible from the data.

Since this survey involves other large FOSS projects such as Mozilla, Debian, Gnome, Ubuntu, or Gentoo to name but a few, it will also be possible to compare practices across projects in order to identify what works from what does not work when facilitating the integration of newcomers.

About the survey

This survey is anonymous, and no information that would identify you is being collected. I expect the survey to take around 20 minutes of your time.

The survey is available at:

It will be available until Tuesday, 22 November, 2012.

If you know members of the KDE community who you think would be interested in completing it, please do not hesitate to let them know about this research.

I will post news about my progress with this research, and the results on my blog: Don’t hesitate to contact me at

How Vidalia and GIMP found new contributors, just by asking

waiting for my ride in this lonely place

The following is a guest post by my friend Asheesh Laroia, who is one of the people behind and other awesomeness on the internet and in real life.

Are there contributors on project mailing lists sitting on the sidelines, waiting to get involved? For GIMP and Vidalia, at least, the answer is Yes.

The GIMP is the famous desktop image editor. Vidalia is a cross-platform desktop app for managing your connection to the Tor anonymity network. Akkana Peck and chiiph, respectively, offered to help new contributors compile the app for the first time and join their communities. The offers created a sense of urgency by naming a specific time to be in the chat room. (Read them: GIMP, Vidalia.)

The point of the event was to find out if actively inviting people to participate could grow the team. I was hoping it would kick prospective contributors into gear, so it was crucial that we named a specific time to be on IRC. I generally hoped the event would prove the existence of a vast, invisible class of contributors: people who aren’t contributing simply because nobody has asked them to. (You can read more about these “Build it” events in the OpenHatch wiki.)

First, the GIMP

Akkana promised that she’d be on the GIMP IRC channel at 03:00 UTC. A few hours early, one person arrived. His motivation was to improve the GIMP Python scripting system:

<kandinski> I would like to help, if possible, with improving python scripting
<kandinski> right now I am writing a script half in scheme half in python
<kandinski> because the scheme has better access to gimp internals, and the python allows me to manipulate the filesystem

It took the attendee some time to download all the dependencies. After 03:00 UTC hit, kandinski began asking development questions:

<kandinski> what happens when you have a but not a configure
<akk> Anything from git, you have to run ./ instead of ./configure

As the build progressed, kandinski repeated his enthusiasm:

<kandinski> I have been looking for a floss project to pitch in to and maybe learn something from

In the middle of the event, Akkana took a break to tell us in #openhatch how the event was going.

<akk> Only one person showed up for it but it’s good anyway — they want to contribute to python bindings (which is something I’ve been meaning to get off my duff and learn about too)
<akk> so we can inspire each other.
<akk> So not a big “class” but worth doing anyway.

As I read her summary at 1am, I was glad that Akkana retained some enthusiasm. But I was kind of embarrassed that Akkana had set aside time for an event with so few attendees.


I have a philosophy about expectations: it’s more okay to disappoint my friends than total strangers. Akkana will forgive me for possibly wasting her time, but I don’t even know chiiph!

So I did a late-night outreach push for the Vidalia event: I sent chiiph’s post to the #gsoc IRC channel, asked people on the #ubuntu-women IRC to help get the word out, and wrote an email to tor-talk, the Tor discussion list. Then I went to sleep.

chiiph’s event was to start at 13:00 UTC. As I slept, he announced the start of the event in the #vidalia room:

<chiiph> and we are on 🙂

At 13:30 UTC, I woke up. The channel was quiet. I had seen people joining the channel before I went to bed; what happened? A little frantic, I pinged one of the people who joined the night before. (My nick is paulproteus.)

<paulproteus> exa: Psst, hi there
<exa> paulproteus: hi :]
<paulproteus> Are you here for the Build It event?
<exa> yep

After a few minutes, chiiph led a group of five prospective contributors through the process of building Vidalia. Many of the attendees were running Debian-based systems, so a simple “$ sudo apt-get build-dep vidalia” was all it took to get their system configured.

Two attendees seemed particularly enthusiastic about the event:

<nishmu> Okay, now I got all things set up now. now moving on to coding.
<jrklein> FYI, I think that this type of meet is a great idea! I’ve been using tor for several years and hosting high-bandwidth tor servers for a year or so now. Haven’t been using the bundle for OSX all that long, but very happy/impressed with it. 🙂

Within a few hours, they had asked for bugs to work on; chiiph and I obliged and found some good tasks for the newcomers. chiiph seemed reasonably chirpy about the event. Later on Friday, he wrote:

<chiiph> jrklein: ah, right, you are an OSX user… we need more of you in here 😀

Going forward

Will these newcomers be converted into contributors and participate in development? That’s now up to the GIMP and Vidalia communities. The most important thing is that the newbies are plugged into communication systems that the developers use. Both projects are quite IRC-heavy, so if they stick around, there is a good chance that they will be put to good use.

I’m interested in ideas to improve the structure of the event. Akkana knew that building the GIMP might take a long time because of a long dependency chain; kandinski suggested that the event invitation provide some steps for attendees to take (like downloading the tarballs of dependencies) the day before the event.

I also learned that doing good outreach for these events makes a world of a difference. Even though the GIMP has many more users than Vidalia, the Vidalia event had many more participants. Vidalia attendees reported hearing about the event through the #gsoc IRC channel and the tor-talk mailing list. For the GIMP, Akkana emailed the gimp development mailing list and posted on her blog, but we could have done more, like reaching out to the gimp-user email list or any of the web forums where GIMP users spend time. Next time, we should make a checklist for event organizers like Akkana to be sure they think through all the outreach venues that make sense.

chiiph learned to be more pro-active about getting people to speak up:

<chiiph> one thing you should comment other people that do this is the pro-active approach
<chiiph> I mean, I was just expective questions
<chiiph> instead of shouting “ask ask ask ask” 🙂
<chiiph> luckily, you came

For me, the whole point of the event is to be pro-active about asking people to join in. I think it worked.

If you read this far, you’ve earned a quip from me. If you work on a free software project and you wonder why your users aren’t getting involved, I’ll tell you: You’re probably not inviting them to take concrete, non-intimidating actions that move them along the path toward contributing. After asking for jrklein to jump over the hurdle of compiling Vidalia, chiiph got more than that: a contributor on OS X.

I want to thank Danny Piccirillo for helping do outreach for the Build It events, and Akkana for chatting with me long enough for us to come up with this idea.

How you can do this, too (and more about OpenHatch)

OpenHatch is an open source community that helps newcomers find their way into free software projects. We work toward this goal through the website and outreach events.

If you want to grow your project, we want to work with you and help that happen. Our wiki has more information about how we ran these Build it events. The best way to get in touch is by joining #openhatch on You can also subscribe to the OpenHatch blog to read our periodic updates.

how making ads for KDE can change everything

This is a guest post from one of our Google Code-in students. Enjoy and watch the video! 🙂

Hello everyone! My name is Claudio Desideri (snizzo) and since the 22nd of November I took part in Google Code-in 2010. I did 6 tasks and worked only with the KDE Community, with promo people in particular. It was kind of a surprise for me to work with videos and multimedia because I’m a quite skilled php coder and so my original idea was to help kde-www. Unfortunately www tasks weren’t available at the time the contest started so I claimed one for a Konqueror screencast. While working on that I felt inspired and for the next task I chose one called “KDE Ad”.

In that particular moment I got the real point of Google Code-in. I decided not to take care of points and timing but I focused only on my work. That decision leads me to spend about 3 weeks just to realize an ad video for KDE in general with my mentor’s help. Then I really started talking with the KDE community and I got in touch with everyone for opinions on my work and I tried to improve myself through that. I’m writing this as my last task too and have to thanks really all the KDE community for what it gave me.

Actually I found any member very helpful and nice with me also when I became a little too pedantic. I did things I’ve never done before, I met very nice peope (especially one girl) during this and I really enjoyed myself. I also undestood the real meaning of “open source project” and gained experience in team work.

Also the main thing I learnt here is: when there is a problem, maybe YOU could fix it, and anyway you’re not alone doing it. And from now, I’ll never leave this community and will work again for KDE because it has been the most amazing experience I’ve ever had in my entire life.

call for 4.6 release parties

A new major release is around the corner and it’s time for all of you to help with KDE release parties around the globe. This is a guest blog by my Google Code-in student Sasu.

It’s been over four months now from previous major release by KDE and it’s time for a new one. 4.6 is about to be released on 26th of January and it is party time again! Release parties are very fun and educational for visitors. If your party has represented KDE well you can even get new local KDE community members.

Although organizing KDE release parties costs some time, it can be a very good experience. Release parties bring the local community together. With a stronger community, organizing the next event will be a lot easier.

release parties, basic info

If your local community is not very big the release party can be just having a beer at a local pub (the writer doesn’t have any experience on that… obviously) with friends. However, if you do have a large local KDE community, you can go as big as you want… and can.

If there are people new to KDE, remember to explain and introduce KDE to them first. Release parties should be fun, that’s the main purpose of them. Parties ain’t parties if you just sit and talk seriously. Participating in parties should be a great experience and worth everyone’s time.

To put it simply, all you need for a party is people at same place at same time. However, you most likely need someone to organize the whole thing. The place depends on party size and program. For smaller events a local bar or restaurant is fine. If you are coming with a bigger group, remember to contact the place and reserve a table. You can also advertise the event at IRC channel topics, microblogging services, blogs and even at Facebook. Most importantly, add your party to the KDE 4.6 Release Parties information page:

You can start by everyone introducing and tagging themself for example. After that you can have a preselected topic to talk about at first. If the event is bigger, you need to have a little more specific program to follow. Talks maybe? Games?

Release parties indicate how strong and active the local community is. According to the KDE Community Wiki, there were 26 release parties for 4.5 in twelve countries including Argentina, Austria, Brazil, China, Czech Republic, Denmark, Germany, Norway, Romania, Spain, Switzerland and the United States. If your country isn’t listed here, like mine isn’t, you can change the situation for this release!

Have nice parties! Organize one now!


Like in the software development, user experience (What now? Visitor equals user for me :P) is the most important part of release parties. At this point, you may want to hear a few words from people who participated in one of many 4.5 Release Parties.

Michael Leupold, where and when did the release party that you participated in take place?
It was held in Stuttgart, Germany. The place is called “Letzte Instanz” and it’s located in Untertürkheim.
How many people took part in the party?
13 developers, translators and users. They came from all over southern Germany.
What did you do at the party?
We enjoyed food, drinks and ourselves. Actual release was unexpectedly delayed till after our event (effectively making our event a pre-release event), we still had a great time talking about KDE and getting to know each other.

Valorie Zimmerman, where you had your party and in what group?
I met with the LinuxChix Seattle, at the Caffé Vita Coffee Roasting Co. on Capitol Hill in Seattle.
How many of you were there? How many of them was a KDE user already?
We had three women attending. I was the only Kubuntu/KDE user.
What did you do there?
We worked on creating a bootable USB key, sipped delicious coffee and nibbled wonderful mini-cupcakes.
Pics or it didn’t happen.
Sorry, I forgot to take a picture.

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