Confiance et développement logiciel

Imaginons un instant la situation suivante: Alice et Bob partent en vacances deux semaines. Sachant que Charlie habite loin mais aime beaucoup la région, ils lui avaient proposé de s'installer dans leur maison pendant leur absence. Cela lui permettrait de s'offrir un séjour à moindre frais (la vie est si chère) et en même temps la présence d'un occupant rebuterait les cambrioleurs estivaux (le monde est si dangereux).

Pour cela, il faut qu'Alice et Bob aient une certaine confiance dans Charlie, ou plus précisément qu'ils partagent avec lui certaines valeurs, par exemple la propreté, le respect des voisins, le respect de l'intimité de ses amis, ... Hors de question qu'à leur retour, ils apprennent que Charlie a empêché tout le quartier de dormir en invitant des amis à faire la fête, qu'il a laissé la maison crasseuse et fouillé un peu partout pour assouvir une curiosité malsaine.

Surtout, il faut qu'Alice et Bob pensent partager ces valeurs avec Charlie. En effet, ils ne sont pas dans la tête de Charlie et ne peuvent donc être sûrs de ce partage, ils peuvent seulement le deviner, en avoir une intuition, forgée par la fréquentation régulière de leur ami, par l'observation de ses attitudes, ses gestes, ses actes, ses réactions, ...

Pour accueillir un autre développeur sur son propre logiciel, un développeur doit également lui faire confiance, retrouver chez l'autre certaines valeurs quant à la façon de développer. Bref, se reconnaître un peu dans l'autre. Pas question que l'autre débarque avec ses bottes toutes crottées et salisse tout le code auparavant si beau. Pas question que le territoire soit défiguré, dénaturé par un intrus.

Avant de se voir ouvrir en grand les portes du repository, le nouvel arrivant devra montrer patte blanche, montrer qu'il sait respecter les conventions de codage, la direction d'évolution induite par l'architecture, etc. Il proposera des patches, qui seront discutés puis acceptés ou non. A terme, les échanges entre les deux développeurs les feront converger vers des choix communs et des pratiques communes. Alors une certaine confiance apparaîtra.

Il est possible également que le nouveau venu soit auréolé d'une certaine autorité par des travaux antérieurs. Le seuil de tolérance sera alors augmenté, comme lorsqu'une personne de marque est invitée: D'accord elle fait tomber des coques de pistache sur le canapé mais elle dit des choses tellement intéressantes et nous apprend tellement de choses...

Par ailleurs, si Alice et Bob prêtent leur maison à Charlie alors que la maison est en passe d'être vendue, qu'importe si Charlie ne tond pas la pelouse et ne récure pas les toilettes. Alice et Bob ne sont plus investis dans cette maison et sont déjà tournés vers un autre lieu.

De même, la tolérance à l'entrée d'un nouveau développeur est bien plus grande lorsque le développeur original a déjà commencé à se retirer du logiciel, qu'il ne s'y investit plus car il s'investit ailleurs.

Imaginons une autre situation: Alice et Bob viennent d'être parents. Ils souhaitent que ce dernier ait un parain, une personne qui s'occupera de son éducation au cas où il leur arriverait malheur (la vie est si cruelle).

Ils pensent naturellement à Charlie, lui qui a su prendre si soin de la maison quand ils étaient absents. Mais il ne suffit pas à Alice et Bob de penser partager avec Charlie une certaine idée de la propreté et du respect des voisins. Non, ils aimeraient aussi être sûrs que, élevé par Charlie, leur enfant prendra la direction qu'ils aimeraient qu'il prenne: qu'il devienne quelqu'un de bien, quelqu'un de juste.

Même sans savoir précisément définir ces valeurs pour eux, ils voudraient les retrouver dans leur enfant, une façon de se reconnaître en lui. Et ils pensent que cela aura plus de chance de se produire si Charlie partage aussi leur conception de la justice, qu'il saura alors en montrer la direction à leur enfant, pour qu'il tende vers cette idéalité.

Le développeur original d'un logiciel n'en espère pas moins des autres développeurs qui le rejoignent. Il aimerait que ces derniers partagent la même idéalité, qu'ils aspirent au même avenir pour le logiciel, de façon à faire évoluer celui-ci dans la même direction, le faire tendre vers cette idéalité. Le développeur original souhaite continuer de se reconnaître dans le logiciel produit à plusieurs. Si les divergences sont trop fortes, ce sera le fork.

Lors du travail à plusieurs sur un logiciel, au fur et à mesure que le logiciel évolue et que l'idéalité évolue en même temps, cette dernière peut se construire cette fois chez les différents développeurs en même temps, par leurs discussions, leurs échanges, les problèmes qu'ils rencontrent et résolvent ensemble. De là naît la confiance entre les développeurs, lorsqu'ils savent qu'ils poursuivent le même but et que chacun se retrouve, se reconnaît dans le logiciel qui naît et évolue de leur travail commun. Pour reprendre le vocabulaire de Simondon, une individuation psychique et collective dans le groupe des développeurs est nécessaire pour faire naître la confiance.