[fr] 6 ans de projets libres : bilan et retour d'expérience

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'inclus 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

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 é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 pertinente est bonne à prendre. Il nous invite à être laxiste sur les conditions d'acceptation d'un patch (au niveau de l'architecture logicielle). Ainsi, on permet une plus grande participation. Une intelligence collective se met en oeuvre. 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 anodines.

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

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 request 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égats.
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 !