Le réflexe
L’open source est un stock de pièces. Tu l’installes, tu l’utilises, tu montes la version. La relation s’arrête là.
Le réflexe builder
“Dix ans de disputes ont produit cette API. Les disputes sont encore en ligne.”
Pourquoi
Le code, c’est le corrigé. Ce que tu n’obtiens nulle part ailleurs, c’est le raisonnement.
La proposition qui a été rejetée, avec trois paragraphes expliquant pourquoi. La revue où un mainteneur explique qu’une approche ne survivra pas aux écritures concurrentes. Le rapport de bug où l’hypothèse de quelqu’un meurt en public, avec son nom dessus, sans crispation, et le thread laissé en ligne pendant dix ans.
Il y a une version pratique de ça. La prochaine fois qu’une mise à jour te casse, l’explication est dans un thread d’il y a deux ans, écrite par celui qui a fait le changement et qui savait ce qu’il coûterait. La plupart des équipes ne le lisent jamais. Elles patchent le symptôme et repaient à la version majeure suivante.
Et contribuer n’est pas le projet caritatif dans lequel c’est rangé, donc “on livre, on n’a pas le temps” répond à la mauvaise question. La revue d’un mainteneur, c’est une heure d’attention dure de quelqu’un de meilleur que tous ceux qui te sont accessibles, sur ton code, gratuitement. Quand le nombre de gens capables de te relire correctement est petit, il n’y a aucun autre moyen d’acheter cette heure à quelque prix que ce soit.
C’est aussi la seule salle où personne ne peut voir d’où tu viens tant que tu ne le dis pas.
À essayer
Prends une librairie dont ton produit dépend. Lis les trois threads ouverts les plus longs de son tracker. Pas le code. La discussion.
Puis envoie un petit correctif. Une documentation ambiguë compte. La première contribution t’apprend le processus, et le processus est l’endroit où les gens abandonnent.
À discuter
Est-ce que quelqu’un ici a ouvert une pull request sur une de nos dépendances ? Qu’est-ce qui a arrêté le dernier qui y a pensé ?