Elizabeth Leddy gave the next talk I attended entitled: Wish I Knew How to Quit You: 10 Secrets to Sustainable Open Source Communities. Elizabeth works with Plone but wasn’t really involved in open source until about 5 years ago. With open source we often start by working at a company that supports a specific open source application and there are two paths we can take. One path is that you start to get annoyed with the way things are going and so you jump to another open source project. Or you can get involved in the open source community so thoroughly that you can move from one related company to another (this is what I have been doing with Koha so I totally understand this path).
The goal of Elizabeth’s talk was to make sure we all create loving communities like the one around Plone. When picking your community you should think about what you want to get out of it and what you want to contribute. Open source isn’t just about code. The people in your open source community (if you’re like Elizabeth or me) are the first people you say good morning to – you wake up and get on IRC and say hi to your family. Elizabeth said that she sometimes wakes up and feels like she has 400 brothers … I totally agree … but I’d change that to ‘siblings’
#1 Make Plans
When developing your community you have to make it clear that you’re in it for the long term. You need a plan for marketing, legal issues, documentation code cleanup – and much more!
One problem communities have is that they hold one person or a few people up as the experts in the community and the fact is that they might one day go away so you need to create a leadership pipeline (something I think Koha is good at). In addition to the fact that these people might go away – you really want to help new blood jump in to leadership roles. Also you don’t want to burn people out! You need spread the wealth.
#2 Break Plans
In addition to creating plans, you have to break plans! Don’t get so stuck on your plan that you don’t embrace change.
Make sure you keep metrics to see what’s going on in the community. Bad sentiment is hard to combat. Counter attack that by measuring community success like you would performance and share that info (I think of Chris Cormack’s Koha stats sharing with each release).
#3 Think Globally / Act Locally
Remember that there is going to be a language barrier! Many people to speak English, but they don’t “prefer” it. This means that people might take longer to reply on a mailing list because they’re translating and trying to decipher what’s being said. It also means that tone in things like flame wars might get lost on these community members.
One way to handle this is to provide multiple language channels – on IRC, mailing lists, websites etc. Also you can encourage local symposia so that people can learn about the software in their area and don’t have to try and travel.
At the very least make sure that your ‘how to contribute’ documentation is translated into several languages! That way people around the world can contribute to your project in the way you want.
Diversity isn’t just about accepting women! It’s about accepting people of different nationalities, sexualities, backgrounds, companies, etc etc.
Offer to mentor new people. Always give feedback instead of just replying with +1! Ask your community members for code reviews so that you can get better – and if others ask for reviews help them – in the end you all make the product better. Remember to thank people – especially the people behind the scenes who are doing things like managing your domain name or hosting your mailing list.
We have to think about culture. “Culture is best perpetuated in person” … but most open source happens online. So coming up with as many ways to meet in person can really help your communication and community growth.
Remember to be transparent. Work in groups on new developments so that here is more trust. Nothing can be implied or assumed – you have to share everything out in the open so that the community knows what’s going on. You can also find people who have maybe disappeared and reach out and ask them what’s going on – it might be as simple as life has gotten hard for them and they’ll appreciate the support – even if it’s just beer delivered to their doorstep.
In person meetings shouldn’t focus just on code – more importantly we want to educate the new people, we want to hash out the problems while you’re in person. Getting people to participate is more important than fostering observers … if the focus of an in person meet up is on producing code you might end up with this.
#6 Stop Recruiting Developers
There is a lot of stuff that has to get done in a long term project that does not include code. Things like marketing, business, documentation, legal and fiscal issues. For Koha all the documentation for users was written by librarians (not developers).
#7 Redefine “Participate”
Make sure it’s not just development
Think twice before contributing to a project without non-profit foundation. Koha has seen this problem … but at the same time I’m not a fan of absolutes (never/always) so I of course contribute to Koha and always will even while we figure out the legal issues that a foundation could help us with.
Foundations can also help with conference planning, fundraising, infrastructure – they don’t have to have any say in the technical decisions if you don’t wan them to.
#9 Lose Control
Have diverse, self policing redundant teams. Other projects do have tight control and work just fine, but having groups means that one person can drop out and you don’t end up scrambling to fill the spot.
#10 Be Awesome / Expect Awesome
You’re responsible for the energy you bring into the room! The tone of your voice and how you treat people will effect everyone in the community. Thank you Koha family for having an awesome energy and welcoming all new community members!!