Open Advice and Research


A little less than a month ago, Lydia Pintscher presented her book Open Advice at FOSDEM in Brussels. The book is the result of the collaboration of a number of Free Software passionates and his a collection of essays which focus on helping potential new contributors to get started. The book, in my opinion, does a lot more than that as it provides a wealth of stories, experiences, and insights that are worth reading for anyone somehow involved in FLOSS. A must read!

While going through the chapters of the book, a lot of points made by the authors arose my curiosity as a researcher. As a lot of FLOSS passionates and contributors seem to point out that researchers often study issues that are not so important or relevant for FLOSS communities, I find this book to be a mine of ideas to help identifying areas that are worth investigating and more importantly of high relevance for FLOSS communties.

This post is about one particular aspect that I have found interesting, but there are a million more very interesting things in the book.

Community taxonomy

In chapter 18 entitled  Documentation and My Former Self  and written by Anne Gentle (a community documentation coordinator at OpenStack), a passage caught my researcher eye:

I wish when I started that I had some ability to gather the “social weather” of an online community. When you walk into a restaurant with white tablecloths and couples dining and a low-level volume of conversations, the visual and auditory information you receive sets the ambiance and gives you certain clues about what to expect from your dining experience. You can translate this concept of social weather to online communities as well. An open source community gives certain clues in their mailing lists, for example.

I actually see two aspects in this quote that I find particularly interesting. I would like to dissociate the idea that Anne Gentle develops in the above paragraph from the term ‘social weather’ that I would define differently. I will address the idea of ‘social weather’ in another post.

Each FLOSS community is unique and has unique features like every individual on this planet is unique with a unique personality, unique preferences, unique beliefs, values… Like Anne Gentle points out in her comment, as a newcomer in a community, one has to figure out from the various clues (content of mailing lists, community rules, policy…) how a certain FLOSS community is and how it functions. If the person feels like it is a great place to be with people he/she thinks he/she  will get along with, then the person will obviously decide to get involved. Anne Gentle mentions that it is an ability to perceive the clues, but experienced members do have this ability and the unique nature of each community is no secret to anyone who has been involved for a while in various communities.

People already know that the Linux Kernel, WordPress, Ubuntu, KDE, GIMP, or Mozilla communities are different and the information about how they handle and value newcomers is not something secret. I am not going to mention the practices of each community and compare them on a judgmental value as raising a debate about how good/bad these practices are is not the purpose of this post.

The point that I am trying to make here is that it would be quite useful to design a certain taxonomy of FLOSS communities in regards to how newcomers are handled. This would be quite useful for newcomers as it will provide them some guidance in where to go according to the perceived fit between a certain community and themselves. To design a taxonomy, there is first a need to identify the various dimensions that characterize how a newcomer is ‘handled’ or what kind of experience a newcomer might potential have. A good way to start doing that, would be to talk to people involved with community management and newcomer recruitment in various FLOSS communities. the discussion would lead to some consensus. Off the top of my head, some of the dimensions could be things like:

  • degree of formality of the recruitment process (example Debian and Gentoo seem to be quite formal, KDE probably a lot less).
  • presence of formal programmes (mentoring and others, inside and outside the community: GSoC, GNOME Outreach Program for Women)
  • amount of support provided to newcomers
  • the culture of the community, its core ideas and values (including the sub-culture associated to how newcomers are considered/valued).
  • technical barrier of entry
  • the code of conduct and other behavioral expectations from the community
  • average duration to become a contributor (or get commit access, be a maintainer …)
  • proportion of people who decided to get involved and eventually became core contributors

There are a lot more potential dimensions that would be worth exploring. Once the interviews are run and the dimensions are identified, then each community can be mapped along the dimensions. If all that can be compiled in one single resource or place that potential newcomers have access to, I reckon it would be of great benefit to newcomers.

I also think that it would be of great benefit for the communities themselves. This would enable some kind of pre-screening of potential contributors and I have a feeling that the ratio of newcomers who then become community contributors would be higher. Newcomers would know more about where they are going instead of having them figuring out after a couple of months that he/she does not adhere with the community culture or the procedure to commit code for instance. Some people might say that newcomers are adults, shall figure it out by themselves and do some homework before joining but as Anne says, perceiving the clues is some skill that one gets over time…

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s