Reducing the risks to get involved in a group

Paradox: only those who do nothing have time

No doubt, if you've tried to bring together people, you have stumbled upon this curious paradox: Those who could make the most of a community are either already involved in other groups, or they are putting together their own project. They do not have the time to invest in your project.

Others do not have sufficient material safety to get involved.

There is a third class of persons involved in numerous projects. They will join with your joy. But if they can bring the wealth of links to other groups, they will have neither the time nor the interest to contribute significantly to your project.

The paradox can be stated as follows: "Unless exception, the best contributors do not have the time to invest in your project."

Reducing risks when during the involvement

Those who are often asked to participate in projects have become accustomed to say no first and then possibly think about it. For having very poorly followed this rule, I have often found myself overwhelmed by too many commitments. This can only be done at the expense of our involvement in the projects we participate in or that we take up.

Once again, it is necessary to let the regulatory mechanisms play their part. Someone who arrives in a project can never be sure that it is really interesting for him or even if he will stay. It is therefore necessary to minimize the risk of getting involved in a new project.

For this there are two criteria:

• One depends on the person itself: You can get involved once vital needs are fullfiled.
• The other depends on the group: Entering a group should not be a commitment to contribute or even stay.

First Rule: Everyone must have a material safety

It is necessary that everyone has solved its problems of material safety:

• Either by participating in the project within the framework of his work if the organization to which he belongs sees an interest in it,
• Either by having a sufficient flexibility to participate voluntarily.

The direct funding of people for a project raises a problem of acceptance by other unpaid people and of expectation of results that require other methods. A person may, however, be employed by a participating organization in the project. She is then paid for her role of link to the project rather than directly for the work done within the framework of the project.

Open or closed communities

An important area in the development of cooperative projects is about the open or closed aspect of groups.

If a coordinator gathers a community of users who can not easily make the choice to leave the community, then the community is said to be closed. If instead the community allows any user to get out easily, if contributions can come from anyone, then the community is open. It seems that some rules stand out to form an open group:

• Each member of the community can come out of the community any time and on his own initiative. If a member disrupts the functioning of the community, the coordinator has the right to exclude. He however does not have the power to maintain in the community someone who wants out.
• It is possible and even very positive to be part of many communities. Everyone can freely choose the groups he wants to join.

The establishment of an open community of users-contributors is preferable to a closed community.
Sects are closed groups.The membership to other groups just as the exit from a sect are highly discouraged. The guru has more than one power to compel its members.

The criteria that we have given are not about the entry into the community. There are cases where communities stop entry using cooptation or other mechanisms. There are several types of these mechanisms such as the coordinating nucleus of a project when it involves many people or the community of project coordinators.

Coordinating nucleus and steering group

We have seen that the great difference between contributors and resident coordinators lays in the execution of critical or non-critical side tasks. Thus the coordinating nucleus of a project can sometimes consist of several people. In this case it is best to choose the coordination team in which each member will support critical tasks very carefully. Cooptation is then the best system. It's the the main coordinator's job to choose its partners and ensure the coherence of the team.

Users do not choose each member of the coordinating nucleus but penalize the efficiency of the coordination team by contributing or else by going out of the community. The information they have is a key criterion to avoid deviations. Paradoxically, the operation is similar to a stock exchange or financial market : A "bet" is built on an idea, a strategy, a team and the penalty is an increased demand of the title.

In all cases it is preferable that the coordinating nucleus (and also the number of critical tasks) remains as small as possible to avoid increasing complexity imposed by the law of Brooks. Ideally the coordinator must be alone.

One solution is to form a steering group. It gathers members of the community who were given roles (non-exclusive and non-critical) to undertake tasks of which none is vital to the project. Such a non-critical steering group allows then to have very active contributors who can even take over the coordination of a subproject without the risk of jeopardizing the whole project if one of them fails.

Community of peers

The community of project coordinators is a community of co-opted members: people enter the community when they are recognized by their peers. Here, the community is only aiming to exchange. Without anything to produce in common, there are no critical tasks. It is mainly used to host exchanges and recognition among its members. This closed community is dangerous, however, if recognition is based only on its members and not on an open community of user-contributors.

Thus, in free software, there are two types of communities. Hackers (also called ethical hackers to distinguish them from others): They are often people who implement cooperative development of free software projects. They get their recognition (and therefore their status as hackers ), not only from the hacker community, but also from user-contributors of their open communities.

Communities of interest such as hackers protect their coherence from the outside by mechanisms of selection:

• The vocabulary or social context allows recognition between members
• The need for an initiation time enables to acquire the qualities needed to be recognized as a member of the group (technical skills, patience, sense of compromise ...). Secrets must be gradually discovered.

On the contrary, the "crackers" are hackers who secretly develop viruses or pirate websites. The community of crackers is formed of people who recognize them as crackers. If they have the equivalent of users (who are so in spite of themselves!), they don't have an open community of contributors. Regulation by the involvement of users-contributors can't occur.

A community whose door is closed is not necessarily a bad thing if it allows the building of a coherent coordinating nucleus by cooptation or allows exchanges between people with a common culture. However it must enable exit and multi-membership to stay open and it has to be based on other open communities to allow mechanisms of regulation of recognition and hence avoid deviations.

Second rule: Entering a project must not be a commitment to contribute or to stay

This "opening" may seem as a disadvantage, and it seems more interesting in the short term to make its users "captive". But the real assessment of the project needs the esteem of the users who choose to contribute or on the contrary to leave. The questioning made imperative by this continuous assesment leads the project to a virtuous circle of quality. Of course the coordinator keeps the power to expel a member who would disrupt the overall operation.