It's free.

Encounters with open source communities

Last month, Seif Lotfy wrote about first interactions with open source communities. I both agree and disagree with him. Moreover, I think most of this still applies for people who already have been in interaction with open source communities.

The first principle

“If the contribution is not useful, then sugar-coat your criticism.”

Spontaneously thinking, this statement makes sense. Giving positive feedback is fine, but you should be careful with it. If the contribution is not useful, don’t try to hide that. Rather than telling the user is completely useless though, try to give positive feedback on being interested in contributing.

As other people said in the comments, there are always people who are only seeking for fame – or, simply said, acceptance. While I think communities should be open for everyone to join, this kind of “contributors” will not do good for the community. Of course, the existing members of the community should try to encounter people with as little skepticism as possible; otherwise, we will become a closed community which will not let anybody else in.

Open source communities are quite different from most other communities. It’s not always easy to grasp how one works, even if you are familiar with other communities. How does one identify and tell apart a confused newcomer from someone who only seeks for attention?

Well, you shouldn’t need to do this in the first place. Based on my experience, the best thing to do is to point the newcomers to the right direction and tell them you are available for any questions they might have. Whether you think they will start to contribute or not. Having questions and wanting to know more is fine, but it always rings my bells if somebody wants to starting helping right now. Rushing it will not help, you will just end up with useless contributions. The majority of those who want to start working immediately also disappear as quickly too.

Getting your hands dirty right away is sometimes appropriate too, for example if you have a list of low-hanging, trivial things to fix. Other situations include brainstorming sessions, where any input is welcome as well as some one-time things you need to conduct – namely, testing a specific thing with specific hardware or software, but you don’t have access to such things right now.

The second principle

“If the contribution is useful, then praise the developer and make him feel useful.”

Again, this statement makes sense when first read. Giving positive feedback should be always encouraged amongst fellow developers. However, it’s a slippery slope to tell other people they are more useful than others. Contributing to open source communities is always (well, almost always) voluntary work. If you have committed something useful, you will most probably want to do it again, since you had the motivation to do so before.

Telling newcomers they are useful is fine, as long as they really are. Making them, or any contributor, think they are irreplaceable is bad. (Specifically telling somebody he’s replaceable is bad too!) The bottom line is that you need the existing developers as much and probably more, since they are more familiar with the community structure, including how technical things work, but also how different people “work”.

Conclusions

Giving positive feedback is great, but be careful with it. Don’t give positive feedback about something that is completely useless for the community. Sugar-coating criticism too often generates useless contributions from people who are only seeking for acceptance. Instead of shepherding people, try to bump them in the right direction. People who are at all motivated will keep going.

This article is part of the article series .