Bryan Ostergaard presented a talk entitled “You are doing it wrong” at FOSDEM this year, in which he spoke about the way Exherbo deals with newcomers. Exherbo seems to be doing well (see Ohloh page). The community grows at a constant pace with an average of 5 new contributors joining the project on a monthly basis who seem to stick around for more than a few contributions.

According to Bryan Ostergaard, it is better to attract newcomers who are inexperienced in FLOSS rather than trying to get some experienced people. The idea behind that is that somebody who has already been involved in a number of projects is likely to be  already busy  and may not have a lot of time to give to the project. Indeed, an individual with a lot of FLOSS experience may have the advantage to be ‘ready-to-go’ and may not need much guidance or mentoring, but if this person is already involved in 3 or 4 projects, his/her availability for the project may not be significant.

What’s in it for me?

The first good point that Bryan makes is about making clear that new contributors understand what they can get from getting involved in a project. Most of the projects that I am aware of have a ‘Get involved’ page that explains how someone can contribute to the project, in other words, what one can give to the community. But it may be worth seeing it from the other end and wonder ‘why shall a new contributor join this particular project?’ It is one thing to be told how you can help and contribute but why shall I do it? What’s in it for me?

Experienced FLOSS people may see the advantages of joining a certain project but someone new to the FLOSS world may not. Each project is unique and what you can get by being involved in a project can vary significantly. It first  varies based on the nature of the project itself  and its domain of application. Contributing to a Linux distro or a web server application may have a bigger influence on a CV when looking for a job, compared to having contributed to a media player project. Similarly, projects also differ in terms of programming languages and technologies that are used. In addition, what you can get from a project strongly depends on the values and the culture of the community.

This is the part that shall perhaps be more specifically explained in project websites. What do I get if I join Exherbo instead of Gentoo, Debian, or Fedora?  How is it different? Is one more ‘fun’ or intellectually challenging that the other ones?  Will I get more job opportunities? Will I have the chance to collaborate with top-notch programmers? Will I help change the world? This all depends on what the core values of a project are. Some projects are more pragmatic than others, some others are more ideological.

In Exherbo, Bryan Ostergaard said that when new contributors clearly understand what they can get from a project, then they have a tendency to stick around more. I think this is again some interesting point. People might be attracted by a certain project because it appears to be fun, but this is the kind of motivation that usually triggers short-term involvement.

What do you expect from me?

If a newcomer is convinced that your project is right from him or her, then comes “Ok, what do I have to do?” or rather “What do you expect from me?”. This is especially true if your project does focus on attracting inexperienced people. By agreeing on what you can gain from working on my project and also what you shall do to gain that, it then establishes a social contract in which both ends are clear about what to expect from each other.

A person with little experience in FLOSS may not fully understand what FLOSS is about. This should perhaps be the first thing to mention when explaining to someone what is expected from him/her. The main point here is not about providing a generic definition of FLOSS (even though it could be useful as a brief introduction), it is rather about specifying the vision of the project towards FLOSS. Some projects speak about free software, others of open source, but each project has a unique perspective which is directly related to the project’s values and culture.

Then shall come the community’s expectations in terms of how shall I interact with others? How shall I talk to people? How often and which mailing lists shall I read? What shall I do if there is a problem or something I do not agree with? Shall I take part in the decisions? How important is the community?

Some of these aspects are addressed by the code of conduct that some of the projects have. I personally prefer indicating to newcomers what is expected from them rather than providing them a set of rules or laws that he/she has to obey…

Social contracts with users too!

Bryan Ostergaard also mentions in his presentation the gap that exists between users and developers.  He indicates that Exherbo tries not to make a distinction between users and developers.

In a FLOSS project, users need developers as much as developers need users. There is some kind of symbiosis that keeps a FLOSS project alive and make it grow. As a result, I think that the right approach is to make clear that there are neither users or developers but only contributors. A way to ensure that is also to be specific about the social contract between a user and a project. Again, things must be clear about what a user shall expect by using a software as well as what is expected from a user (such as reporting bug and how to do that, how to talk to developers, suggesting features, promoting the software…).

In this post, I suggest that focusing on a social contract approach with both newcomers and users would help improve long-term involvement and contribution. Practically speaking, it means that projects shall first reflect on defining what they can give to newcomers and users as well as what they expect from them. Then, this shall be compiled into resources on the projects’ website as this shall be one of the first resources to consult when thinking of joining  a project or using its software. Please feel free to comment or debate!