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 .

Discussion

  1. Seif Lotfy
    May 29, 2012

    Hi Pasi,
    Thanks for the amazing post. I agree with you on the second point completely. A contributor needs to show patience and the will to contribute. What I meant is that let alone the fact that they are coming with enthusiasm but average contribution should be worth harvesting. With some sugar coating I meant thanking him for the contribution and stearing him in a direction where he/she might add more value, or make him/her start with a simpler task.
    “Sorry dude, try with something simpler like x” vs “Thanks alot, what about trying to fix x now”
    This is what I mean with sugar coating.

    As for point 2. I never said to tell someone he/she is more useful than others. But praising his/her work publicly shows appreciation.

    Sugar coating in my post was meant for new contributors. Just to harvest their momentum and enthusiasm.

  2. Pasi Lallinaho
    May 29, 2012

    Hey Seif, thanks for the reply and thanks for your original article!

    Of course, appreciation should be shown towards any contribution, since any contribution (even awfully useless) means somebody did work to both create/modify/whatever verb appropriate and send the contribution.

    “Sugar-coating” might easily give a wrong conception though (did for me!), but I totally agree with you that new contributors’ momentum and enthusiasm should be harvested and pointed to useful directions. This is something where I think any project or team will have area for improvement, always.

    FOSS projects easily become elitist and/or inclusive, as people start to protect their own position and importance – which basically means the people want to look irreplaceable in the project. (This is just how people are, and it’s fine, as long as you are able to notice the motion in yourself and fight against it.) Once people do this, it’s also easy to make somebody look more important/useful than others.

    BTW, I just had to chuckle for the example “…what about trying to fix X now” – isn’t that something what experienced programmers have been trying to do for years already? :)

  3. Seif Lotfy
    May 29, 2012

    I think we are on the same page. And the word choosing on my side was wrong. So I agree with you 100%

    and I just got the X thing now :P