I’ve been building (free software) communities for quite a while now. With HedgeDoc (former CodiMD) being probably the most successful project. How can one tell? Well, I was able to step back a bit and let better people for the job handle it. However there is also MadIRC which is quite successful and I was able to give that to a group of successors that still keeps it around. And my current projects are some Matrix rooms like “Blogger’s Gathering” or “Git Hosters”.

Once you have a project that people might be interested in, you can start with building a community around it. And hopefully this little insight can help you to do that as well as giving you the knowledge how communities that I’ve build up work.

The 3 factors to build a community

The factors for building a successful community are actually quite simple and can be applied to almost every project. And of course everyone can learn them.

Time

First of all it requires your most valuable resource: Time. You have to invest quite some time into a community. Starting from the time to invest to write texts in order to inform people, over the time to spend to socialize with them and the time you may spend on helping people to find their way into or around the community.

It becomes a part-time if not even a full-time job. Not always busy, but response time is crucial. And that’s what you’ll mostly use your time for at the beginning: Waiting. You wait for a person to show up and have a question. You should be able to answer a question or help immediately. This makes people feel good in a community. Nothing is better than entering a community chat, asking a question and within a few minutes you get an answer. It doesn’t have to be the perfect solution but the “You are not alone here” signal is what is the first step towards success.

Patience

With people having problems, the second important factor is your patience. When answering questions it can become tedious quite quickly. Or sometimes people ask questions you consider so trivial that 5 seconds of online research would have answered them. But people don’t always do that. Or they use the wrong terms. Be patient and answer their questions. Help them as good as you can. Explain, ask, answer. Don’t become pushy, or unfriendly.¹

Friendliness

Friendliness is key to build a community. People usually don’t enjoy hanging out with unfriendly people. As already mentioned, it’s not always easy, but just answering to something like “Hi” or welcoming new people in a chat is important in the very beginning. Later on it might be better to give it some time and only do that when no one else provide any reaction to the “hello”.

Also when you look at forum posts, issues or pull requests, try to answer friendly. Assume that someone might doesn’t know how to do things as expected. For example we require a sign-off for HedgeDoc code and people often fail to provide it. I have quite often wrote down the 3 steps to add it to the existing PR commit even when they are well documented all over the place. You save the other person 15 Minutes of research by using 5 of yours. That’s usually quite well received and makes you more likeable.

Keeping the community together

Once you have a few people around it’s obviously important to keep people around. Without keeping them interested in the community, it falls apart as quick as it appeared.² For that you want to take some actions.

Explain everything

It sounds like a ton of work, but it not necessarily is. Just make sure you provide a simple argument why things are done in a certain way. People follow rules much better when they know why a rule exists. Also people accept decisions much better when they know why a decision was made in a certain way. It’s even easier to accept them when they disagree with the decision itself but can accept the argument.

From complicated design decisions to why a group exists in first place³: Write it down. It usually saves you long discussions. If someone wants to know, point them to the reasoning. Usually people are less likely to start drama when you can provide them with reasons you made up, and in best case publicly documented, at the time of the decision instead of starting to write a reasoning on the spot as answer to the disagreement.

Share responsibility

Don’t try to make all decisions. Delegate tasks. And delegate actively, because the only people begging you for responsibility are those you really don’t want to give them to. If someone appears to do really good stuff for the community reward them with moderator rights, access to repositories or just making design decisions. Enable people in your community to take stuff on their own without your need to authorize stuff. It shows that you trust them and value their contributions.⁴

Praise the community progress

Soon after building a community and delegating tasks, you’ll notice that things start to get their own life. Watch it and enjoy it. Share it on social media and thank the people who bring in their own ideas. It’s the empowerment that a lot of people need to progress further. It might be a small feature for the overall project but for that very moment it might be the motivation for someone to spend time on your project. Express how much you like their work and if you are not completely happy with it, give hints how to improve it so you can properly integrate it. Critique is received a lot better when you show how much you value someone’s time investment.

When sharing those stories on social media it provides your project some exposure which again, helps the community to grow. It also makes your community more likeable because you don’t just focus on the plain project but go beyond and focus on the people involved as well.

Conclusion

This is a little bit of insight in the unwritten rules of how I build communities in various occasions. I’m sure it’s not the only way to do it, but it’s definitely a working way to do it. All it takes is time, friendliness and a good amount of patience. Is it rewarding? Depends on how much drama comes up. But it’s definitely fun.

If you want to move on from your free software projects at some point, I definitely recommend to try to build up a community around it. Often tools are great but you grow tired of developing them. An alive community can be your chance move forward with other projects without killing off the old one. Share your responsibilities and make people aware of processes. By helping people to dive deeper into your code and contributing more, you will soon have some actual experts working with you.

And obviously at the end of the day it’s fun to meet so many new people and see how a group of them enjoys their time together.

With that said, I hope that helps you to get your projects going and I’m looking forward to meet some more awesome communities!

Photo by Helena Lopes on Unsplash