Journal 6 ans de projets libres: bilan et bien être du mainteneur

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
51
20
déc.
2016

Sommaire

Chaque année je présente ce que j'ai appris en participant à un projet libre. L'année dernière, j'ai clos un premier cycle sur mon retour d'expérience de 5 ans de pratique. Pour démarrer ce second cycle, je vais parler des difficultés que le succès du projet peut engendrer. Je voudrais aussi revenir sur l'héritage de Pieter Hintjens, un développeur renommé décédé cette année. Mais pour ne pas non plus trop déprimer, je vais partager une autre de mes découvertes, la disposition de clavier bépo ! Et oui, le libre ne s'arrête pas au code et peut avoir des impacts sur d'autres domaines. Mais avant toute chose, petit retour sur l'année passée !

Ce que j'ai fait cette année

J'ai principalement travaillé sur le projet libre Cozy. Etant donné que c'était mon activité professionnelle et que j'étais fondateur du projet, j'ai pu intervenir à tous les niveaux : du développement jusqu'à la promotion en passant par l'animation de la communauté. Les technos employées étaient du Javascript/Coffeescript. Toutefois, suite à la montée en popularité de ES6, nous avions entamé une lente conversion vers ce nouveau standard. J'ai ensuite été écarté de ce projet. J'ai donc dû arrêter de travailler dessus et trouver une autre occupation.

Pour me remonter le moral, j'ai commencé par refaire mon setup d'auto-hébergement. Après ça, j'ai fait beaucoup de veille techno. Ensuite, je me suis remis à produire en réalisant un site libre listant les événements techniques à venir. Après avoir pris de grandes vacances, j'ai voulu me lancer dans des contributions (Javascript, Python). Mais mon compte en banque m'a vite rappelé à l'ordre et n'ai donc pas pu aller très loin car j'ai repris une activité professionelle.

Dans mon dernier bilan, j'avais pour idée d'explorer le Go et le Lua mais je n'ai pu creuser que le premier. Go est un langage intéressant pour ses fonctionnalités (go routine et stream notamment) mais n'offre pas la souplesse d'un langage interprété. Je le mets donc de côté pour le moment et ne l'inclut pas dans ma boîte à outil.

L'année dernière, j'avais aussi parlé de mener des expérimentations sur du code en Esperanto. Elles n'ont toujours pas démarré et je ne sais pas quand je pourrai m'y mettre.

Voilà pour tout ce que j'ai fait concrètement. Maintenant cap sur les enseignements que j'en ai tirés !

Bépo

Bépo

Le bépo est une disposition de clavier ergonomique adaptée à la rédaction de textes en français. Découvrir ce concept est une expérience intéressante car il revient à remettre en cause un standard comme la disposition azerty. Par contre le changement est dur. Et oui, modifier sa manière de taper à l'ordinateur après plus de 20 ans de pratique, ça chamboule pas mal !

Grâce au très bon site d'exercice bépodactyl, j'ai pu apprendre en quelques mois à utiliser cette disposition. J'ai même du remettre au propre ma manière de répartir mes doigts sur les touches (et oui je vous parle de digital !). Je tape maintenant avec mes dix doigts et j'alterne l'usage de la touche maj. Mais surtout le mouvement de mes doigts est beaucoup plus limité et logique. Ce changement m'a tellement plu, qu'aujourd'hui je ne tape plus qu'en bépo. Par contre j'ai maintenant du mal à utiliser l'azerty. Ce qui parfois peut être gênant.

L'autre aspect sympathique du bépo, c'est sa communauté. Il y a plein gens passionnés prêts à vous donner des conseils et vous faire découvrir des claviers mieux pensés. Certains proposent des touches bien alignées et revoient la position des touches "entrer" et "suppression". Pour ma part j'utilise le Typematrix mais je suis attiré par l'Ergodox. Affaire à suivre !

Pieter Hintjens

Pieter Hintjens
Photo Tim Lossen

Pieter Hintjens était un développeur reconnu dans le milieu des systèmes distribués. Il s'est notamment fait remarquer avec le protocole AMQP et l'outil / protocole ZMQ. Malheureusement, il est décédé le 4 octobre de cette année. Il était en phase terminale de cancer mais il est resté en assez bonne santé jusqu'au bout. Il a donc pu anticiper sa mort et a ainsi publié le protocole du décès, un ensemble de bonnes pratiques pour organiser sa fin.

Pendant ses derniers mois, Pieter a beaucoup publié. Je le connaissais déjà par son très bon guide de ZMQ et je n'ai pas été déçu de ses nouveautés. J'ai pu aussi découvrir des écrits plus anciens. Apprendre de ses contenus est l'action par laquelle j'ai le plus progressé cette année sur les question du logiciel libre et du développement. Son analyse des communautés et de la bonne manière de faire est une mine d'or.

En très résumé, il nous indique qu'un logiciel est avant tout une affaire de gens. Les meilleurs logiciels sont réalisés par des groupes diversifiés et non par des génies. Les humains sont plus efficaces lorsqu'ils agissent comme des fourmis plutôt qu'en faisant un exploit solitaire. Enfin, il définit un bon code comme étant un code qui marche, qui résout un problème et qui est utilisé.

En partant de ces postulats, il considère qu'une architecture parfaite est secondaire. D'autant plus qu'elle repose déjà sur un grand bazar (pas une de vos dépendances n'est codée pareil). Par conséquent, lorsqu'on réalise un projet communautaire, toute contribution est bonne à prendre. Il nous invite à donc à être laxiste sur les conditions d'acceptation d'un patch. Ainsi, on permet une plus grande participation. Une intelligence collective se met en œuvre. Le groupe peut proposer des solutions plus pertinentes et adaptées. L'ensemble des intervenants est plus motivé. Ce qui attire plus de monde et diversifie la communauté. Elle passe ainsi dans un état propice à la résolution pertinente de problèmes.

Pour lui, le ou les mainteneurs principaux sont chargés de la bonne application des règles établies par le groupe. Cela évite de chercher tout le temps le consensus. Si un patch respecte les règles il est accepté. Si non, il est refusé. On évite ainsi les discussions stériles.

Pour aller plus loin, je vous recommande le talk Building Open Source Communities, son livre Social Architecture et cet article sur ce qu'est du bon code.

Les risques pour le mainteneur principal

Feuille morte
Photo: Maladova sur Flickr

Maintenir un projet libre avec des utilisateurs est très plaisant. Mais cela peut vite devenir une expérience désagréable.

En effet, le mainteneur principal, malgré son mérite, peut devenir un problème pour le projet et lui même. Son expertise le pousse à devenir exigeant sur les contributions. Le coût d'entrée pour participer devient donc élevé. Plus de réparations dépendent du mainteneur. Les "pull requests" restent ouvertes longtemps et les échanges s'allongent. La quantité de travail s'accumule. La pression sur le mainteneur augmente.

Même si la situation est positive car le projet a du succès, pour le mainteneur ça se complique. Il devient tendu. Il culpabilise de ne pas pouvoir répondre à tout le monde. A l'inverse, quand une critique est trop forte, il la prend personnellement. C'est assez dur à avaler. Il doit apprendre à porter une armure de fer et toujours se motiver pour faire avancer les choses sans s'emporter. Malheureusement parfois il dérape et fait des dégâts.
L'excitation peut aussi s'avérer dangereuse. Non seulement le mainteneur se repose moins mais en plus l'euphorie peut donner une assurance qui rend aveugle. Elle peut amener à des tensions qui entraîne une mauvaise spirale.

Certains mainteneurs chanceux profitent d'un cadre commercial. Mais pour d'autres, il n'y a pas d'autres rétributions qu'une gloire éphémère. Dès que cette gloire s'amenuise, il est tentant d'en faire plus pour la retrouver. Résultat on constate régulièrement des états de burnout chez les mainteneurs, même en faisant un travail bénévol. Il y a des cas connus comme celui du mainteneur de Bootstrap,, de TJ Holowaychuk, qui a porté le début de Node.js par ses nombreuses bibliothèques, ou de l'auteur de Moment.js. Et je ne parle là que de l'éco-système Javascript… Pour ma part je n'ai heureusement pas trop souffert de ces problèmes, mais si Cozy avait eu un aussi grand succès que Bootstrap, je ne sais pas si j'aurais pu gérer tous les désagréments que j'ai cité aussi facilement.

Dans les cas d'arrêt brutal de contribution, les mainteneurs arrivent à concéder leur réalisation. La passe d'arme se fait souvent bien. Ce qui est rassurant.

Même si avoir un projet à succès comporte plein d'avantages, il ne faut pas oublier que trop de bonnes choses peuvent amener à l'indigestion. Il faut aussi prendre en compte que le projet doit pouvoir continuer si vous arrêtez du jour au lendemain. Pour remédier à ça, la méthode de Pieter Hintjens est très efficace et vous évitera bien des soucis. En bref, si vous vous lancer dans un projet libre, prenez ce risque en compte et votre expérience ne sera plus que du bonheur !

Conclusion

Cette année, j'ai appris que n'importe quelle habitude peut être remise en cause, que la clé d'un bon projet libre est avant tout une histoire de diversité et qu'il faut savoir se ménager surtout si on rencontre du succès.

Pour l'année prochaine, j'aimerais toujours avancer sur cette idée de code en esperanto. J'espère aussi pouvoir créer un projet libre ou participer activement à un autre. Ce qui me permettra d'écrire une septième année de bilan. Dans tous les cas merci à tout ceux qui m'ont suivi et soutenu dans cette démarche libriste pendant ces six premières années !

  • # Liens cassés vers des images

    Posté par  (site web personnel) . Évalué à 1.

    Liens sont cassés vers tes images.

    Pieter's best friend.

  • # Un peu de retape

    Posté par  (site web personnel) . Évalué à 3.

    Et puis tant que j'y suis, un peu de retape pour ZeroMQ:

    http://zeromq.org/event:zeromq-pre-fosdem-hackaton-thu-2-fri-3-feb-2017

  • # Mainteneur, communauté et BÉPO

    Posté par  (site web personnel, Mastodon) . Évalué à 8.

    Hello,

    J'apporte mon grain de sel à ce journal, parce que si les projets et technologies sont différentes de mon expérience, j'ai l'impression que le ressenti est proche.

    Maintenir un projet

    Entre l'automne 2014 et l'été 2016, j'ai été « directeur technique » de Zeste de Savoir. C'est un bien grand terme pour dire que mon rôle était de gérer la cohérence technique du projet et à s'assurer qu'il avance (et des fois à coder moi-même).

    Mais même comme ça, avec une association derrière et pas mal de contributeurs motivés, l'effet d'usure se fait sentir. Parce qu'on a l'impression de tourner en rond, que la gestion prends du temps, parce qu'on a envie de passer à autre chose.

    Il faut savoir passer la main (c'est difficile) et surtout savoir la passer avant qu'il ne soit trop tard (c'est encore plus difficile). Parce que l'usure est un processus lent et pernicieux : au bout d'un moment, gérer le projet devient une routine, et tout à coup on se rends compte qu'on ne peut plus y participer sans râler, ou qu'on y va qu'à reculons – et là il est plus que temps de partir avant que quelque chose casse, soit chez soi (cf les cas de burnout), soit dans le projet.

    Et je ne parle même pas de la gestion de l'humain, qui devient catastrophique quand l'usure arrive (déjà que personnellement je ne suis pas bon là-dedans et déteste ça). Et un projet où chaque PR ou issue peut devenir un conflit sans prévenir, c'est pas terrible (heureusement, on a limité la casse de ce point de vue sur Zeste de Savoir).

    Un projet avec du monde derrière

    L'avantage de Zeste de Savoir, c'est qu'entre l'association et la communauté, il y a du monde pour développer. Généralement.

    Sauf que ça ne veut pas dire que trouver quelqu'un pour reprendre la gestion est facile. Il faut quelqu'un de confiance, qui partage la même ligne directrice, en qui on (l'association, en particulier) a totalement confiance, qui a le temps et la motivation de s'occuper tout ça.

    Quand je vois comme on a galéré pour trouver quelqu'un (deux personnes en fait, qui se partagent le travail), je me dis que pour tous ces projets petits en équipe de dev mais connus donc avec une vraie charge de travail, l'abandon du contributeur principal c'est probablement la mort du projet, sauf miracle.

    Mais comment faire en sorte que ces transitions se passent mieux ? Surtout que du côté développeur occasionnel, ou utilisateur du produit, le phénomène d'usure peut être complètement invisible – donc comment proposer son aide si on ne sait pas qu'il y a un besoin à ce niveau ?

    Je n'ai pas de réponse. Peut-être que l'organisation en associations et/ou communautés de développeurs pour rassembler la maintenance de projets semblables peut aider ? J'ai quand même un doute en pratique

    BÉPO

    Digression : je me suis aussi mis à BÉPO. On m'avait dit que c'était catastrophique pour développer. C'est vrai que taper de l'anglais n'est pas le plus agréable (le w est particulièrement inaccessible) ; mais au final je trouve que cette disposition est aussi bonne que AZERTY pour le développement (Java, Python principalement). Ou aussi mauvaise, comme vous voulez :)

    La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Mainteneur, communauté et BÉPO

      Posté par  . Évalué à 3.

      Pour programmer en bépo il existe plusieurs variantes (béop, programmer béop, etc).
      J'ai pas encore essayé mais c'est tentant.

      Pour l'ergodox je suis aussi tenté mais le prix est assez rebutant (oui je parle bien de l'ergodox à monter soi même, ceux tout fait perdent 90% de l’intérêt de la chose).

      • [^] # Re: Mainteneur, communauté et BÉPO

        Posté par  (site web personnel) . Évalué à 4.

        Je programme en bépo et je trouve cette disposition mieux que l'azerty pour coder. Certaines touches comme les accolades, ou les crochet pourraient être plus accessibles mais dans ça l'ensemble ça reste acceptable.

        Là où ça a été plus difficile, c'est pour l'utilisation de vim. J'ai du remapper pas mal de touches. J'ai failli craquer et repasser en azerty à ce moment là mais au final je m'y suis bien fait. Par conséquent, ma config de vim devient très personnalisée. Ce qui fait que je ne suis efficace avec vim que dans le cadre de mes paramètres.

    • [^] # Re: Mainteneur, communauté et BÉPO

      Posté par  . Évalué à 3.

      Digression : je me suis aussi mis à BÉPO. On m'avait dit que c'était catastrophique pour développer. C'est vrai que taper de l'anglais n'est pas le plus agréable (le w est particulièrement inaccessible) ; mais au final je trouve que cette disposition est aussi bonne que AZERTY pour le développement (Java, Python principalement). Ou aussi mauvaise, comme vous voulez :)

      Ce qui m'embête avec bépo c'est les raccourcis clavier. Même hors d'emacs/vim, il ont souvent une logique, on place proche des raccourcis qui s'utilisent ensemble par exemple et j'ai pas envi de remapper tous mes raccourcis d'un tas de logiciels (vim, VS code, idea, firefox, zsh, awesome,…).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Mainteneur, communauté et BÉPO

        Posté par  . Évalué à 2.

        A l'époque, j'avais résolu le problème en changeant mon layout pour coder, que je gardais en azerty, et pour écrire que je passais en bépo.

        Ça permet également de garder en mémoire les deux systèmes. Mais ça prend plus de temps pour maîtriser le bépo.

      • [^] # Re: Mainteneur, communauté et BÉPO

        Posté par  (site web personnel) . Évalué à 2.

        J'avais fait l'effort d'apprendre à taper en bépo, jusqu'à arriver à tenir une conversation sur un chat. Sauf que coder en bépo n'était pas du tout agréable pour moi. Et vim était vraiment une horreur à utiliser en bépo.

        Finalement je suis passé en qwerty us international avec les variantes qui vont bien. Je le trouve plus pratique pour rédiger des textes en français, et plus pratique pour coder. Bref, que des avantages par rapport à l'azerty. Le seul point noir c'est quand on veut aller aider un collègue et qu'on galère à utiliser leur clavier azerty, et l'inverse est encore pire pour eux.

        • [^] # Re: Mainteneur, communauté et BÉPO

          Posté par  . Évalué à -1.

          Pour tous ceux qui ont des doutes sur la programmation en bépo, je vous conseille le Bépo-altgrsym-3.

          Faite par un technicien pour les techniciens : l’idée étant de rendre AltGr symétrique (d’où le nom), ce qui permet de rendre accessible les caractères spéciaux utilisés en prog, shell, etc.

          Seul bémol : faudrait que je me bouge pour sortir un Bépo-altgrsym-4 qui limiterait au minimum nécessaire les changements de touche vis-à-vis de la 1.0. Histoire de limiter la casse quand on est sur son ordi, mais que le bépo officiel (1.0) est dispo avec un coup de setxkbmap/loadkeys.

  • # Lien cassé vers hackerevents.org

    Posté par  (site web personnel) . Évalué à 3.

    Une faute de frappe qui casse le lien

  • # Bépo

    Posté par  . Évalué à 2.

    A le bépo. Une super disposition de touches. Mois aussi j'utilise le TypeMatrix avec le bépo et c'est un bonheur. Sinon un des langage que je vais explorer est sûrement le langage Rust de Mozilla.

  • # Ergodox

    Posté par  (site web personnel) . Évalué à 2.

    J’ai un ergodox, que j’ai du souder moi-même et j’en ai bavé parce que c’est pas mon truc, mais ça vaut le coup je trouve, j’aime beaucoup :-)
    Ya quelques trucs qui m’énervent parce que le configurateur graphique marchait mal du coup j’ai jamais eu ce que je voulais pour certains trucs (touches copier et coller, touches multimédia, calques que j’aurai voulu avoir).
    Ya moyen de régler ça en programmant sa disposition mais j’ai pas eu le courage.

    En tous cas je recommande, pour le bépo c’est hyper cool. Faut trouver un moyen pour incliner les deux parties pour être vraiment bien, moi je les pose sur les cotés de mon PC portable et l’angle est pas mal.
    J’ai pris des switchs brown et je regrette un peu, j’enfonce quasiment toujours les touches à fond je me dis qu’avec des clears j’aurai peut-être réussi à prendre le réflexe du touch-typing.

    Aussi ya aucun repère sur les touches founies avec donc faut se les faire soi-même, j’ai mis une pointe de glue sur E et T, ça se sent bien au toucher pour retrouver ses marques.

    Je m’en sers beaucoup pour coder et l’anglais et ça reste bien mieux que l’azerty quand même, je suis étonné des commentaires plus haut sur le bépo. Que certains préfèrent le qwerty ou des dispositions optimisées code je peux le concevoir, mais l’azerty c’est vraiment mauvais sur beaucoup de points, et c’est pas avoir le w sur un petit doigt qui peut suffir à rendre le bépo moins bon.
    Sur un ergodox ya moins de choses sur le petit doigt avec tout ce qui va sur les pouces et à gauche, donc le petit doigt peut bien gérer le w en échange :-P

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.