On working together

A chat with Armijn Hemel (during good food - Roti Kip) about contributing lead to this blogpost. Within the KDE community we have a large number of volunteers working in a variety of areas. Paul notes in his blogs how 'modularization of the community' can be dangerous when a bus rides over an important contributor. Luckily I haven't heard of busses doing that recently, but there are other matters in life which can pull away contributors. This hurts communities, and I think contributors should think a bit more about that.

Real life interference - think about it!
Unfortunately, leaving is something one rarely plans in advance. Most contributors want to stay involved, and still offer to take on work - they just don't actually have time for it anymore. This obviously makes planning rather difficult - as Armijn noted, being a volunteer doesn't mean having no responsibilities.

But does it mean you always have to do what you promised, despite real life? My take: absolutely not. I think people should be free - and have fun contributing (hey, KDE tagline!). It should not be a MUST. Sure, its good to take responsibility, and even the more boring tasks have to be done. I don't always enjoy what I do - but in the end, the good feeling which follows once a difficult or timeconsuming task has been completed makes it worth it.

Share what you do - work failsafe!
What IS important, however, is to tell others you can't finish something. And probably even more important: to make sure others CAN take over things you did in the past or you are working on right now. Failing the first can be annoying - it makes it important for someone to track what others are doing. I try to fullfill that role but it ain't always fun and it's certainly not easy. But it can be done, and it helps immensely if you keep me updated yourself. However, the second issue is far more troublesome.

It is important to keep in mind that people, including yourself, could leave at any point in time. New job, having kids, illness, family issues - you can't plan them (ok, maybe the kids). Make sure you're expendible. It's cool to be responsible for a great many things - but none the less it is important to involve others and keep the team informed by mailing or blogging about it. And use a wiki or other collaborative tools to keep the crucial information.

Information overload - don't go to far!
Note I say the crucial information, be careful with information overload. It's why I always advocate to keep plans simple, and start implementing a part of it before finishing large documents detailing what COULD be done. Writing down too much hurts as much as writing down nothing.

Say you have come up with a great way to do things different, better. You've read this great article about it, and now you want to implement it. So you start writing a great and complicated plan. Very cool - but what if you can't finish it? It is unlikely for someone else to pick it up - often these 'grand plans' are cool, but if they're not a team effort from the start, they die of once the initiator leaves it.

Besides, talk is cheap, work is what matters. And FOSS teams in general have limited resources - resources I'd rather spend on stuff which matters quick, is easy to keep alive and is easy to get involved in. Low hanging fruit, so to say. Sometimes I get comments like "don't chase people away" and such because I focus so much on what is seen as short term benefits. I'm sorry, but in the end, results count, not big bloathed wiki's. I'd rather have for example a mediocre webshop online and then in time have others contribute stuff than writing an amazing plan and then - nothing*...

Simple is good - and take care of the basics!

Simplify great plans. Often, doing a little makes a great difference already - and in time, if others are interested, you can go further. This is the release early-release often mantra. It works even in marketing, as I've often seen. If you want something done, a proof of concept will lead to much more input that just a 'I think X would be a good idea'.

Besides, great plans can take away precious resources from the basics. Things which need to be done. So, I sometimes might be seen as blocking new plans and endeavours. Sorry, that's not my intention. I just want things to succeed, and I've seen plenty of big plans fail... Which doesn't mean you should never start big things - but make sure a lot of people are behind it and want to work on it or it will fail.

The key - or what to do!
Often, the key to success is NOT a big plan, NOR even your own hard work - it's about getting a few others involved, motivating them, AND keeping them on their toes by checking up on them and keeping interest up. For longevity of a team, this is even more important. And it is far more fun to work with others. So think about that wen you want to do something great: involve others, keep them updated, and don't soldier on all alone!




* note that this example is NOT a description of how we're currently setting up a webshop - it's a random example, Justin is doing great to say the least ;-)

One more thing - I would say the number of active KDE promo people these days (compared to a year ago) clearly counters the argument that the pushing a bit against 'big plans' which I sometimes do is bad for building a dedicated team ;-)