Page suivante Page précédente Table des matières

15. Structure et propriété des projets

Le cas le plus facile est celui dans lequel le projet n'a qu'un seul propriétaire/mainteneur. Aucun conflit n'est alors possible. Le propriétaire prend toutes les décisions et récolte les bénéfices ou les problèmes qu'engendre son projet. Le seul cas possible de conflit se présente lors de la succession — qui va devenir le nouveau propriétaire si le précédent disparaît ou perd son intérêt pour le projet. La communauté aussi a intérêt, d'après (C), à éviter les scissions. Ces intérêts sont exprimés par une règle culturelle qui dit qu'un propriétaire/mainteneur doit publiquement passer la main à quelqu'un s'il ne peut maintenir le projet plus longtemps.

Le cas non trivial le plus simple est lorsqu'un projet a plusieurs co-mainteneurs qui travaillent sous la direction d'un « dictateur bienveillant ». L'usage favorise ce type d'organisation pour les projets de groupes. L'expérience montre que pour des projets aussi gros que le noyau Linux ou Emacs cela fonctionne correctement, et résout le problème du « Qui décide » d'une façon qui n'est pas forcément la pire de toutes les possibilités.

Typiquement, une organisation de type dictateur bienveillant est issue d'une organisation de type propriétaire/mainteneur qui a su attirer des contributeurs. Même si le propriétaire reste le dictateur, cela introduit un nouveau niveau de dissensions possibles à propos de la répartition des remerciements pour les différentes parties du projet.

Dans cette situation, les coutumes obligent le propriétaire/dictateur à remercier les contributeurs de façon équitable (à travers, par exemple, une notification appropriée de leur nom dans les fichiers de LISEZMOI ou dans celui de l'historique du projet). Selon le modèle de la théorie Lockéenne de la propriété, cela signifie qu'en contribuant à un projet vous gagnez une part de sa renommée (en bien ou en mal).

En poussant ce raisonnement plus loin, on constate que le « dictateur bienveillant » ne détient pas, en réalité, la totalité du projet de façon inconditionnelle. Bien qu'il ait le droit de faire des choix cruciaux, il propose en effet aux autres des parts de la renommée de son projet en échange de leur travail. L'analogie avec le métayage dans les fermes est presque incontournable, sauf que le nom du contributeur reste dans les remerciements et qu'il continue à être associé au projet, même après avoir arrêté d'y contribuer.

Quand les projets de type dictateur-bienveillant rassemblent plus de participants, deux familles de contributeurs tendent à se démarquer : les contributeurs ordinaires et les co-développeurs. Un cheminement typique pour devenir un co-développeur est de prendre la responsabilité d'un sous-système majeur du projet. Un autre est de se transformer en « Chasseur de bogues », en débusquant et en corrigeant un grand nombre de bogues. De cette façon ou d'une autre, les co-développeurs sont des contributeurs qui s'investissent de façon substantielle et persistante dans le projet.

Le rôle de responsable d'un sous-système est particulièrement important pour notre analyse et mérite qu'on s'y attarde. Les hackeurs aiment à dire que « L'autorité vient de la responsabilité ». Un co-développeur qui accepte la responsabilité de la maintenance d'un sous-système donné obtient en général le contrôle de l'implémentation de ce sous-système et de ses interactions avec le reste du projet, et seul le chef de projet (qui joue le rôle d'un architecte) peut lui faire des remarques. On remarque que cette règle délimite effectivement une propriété suivant le modèle Lockéen à l'intérieur du projet, et a exactement le même rôle de prévention des conflits que les frontières ceignant habituellement les propriétés.

L'usage veut que le « dictateur » ou le chef de projet dans un projet avec co-développeurs consulte ceux-ci lors des décisions clef. Plus particulièrement encore lorsque la décision concerne un sous-système « appartenant » à un co-développeur (c'est-à-dire, qui y a investi du temps et en a pris la responsabilité). Un chef de projet avisé, qui sait à quoi sert le découpage interne de son projet, n'interférera avec, ni n'annulera les décisions faites par le propriétaire d'un sous-système.

Certains projets très importants abandonnent entièrement le modèle du « dictateur bienveillant ». Une façon de procéder est de transformer les co-développeurs en une commission de votants (comme pour Apache). Une autre façon est de faire tourner le titre de dictateur, dans ce type d'organisation le pouvoir passe d'un membre à un autre au sein d'un cercle de co-développeurs aguerris (les développeurs de Perl se sont organisés ainsi).

De tels arrangements sont généralement considérés instables et compliqués. Évidemment, ces difficultés dépendent largement de la productivité d'une telle commission, de ses décisions ou de son absence de décision. Ce sont des problèmes dont la communauté des hackeurs a parfaitement conscience. Je soupçonne cependant que le malaise des hackeurs vis-à-vis des commissions ou des organisations à pouvoir tournant vient du fait qu'elles cadrent mal avec le modèle inconscient de Locke qu'ils utilisent pour résoudre les cas simples. Il est difficile, dans ces organisations complexes, de tenir le décompte des propriétés de chacun en matière de parties contrôlées ou des gains de réputation. Il est difficile de voir les frontières internes d'un tel projet, et donc difficile d'éviter les conflits, à moins que le groupe n'atteigne un niveau exceptionnel d'harmonie et de confiance réciproque.


Page suivante Page précédente Table des matières