Auteur et mainteneur de plusieurs projets open source , Andrew Gallant tente de soulager la tension qui s'est récemment accumulée dans la communauté open source. Les cris de l'âme «Qu'est-ce que ça fait d'être un mainteneur de logiciel libre» , «Ungrateful opensource» et d'autres plaintes des mainteneurs ont donné lieu à une discussion sur l'agressivité, l'impolitesse, l'ingratitude, l'épuisement émotionnel et la gravité du soutien désintéressé aux projets. Le billet a été publié le 19 janvier 2020, - env. trans.

Je veux m'éloigner de la tradition de parler presque strictement sur des sujets techniques - et je partagerai certaines de mes relations personnelles avec les logiciels libres et open source (FOSS). Bien que toutes les personnes soient différentes, j'espère que l'échange de vues contribuera à renforcer la compréhension mutuelle, l'empathie et la confiance dans notre communauté.

Veuillez ne pas considérer ce message comme une réaction directe aux actions de tout autre responsable. Ce n'est pas une recette pour un comportement idéal, mais plutôt une réflexion personnelle dans l'espoir qu'ils deviendront une occasion pour les autres de réfléchir sur leurs propres relations avec l'open source. Il n'y a pas qu'une seule bonne façon de devenir un bon mainteneur. Chacun a sa propre façon de gérer cela.

Ce n'est en aucun cas un appel à l'aide. Il s'agit de comprendre. Je n'appelle pas à un changement dans l'économie des logiciels libres et ne discute pas de ma santé mentale. Je ne parle pas d'attirer des mainteneurs supplémentaires. Je veux juste partager mon histoire et essayer d'augmenter l'empathie dans la communauté FOSS.

Public cible : toutes les personnes impliquées dans l'open source.

Table des matières

L'histoire

Mon tout premier projet open source est sorti il y a près de 16 ans - un babillard en PHP. À cette époque, presque tout le monde a créé de telles choses, et c'est ainsi que j'ai appris à programmer. Le projet a d'abord commencé comme un système scolaire pour les discussions (à cette époque, les écoles ne fonctionnaient pas du tout avec Internet, sauf pour l'hébergement de sites de merde). Puis j'ai d'abord rencontré la difficulté d'estimation. Le projet a duré beaucoup plus d'un semestre et s'est progressivement transformé en un hobby qui dépassait le cadre du projet scolaire.

Personnellement, j'ai toujours aimé programmer juste pour le plaisir. J'aime toutes les étapes: d'abord sonder un sujet, déterminer la faisabilité, développer un plan initial, coder obsédé et même y penser, j'aime chaque minute.

Pour profiter de la programmation, je n'ai pas à partager les résultats de mon travail. Cependant, l'open source est rapidement devenu une partie naturelle de mon processus de développement, qui a persisté sous une forme ou une autre pendant 16 ans. En fait, ce que j'aime le plus, c'est que le code permette à quelqu'un de résoudre son problème plus efficacement. Plus mon code est bon, plus il est agréable. En règle générale, je me fiche de savoir qui d'autre part n'est qu'un autre pirate informatique qui satisfait sa curiosité, ou une entreprise géante qui fait quelque chose d'intéressant à une échelle incroyable.

Mon histoire sur les logiciels libres s'est poursuivie avec plusieurs versions de mon babillard et de wtcSQLite , un simple clone de phpMyAdmin , mais pour SQLite.

Lorsque je suis passé de Windows à Linux vers 2009, j'ai lancé encore plus de projets, mais en Python et X11. Parmi eux, PyTyle pour la fixation des cadres dans le gestionnaire multi-fenêtres et openbox-multihead , mon implémentation du support multi-moniteur dans Openbox . Ces projets, ainsi que des recherches par Go, m'ont amené à créer le gestionnaire de fenêtres sur Go que j'utilise toujours.

Au fil du temps, et il y a environ six ans, j'ai commencé à écrire dans Rust. Quickcheck est devenu la première bibliothèque, mais elle a été suivie par une foule d' autres: regex , docopt.rs , rust-csv , fst , termcolor , walkdir et bien d'autres au cours des six prochaines années.

Bien que la grande majorité de mes projets Rust soient des bibliothèques, il existe des outils de ligne de commande comme xsv et ripgrep .

Beaucoup de mes anciens projets sont maintenant morts ou soutenus par d'autres, mais je continue à soutenir la plupart des projets Rust. Ou ils ont été supplantés par les racks de meilleure qualité de quelqu'un d'autre (par exemple, comment le canal de traverse a remplacé le canal ).

Aujourd'hui, j'aime toujours beaucoup programmer, mais je passe aussi beaucoup de temps sur les révisions de code, le débogage de problèmes avec les utilisateurs finaux, la réponse aux demandes de fonctionnalités et autres choses de ce genre. Cela signifie invariablement interaction, travail et communication avec les autres.

Maudites émotions

Dans ma jeunesse, j'étais fier de ma «logique» et de ma «prise de décision impartiale». Comme dans toute bonne tromperie, il y a un grain de vérité ici. Mais par essence, je suis personnellement un être profondément émotif.

Les émotions sont profondes et peuvent être une source très utile de motivation interne. Par exemple, pendant un certain temps après la sortie de ripgrep, j'ai vraiment détesté toucher le code responsable de l'affichage des résultats de recherche . Il était confus, buggy et difficile à changer. Réécrire complètement le code est une décision tout à fait logique qui peut être prise pour des raisons purement techniques, mais j'étais motivé à le faire par dégoût. Je n'aimais tout simplement pas mes sentiments . Les émotions m'ont aidé à régler la situation, à m'aider moi-même. Par exemple, maintenant la sortie est isolée dans une bibliothèque séparée avec des tests approfondis, et je me sens beaucoup mieux chaque fois que je dois entrer dans ce code et faire quelque chose. Ce n'est toujours pas mon meilleur travail, mais c'est déjà une grande amélioration - au moins d'un point de vue émotionnel - par rapport à l'état précédent.

Les émotions sont une chose amusante car elles peuvent vous conduire dans des états vraiment incroyables. Supposons, dans l'exemple précédent, que certaines raisons techniques suffisent pour réécrire le code de sortie? Ici, vous devez prendre une décision. Mais s'il n'y a pas de motivation, je n'oserai peut-être jamais refactoriser. Et sans refactorisation, la base de code va probablement stagner et le programme commencera à échouer, ou une combinaison des deux. Si les émotions donnent de la motivation, le refactoring ouvrira un bien meilleur avenir, où vous pourrez implémenter plus de fonctions dans le logiciel sans compromettre la fiabilité.

Les émotions ont un inconvénient. Quiconque a publié et pris en charge un logiciel assez populaire était sûr de contacter d'autres personnes. Il s'avère qu'une autre personne peut avoir un effet étonnant sur votre état émotionnel. Un geste ou un commentaire positif peut égayer votre journée. Le même sentiment: oui, le téléchargement de mon code était si important qu'il a aidé cette personne . Mais, comme tout responsable le confirme, les commentaires positifs sont presque toujours éclipsés par les commentaires négatifs.

Les commentaires négatifs ne sont pas si mauvais. Il s'agit d'une conséquence naturelle du partage de code lorsque vous invitez d'autres utilisateurs à l'utiliser et à signaler des problèmes . Lorsqu'un message d'erreur apparaît, vous sentez que vous avez échoué cet utilisateur. Lorsque vous avez écrit le code, vous étiez sûr de l'avoir suffisamment testé, mais il est toujours incorrect . Les rapports de bogues ne s'arrêteront-ils jamais? Combien de temps cet utilisateur a-t-il perdu en raison d'un bug? Combien de temps me faudra-t-il pour tout réparer? Pas même cela: combien de temps me faudra-t-il pour passer simplement à un mode dans lequel il y a au moins l' espoir de le réparer?

Ces pensées peuvent conduire à des émotions qui commencent à vous éroder. Et c'est le scénario le plus probable en ce qui concerne les commentaires négatifs.

Négatif purulent

J'ai rapidement appris à surmonter les émotions négatives des rapports de bogues. En fait, les bons messages d'erreur faciles à lire deviennent rapidement agréables car ils sont généralement très rares. La plupart des bogues ne sont pas reproduits du tout, même si vous fournissez un modèle pour le problème avec des demandes explicites pour tous les paramètres (modèle de problème). L'expéditeur veut probablement le meilleur, mais les informations ne sont tout simplement pas suffisantes pour reproduire l'erreur. Et l'agitation commence d'avant en arrière pour tenter d'isoler le bogue.

Pour moi personnellement, c'est le domaine le plus douloureux. Les émotions prennent le dessus parce que je ne peux penser qu'à une chose: pourquoi cette personne n'a-t-elle pas pris le temps de lire et de remplir le modèle du problème ? Ou si un bug se produit en raison d'une erreur d'un utilisateur qui n'a pas lu la documentation, je ne peux que penser: j'ai pris le temps de donner un logiciel à cet utilisateur, et il ne peut même pas lire le fichier README avant de soumettre un rapport de bug?

C'est fou. Bien sûr, les émotions ne sont pas toujours rationnelles. La documentation pourrait probablement être plus claire. Ou l'utilisateur n'a peut-être pas remarqué cet élément. Peut-être qu'il n'a pas d'expérience dans la gestion de projets FOSS ou la soumission de rapports de bogues et, peut-être, il ne sait pas comment aider à la simple reproduction d'un bogue. Toutes ces hypothèses sont tout à fait raisonnables, et c'est pourquoi je fais de mon mieux pour que les émotions ne prévalent pas. Bien que l'empathie avec la personne à l'autre bout du fil soit également importante.

Supposons que je ne dise «je vous invite à utiliser mon code» nulle part, mais je fais beaucoup de choses simplement parce que mon intention est que d'autres utilisent mon code. J'écris une documentation plus détaillée, des exemples d'utilisation. J'ai mis en place des tests d'intégration continue. Made README pour les débutants. Le lien vers le projet est indiqué sur plusieurs de mes pages. Si les gens acceptent cette invitation à utiliser mon code ou considèrent un traqueur de bogues ouvert comme une invitation à signaler des erreurs, je ne devrais pas les punir lorsqu'ils envoient réellement ces messages. L'auteur d'un mauvais rapport de bug pense probablement qu'il a fait tout son possible. Et bien qu'ils agissent par bonnes actions, j'essaie vraiment de répondre de la même manière.

Cela souligne l'asymétrie entre les utilisateurs et le mainteneur. Les auteurs de nombreux rapports de bogues peuvent échanger un ou deux messages avec moi. Pour eux, un rapport de bogue mal écrit n'a pas vraiment d'importance. Mais je suis du mauvais côté, parce que cette scène se joue encore et encore dans tous mes projets. Tout le temps. Presque tous les jours. Il est extrêmement difficile de maintenir l'empathie dans une telle situation, surtout si vous avez une mauvaise journée. Ce qui arrive parfois.

Parfois, mon impatience se manifeste par des réponses trop courtes. Je fais de mon mieux pour m'améliorer à cet égard. Le processus d'auto-amélioration n'est pas encore achevé.

Travailler par le pouvoir

Si vous êtes le responsable d'un projet populaire ou de plusieurs référentiels réguliers, vous obtenez un flux presque continu de rapports de bogues et de demandes de pool. Ils viennent tous les jours. Rester avec lui est presque impossible. La taille du cache de mon cerveau est exceptionnellement petite, donc je ne suis pas très bon pour changer de contexte entre les projets. À la suite de ce phénomène, j'ai rapidement généré des rapports de bogues et regroupé les demandes pour les projets avec lesquels j'ai récemment travaillé. Ces projets sont probablement plus accessibles ou mieux abordés dans les dernières pages de la cache du cerveau.

Mais dans d'autres projets, la liste des problèmes commence à s'accumuler. Chaque jour, vous voyez un nouveau problème et vous vous dites: "Oui, je vais vraiment regarder ça dès mon retour du travail." Mais quelque chose de nouveau arrive. En conséquence, la motivation pour changer de contexte n'apparaît que lorsque l'utilisateur vous envoie un ping mensuel pendant quatre mois - probablement sa demande de pool est vraiment importante.

Désolé, il y avait un petit sarcasme dans la dernière phrase, mais en même temps c'est vrai. L'asymétrie des utilisateurs et des mainteneurs est de retour, mais j'essaie vraiment de vider le pool de files d'attente de demandes et de développer le projet. Je veux contribuer à cet utilisateur, non seulement pour continuer à utiliser mon code, mais aussi pour le rendre heureux . Dans de nombreux cas, une heure suffit pour résoudre les demandes de pool et tous les problèmes qui nécessitent une action.

Mais j'ai passé quatre mois à regarder avec tristesse les problèmes qui se posent à ceux qui entrent sans solution.

Pour ce phénomène, j'ai appliqué une méthode que j'utilise très efficacement dans ma vie personnelle: fixer des limites. Poliment, mais fixant fermement des limites est l'un de ces hacks de vie magiques qui rapporte des dividendes dès que vous l'apprenez. Si vous ne savez pas comment faire cela, je peux difficilement vous l'expliquer. Cependant, fixer des limites vous permet de vous concentrer sur ce qui est important pour vous , pas sur les autres .

De toute évidence, il faut rechercher l'équilibre. L'établissement de limites ne signifie pas que vous pouvez vous concentrer uniquement sur vos propres affaires. Mais la possibilité de mettre en place ce mur et de dire: "Non, je ne fais pas X, mais je ferai volontiers Y" - cela a vraiment fait des merveilles pour moi. Mon secret est de faire des arguments que les autres ne peuvent pas contester sur la base de ma propre expérience et de mes souhaits.

Qu'est-ce que cela a à voir avec l'open source? Pour moi personnellement, la clé était d'établir une frontière entre moi - et tous ces problèmes orphelins avec les demandes de pool. Vous devez en quelque sorte vous impressionner: «Je passe volontairement mon temps, et il est normal que je ne réponde pas à temps. Je suis sûr que la plupart des gens comprendront cela et seront raisonnables. "

Cela apparaît également lors de la discussion des demandes de nouvelles fonctionnalités. Parfois, la demande peut avoir un certain sens pour votre projet, mais cette fonction implique une lourde charge de support. J'ai appris à fixer des limites: vous ne pouvez dire «non» à une fonction qu'au motif que vous ne voulez pas consacrer plus de temps au support. Comme cela s'est produit plus d'une fois, vous pouvez changer d'avis! Par exemple, si le code s'est amélioré, devenez plus accessible pour la maintenance - vous remarquerez peut-être en vous plus de désir d'introduire de nouvelles fonctionnalités. Mais sinon, je fais de mon mieux pour tâtonner mes limites et refuser de me charger d'un travail supplémentaire qui ne fait pas plaisir.

Je voudrais écrire des instructions étape par étape sur la façon de fixer des limites fermes et d'arrêter de se sentir mal en raison d'une pile de problèmes. Cela n'élimine pas complètement le négatif, mais cela aide beaucoup.

Grossièreté

Les trolls évidents sont généralement faciles à gérer. Il s'agit d'un groupe de personnes avec des intentions évidentes de vous énerver. Les trolls n'envoient généralement aucun code, il n'est donc pas nécessaire d'accorder beaucoup d'attention à leurs commentaires. C'est du moins ce que je me dis dans le cadre du mécanisme de défense. Si je vois un troll, je le signale généralement à l'appui de GitHub avec blocage ultérieur. En général, je rencontre très rarement de tels personnages, donc ici, je semble avoir de la chance.

Mais l'impolitesse prend plusieurs formes. Mon émotivité définit un cadre de décence assez serré, vous ne pouvez donc pas considérer toute cette grossièreté. Mais de mon point de vue, c'est au moins grossier.

"Votre outil ne fonctionne pas [pour mon cas de niche], il est donc cassé."
"Je vais juste intervenir pour dire que j'aimerais aussi cette fonctionnalité" (Remarque. Il semble que certains lecteurs ne peuvent pas accepter ce que j'appelle "l'impolitesse". Peut-être que c'est un mot trop fort, mais quand dans la discussion, ils accumulent une telle " "Modules complémentaires", cela ajoute simplement du bruit à l'e-mail et peut être ennuyeux. Au lieu de cela, les émoticônes sont les bienvenues ou vous pouvez ajouter quelques détails à votre cas d'utilisation spécifique. Cependant, il semble assez petit en arrière-plan, et je le vois vraiment ici astiquement mon problème).
Pour insister sur le fait que pour implémenter la fonction, vous devez " simplement faire X".
Agression passive lorsque vous transmettez une demande de fonction.
Harcèlement non constructif sur les logiciels dans [insérer ici tous les médias sociaux].
Variations sur le thème «Pourquoi réinventez-vous la roue?» Ou «Pourquoi ne pas contribuer à un projet existant à la place?»

Dans de nombreux cas, l'impolitesse est le résultat d'une véritable déception de la part de l'utilisateur. Combien de fois avez-vous murmuré sous votre souffle quand un instrument ne s'est pas comporté comme vous le souhaitez? Peu importe que cet outil vous soit probablement présenté gratuitement. Vous essayez simplement de résoudre un problème et l'outil se met en travers de votre chemin. Je l'ai moi-même vraiment ressenti. À mon avis, un sentiment humain tout à fait normal.

Parfois, l'impolitesse prévaut, qui s'exprime de diverses manières improductives. Je sais que je l'ai fait moi-même et, bien sûr, cela s'est également produit de l'autre côté. C'est incroyablement bouleversant pour toutes les personnes impliquées.

Dans d'autres cas, certaines personnes elles-mêmes ne comprennent pas leur grossièreté. Peut-être à cause de la barrière de la langue, ou parce qu'ils ne savaient tout simplement pas comment leurs mots affecteraient les autres. Assez innocent, mais cela ne change pas les sentiments de ma part.

Faire face à ce genre de grossièreté peut être très difficile. Ces problèmes ne dérangent peut-être personne, mais je n'en fais pas partie. Je pourrais prétendre que cela ne me dérange pas, mais je suis sûr que cela conduira à une insulte à l'open source et encore plus de déception.

Là encore, l'établissement de limites m'a aidé. Si nous jetons les trolls, la grande majorité des vivaneaux réagissent généralement assez bien, si vous les abordez poliment. J'ai souvent fait cela dans mes trackers de bogues, et cela a généralement amélioré la situation. Je ne me sens pas insulté parce que je me protège, et en même temps je me sens mieux quand l'autre personne s'excuse, ce qui arrive dans la grande majorité des cas.

Pour ce faire, il suffit de dire simplement: "Je n'aime pas la façon dont vous avez dit X. Je pense que ce sera beaucoup plus productif si nous refusons de tels appels à l'avenir."

Mais dans certains cas, les gens ne répondent pas très bien à de tels mots. D'après mon expérience, ils les ignorent généralement. S'ils continuent d'être impolis, je peux répéter cela plusieurs fois, car certains ont besoin d'entendre quelque chose plus d'une fois pour les atteindre. Au moins, je le sais par moi-même (au grand dam de ma femme). Si cela ne fonctionne toujours pas et que leur ton me dérange toujours, alors j'arrête d'interagir. Fermez ou bloquez simplement le problème ou la demande de pool, ou allez plus loin jusqu'à ce que l'utilisateur soit bloqué sur [insérer les médias sociaux ici].

Autorité

Il était une fois, j'ai discuté avec des amis proches qui voyageaient à l'étranger. De retour aux États-Unis, ils ont partagé un petit exemple de choc culturel. La chose principale?

Je n'ai jamais pensé à quel point les Américains aiment forcer .

Que ce soit une caractéristique de toute la culture américaine ou simplement de l'environnement - nous ne discuterons pas. Le fait est que certaines personnes aiment parler de ce que d'autres devraient faire. J'ai grandi avec de tels flux de gens des niveaux les plus différents de la hiérarchie du pouvoir - et je ressens vraiment un dégoût inné pour cela.

Je suis absolument convaincu que la plupart des gens ne réalisent même pas un tel comportement. Certains ne veulent pas entrer dans votre vie, mais essaient simplement de donner des conseils. C’est du moins ainsi qu’ils réagissent lorsque je signale des cas de coercition particulièrement flagrants.

Prendre un peu de recul, utiliser le mot «devrait» n'est pas nécessairement mauvais en soi. Mais ce qui change vraiment de sens, à mon avis, c'est la présence d'une invitation . Si vous avez demandé conseil à quelqu'un sur un sujet, et qu'il dit quelque chose comme «Oui, vous devez faire X», cela ne sonne pas si mal. , .

:

.
[ ].
.
[ ].
.

, - . . , , - , . , - , - , .

, , . :

, « ?», , . FAQ .
. , - , .

, . , Rust, UNLICENSE . - «» , () , . . . - , .

, . - , . . , .

, . , , , - .

, - ( ), . . . -, . - , — , , — . , -: - , .

. . , , .

. open source. , , , .

FOSS — . , . FOSS , , . , .

, . - , , , .

. , . :

, , ?
?
?
?

, . , . , . . — , . , , .

, JSON, , . , / . .

, , . . , . , , . , .

, , . , , FOSS.

,

. : « ?» , . . , , . , ( ) .

, :

, . , . , : «, , . ».
-, .
-, , , . — , .
changelog, , . , , .
, , . , .
. , , .
. , , .

, — — . . , , , . .

Conclusion

FOSS, . , . , . , . , , . , . - , FOSS.

, , , , . , .

Dans l'article, j'ai énuméré de nombreux types de comportements que je considère comme négatifs. Tout le monde ne les perçoit pas aussi négativement que moi. C'est normal et attendu . De plus, j'ai moi-même fait certaines de ces choses négatives. Les gens ne sont pas parfaits et nous ne pouvons jamais être pleinement réactifs à 100% du temps. Ce sont des questions subtiles, et j'espère que nous pourrons améliorer la situation, au moins un peu.

Ma relation avec l'open source