Over the weekend, I had the opportunity to attend Ohio Linux Fest 2012 in nearby Columbus, Ohio.
KDE developers are apparently photo OPs
I had also attended the year prior, where I had a very strange experience. Up ’till then, I had only ever been surrounded by developers and other like-minded people who already “get” KDE, what it means to use free software, and how to get involved. Thats great and all, but Ohio Linux Fest is a convention for the users. There, I was one of maybe three other FOSS contributors that I recognized, and even then I didn’t really know anyone. There, it is incredibly uncommon to meet anyone who actually slaves over a hot vim session to churn out code and put together your working distributions. Meeting a developer, even for something as small as phonon-gstreamer is a humbling event from what I could gather.
This year, our closing keynote was How to Create Ravenously Passionate Contributors by Angela Byron. Her talk explained how she got involved in free software, how she keeps people around in Drupal, and an overview of how their community works.
If you have a look at our Ohloh stats, commits and contributors are down significantly in the past 12 months. I’m sure there are dozens of good reasons why, but the question here is how can we get more contributors?
Angela’s talk discussed some very good points, all of which have parallels to my own path from being some highschool kid wanting to get involved but not knowing how, to being a KDE contributor.
Overview slide from @webchick's talk
The above slide was towards the end of the talk and summarizes things very nicely. I’m going to attempt to apply what I learned at the talk to KDE:
Corrupt Young Minds
This point is aimed more towards getting more people into the field of free software in general. If you’ve got kids, you need to sit them down in front of a computer with KDE installed and tell them to go crazy. They’ll beat it up, they’ll break it, and they’ll fix it. Throughout all that, they’ll learn and discover what it takes to get involved.
Destroy Einstein
A major misconception about free software, is that you need to be a genius to contribute. Only senior software engineers who write code exactly right the first time make free software happen, right? Wrong. Behind every line of code is a dedicated team of people who works hard to make it happen:
- Sysadmins, who maintain the git repos, reviewboard, cia hooks, IRC channels, and who knows what else.
- Documentation writers, who explain how things work in easy terms.
- Packagers delivering released software into the hands of users and developers who don’t like to run kdelibs from git (i.e. me)
- Artists and designers drawing awesome icons, desktop themes, making usable interfaces and websites.
- PR teams writing up press releases, taking screenshots, getting the word out.
- Community managers making sure everyone plays nice.
- Testers and triagers to keep bugzilla clean of fluff, duplicate reports, and to make sure that the software doesn’t crash and eat all your cheese.
I’m sure there’s more, but no single person can do it all or even knows how it all works. I’m really not sure what goes into running Akademy or Roktober, but I know there are people within our community who make it happen. They are everyday people who aren’t Einstein and are essential to our success.
Mentoring++
This is also a critical component of gaining new developers. Google Summer of Code is an absolutely wonderful program, but we can’t rely on it to gain new contributors. If an interested person is not a student, they still should get some mentoring. KDE has had an informal mentoring program for a long while. I just learned about it last month. We also have an awesome book on how to develop for KDE. Both of these need to be pushed more by current contributors.
Mentorship doesn’t need to be hard, either. If you’re mentoring someone, just take a few minutes out of your week to poke them and see what they’re up to. Sometimes that little push is all that is needed to show that their contributions matter. Ego stroking is a good thing.
Full-frontal nicety
What this means is that all of our public communication channels should be welcoming to new contributors. If something nasty is going down in a mailing list, IRC channel, or wherever else, don’t just let it happen. It sends the message that this kind of behavior is supported by the community.
Fail early, often, and in public
Far too often, a newbie’s mentality is that in order to contribute to a project, they need to do it perfectly on the first try. Real contributors don’t do that. We make and fix mistakes all under public scrutiny. We’re only human, after all. New contributors should be taught that the best way to become part of the community is to actively participate. Here are the two approaches to contributing to Drupal, taken from Angela’s presentation:
| Perfectionist |
Mere Mortal |
| Find a bug |
Find a bug |
| Spend a few days learning the project and developing your patch |
Contact the maintainer(s) on IRC, asking for some pointers |
| Review the patch a few times to make sure it follows the documentation standards, code formatting, krazy doesn’t complain, and all that jazz. |
Someone points them in the right direction, explaining the issue in detail and happens to have some semi-working code available for them to build upon |
| Submit the patch |
Contributor submits the patch after a little bit of work |
| A developer sees the patch, commits it, and says Good Job! |
A tester tests the patch and finds out it works good, but the documentation and formatting needs adjusted |
|
Contributor fixes the formatting and resubmits |
|
Tester is happy with the results, says “Ship it!” |
|
The inevitable “it doesn’t work in IE6″ |
|
Contributor gets it to work in IE6 and resubmits |
|
A core developer commits it to master and says Good Job! |
Compare how visible the Mere Mortal is compared to the Perfectionist. The perfectionist is seen exactly once, whereas the mere mortal is seen a handful of times by various people and is all that much more a part of the community by the end. When contributors feel welcome and significant, everybody wins.
Encourage diversity, in both contributors and contributions.
Girls can code too, but are told they’re too pretty for the sciences from a young age. Knock that off, mainstream culture.
Even if you can’t code, check the big list of other jobs in KDE earlier up in the post. They are just as important as everyone else.
Meat-space is sticky
Ask just about anyone who has gone to Akademy or Randa: Face to face meeting sticks with you for a long time. My first KDE event was the last Camp KDE in San Francisco. There I met some of the KDE contributors that I admired, wishing I could be like them too someday. This happened again in Randa 2011. Once you meet them, you find out that they’re just people, much like yourself. Nothing special. It does, however, develop some amazing bonds. KDE feels a bit like family these days.
Cultivate a do-ocracy
Going back to the point “Killing Einstein”, it needs to be clear that stuff only gets done by those who get it done. If you find a bug, report it; nobody else will know about it otherwise. If someone reports a bug, fix it; don’t assume someone else will get to it. If something looks unmaintained and needs some love, just do it. Who will stop you?
Recognize Contributors
People contribute more when they feel that they are important. Shining the spotlight on someone is a great way to do that. In KDE, we have BehindKDE: a contributor is interviewed and you learn who they are, what they do, and how they got to be a part of KDE.
Thats not the only way to do it though. Something I’ve made a habit of doing is making sure the contributors to a Phonon release are acknowledged in blog posts, usually by signing it with “–The Phonominals, X, Y, and Z” If a bug gets fixed by someone’s patch, I’ll be sure to note it in the git commit message and CCMAIL them and call them awesome. Its the little things like this that give new contributors that warm fuzzy feeling of making free software happen.
Scale yourself
Try to reduce your bus factor by encouraging others to take on tasks that you normally do. Intensive mentoring and some really good poking will spread out your load and bring some fresh enthusiasm into the mix.
If you want to help KDE grow, try practicing some of this in your own projects. Maybe sign up to be a mentor. Or review commits for commit-digest.org. Plan a sprint for your group. Write a blog post about what you’re working on and how someone can help test or document. Perhaps even join the KDE Promo team? The sky’s the limit.
Over the weekend, I had the opportunity to attend Ohio Linux Fest 2012 in nearby Columbus, Ohio.
I had also attended the year prior, where I had a very strange experience. Up 'till then, I had only ever been surrounded by developers and other like-minded people who already "get" KDE, what it means to use ...
