URL: https://linuxfr.org/users/gelnior--2/journaux/3-ans-de-projets-libre-bilan-et-apprentissages Title: 3 ans de projets libre: bilan et apprentissages Authors: gelnior Date: 2013年11月26日T11:30:21+01:00 License: CC By-SA Tags: retour_d_expérience, cozycloud, libre, développement, talk, communauté et sensibilisation Score: 59 Et oui ça va devenir presqu'une tradition, comme les deux années précédentes ([1](https://linuxfr.org/users/gelnior--2/journaux/un-an-de-projet-libre-bilan), [2](https://linuxfr.org/news/deux-ans-de-projet-libre-bilan)), je partage avec vous mon retour d'expérience sur une année de développement de projets libres ! Pour rappel, tout a commencé le 19 octobre 2010 (oui, je sais, j'ai un bon mois de retard) alors que je démarrais le projet de réseau social distribué [Newebe](http://newebe.org/). Ce qui m'amena 18 mois plus tard à monter une startup proposant une solution de cloud personnel libre, nommé [Cozy](http://cozy.io). Mes retours d'expérience proviendront essentiellement de Cozy, projet sur lequel j'ai passé le plus de temps. Dans la suite de ce journal vous découvrirez ce que j'ai appris sur les trois thèmes suivants: le développement, la prise de parole en conférence technique et l'animation de la communauté. # Développement Aujourd'hui je ne code plus de la même manière. Je ne cherche plus à coder le plus élégamment possible mais **je cherche à rendre mon code le plus compréhensible possible** (pas de factorisation à outrance, noms de variables et de fonctions explicites...). Heureusement la concision aide beaucoup dans cet optique, du coup le code reste propre. **Automatiser c'est chiant mais ça rend heureux**. Je me suis forcé à écrire plus d'alias bash pour le dev local et de scripts [fabric](http://docs.fabfile.org/en/1.8/) (merci [fabtools](https://github.com/ronnix/fabtools) !) pour les interventions serveurs. Et vous savez quoi ? ça change la vie ! Je passe beaucoup moins de temps sur les tâches répétitives. Au passage, ce [lien](http://matt.might.net/articles/console-hacks-exploiting-frequency/) donne un bon moyen de définir de bons alias à ajouter. De la même manière, **je me suis forcé à utiliser [vim](http://vim.org) dans les règles de l'art**. J'ai commencé par bloquer les flèches du clavier pour naviger seulement avec les touche h, j, k et l. Ensuite j'ai essayé de maitriser plus de raccourcis et changer les bindings qui ne me convenaient pas. Le début était pénible mais aujourd'hui je vais beaucoup plus vite et je fais moins de gestes parasites. De plus c'est vraiment ludique de chercher les combinaisons de clavier efficaces sous vim. Je me suis rendu compte que **les workflows git à base de beaucoup de branches sont un peu surcôtés**. Ils fonctionnent peut être très bien pour des très gros projets mais dans l'ensemble les forks github suffisent largement. C'est le guide zmq qui m'a ouvert les yeux sur le sujet et je dois bien admettre que ça marche : il propose de n'utiliser qu'une seule branche master sur le repo principal tandis que le travail en cours reste dans les forks des contributeurs. Ainsi on garde une branche principale propre et les interactions sont simplifiées. **Diviser son code en module c'est pratique et ça permet de travailler sur des bouts de code sans embêter les autres**. Surtout quand les interactions entre modules ne sont pas si complexes que ça à gérer (du moins pour l'instant). Je me suis lancé dans un développement trop long pour Newebe: j'ai voulu réécrire toute l'interface utilisateur. J'aurais du me contenter de développements plus léger. Conséquence ? je me suis un peu découragé, j'ai passé beaucoup de temps et ce n'est toujours pas terminé... **Garder un fonctionnement en petit pas pour un projet pour lequel je ne donne plus beaucoup de temps aurait été plus adapté**. ![Timeline Github](http://gelnior.files.wordpress.com/2013/11/timeline_github_1113.png) # Talks Dans le cadre de Cozy, j'ai eu l'occasion de faire un bon nombre de [talks](http://fr.slideshare.net/gelnior/). Ceci principalement dans l'objectif de présenter notre projet mais aussi de faire découvrir des technologies que nous utilisons. Pour couronner le tout, j'ai suivi les cours de l'accélérateur de startup de Mozilla : un bon nombre d'entre eux portent sur la pratique du pitch. J'ai bien conscience que j'ai encore beaucoup de progrès à faire à ce sujet mais je me permets de partager ici quelques conseils en vrac pour bien réussir son talk (que j'aimerais d'ailleurs plus appliquer). **Je n'aurais pas du chercher à transmettre trop de nouveaux concepts en même temps**: ça perd les gens plus qu'autre chose. On tombe vite dans ce travers car certains concepts qui peuvent nous paraitre triviaux ne le sont pas pour tout le monde. ex: ce n'est pas parce que vous lisez plein d'articles sur SASS que tout le monde sait ce qu'est un pré-processeur CSS. Chez Mozilla, ils nous ont fait faire un exercice intéressant: **écrire son plan en fonction des questions que le public risque de se poser**. Lors d'un talk vous êtes là pour apporter quelque chose de nouveau mais vous devez aussi répondre à des attentes par rapport à cette nouveauté. Du coup ça m'a permis de remettre en cause mon discours initial pour ma dernière présentation. Lors de plusieurs talks j'ai senti que les gens voulaient poser des questions dès le milieu. **Si vous avez l'occasion de placer une petite session de questions réponses au milieu, faites le !** Les talks sont un peu trop unilatérales, laisser les auditeurs s'exprimer permet de dynamiser la présentation et enrichit votre propos. **J'aimerais plus souvent pensez à parlez vraiment fort pour pouvoir ainsi moduler ma voix. Idem pour le rythme (le flux de parole)**, c'est très utile de jouer dessus. On a tendance à garder un ton monotone, ce qui ne permet pas de mettre en valeur les éléments importants en ralentissant ou en s'exprimant plus fort. Attention si vous avez un micro parler trop fort peu vite devenir insupportable. Parler en public ressemble beaucoup à jouer de la musique en public. Quand on se plante sur une phrase ou qu'on oublie des mots (ça m'arrive souvent...), il faut continuer comme si de rien était. A l'inverse, je vous conseille de vraiment soigner les phrases d'introduction et de conclusion. J'avais beaucoup lu d'article disant qu'il faut occuper l'espace quand on parle sur une scène mais bien souvent il y a peu de place pour se déplacer. Parfois, j'ai même été coincé derrière un pupitre, ce qui peut être assez perturbant. **S'enregistrer est utile pour se rendre compte des points à améliorer**. Par exemple, grâce aux vidéos des rmlls j'ai vu que je faisais souvent des gestes nerveux à répétion. Je n'avais pas toujours le temps de répéter: filer tout son talk prend du temps. J'ai donc appliquer un principe appris en musique: **je ne répétais que les parties que je ne maitrisais pas**. Egalement appris chez Mozilla: **il faut toujours placez un appel à action à la fin du talk**. Ca donne une idée de quelles actions sont à entreprendre pour pouvoir continuer la conversation avec l'orateur. ![Présentation aux RMLL](https://gelnior.files.wordpress.com/2013/11/image-rmll.jpg?w=939) # Communauté Avec Cozy, étant dans un optique entreprise, nous devons faire en sorte que la communauté s'agrandisse rapidement. La difficulté réside donc dans le fait qu'il nous faut plaire à beaucoup de monde tout en conservant notre vision. Certains appellent ça la gestion de communauté (community management), je pense que l'on devrait plus parler de facilitation de communauté. En d'autres termes, l'objectif est de faire en sorte que la communauté puisse s'emparer le plus facilement possible du projet. La chose qui m'a le plus marqué est d'avoir pris conscience qu' **un projet est souvent trop difficile d'accès pour quelqu'un qui vient de l'extérieur**, que ce soit pour contribuer ou même l'utiliser. Pour permettre aux autres d'arriver **il faut donc faire baisser le coût d'entrée au maximum et sur tout les plans**. Deux événements cet été m'ont aidé à m'en rendre compte. D'une part, je venais de lire le chapitre 6 du guide de zmq qui insiste sur la nécessité d'éliminer un maximum de frictions pour accéder au projet. D'autre part, je remarquais que mon projet request-json recevait plus de contributions que n'importe quel module de Cozy. Pourquoi cela ? Tout simplement parce que le concept était très facile à comprendre (un client simple pour faire des requêtes sur des API JSON) et que les sources sont courtes, faciles à lire et tiennent en un fichier. Enfin la documentation prend peu de place et apparaît dès le README. En bref, n'importe qui peut s'approprier le projet en quelques dizaines de minutes. Pour illustrer ce propos sur un projet plus conséquent, voici ce que nous avons faits chez Cozy. * Nous avons rendu notre **documentation plus accessible et visible**. Même un wiki sur github demande parfois trop d'efforts pour être trouvé car les gens n'ont pas le réflexe d'aller jusque là. Nous avons donc mis la documentation directement sur le site. * Les exemples de codes de la doc sont écrits en Javascript et non plus en Coffeescript (ceux qui savent lire le premier sont plus nombreux que ceux qui savent lire le second). * Nous avons rendu aussi le site plus explicite et avons fourni les objectifs que nous nous donnions (conseil tiré du livre [Swarmwise](http://falkvinge.net/2013/02/14/swarmwise-the-tactical-manual-to-changing-the-world-chapter-one/) de Richard Falkvinge). Ainsi cela donne une idée de contribution pour les gens motivés qui ne savent pas par où commencer. * Nous avons aussi simplifié le forum en le remplaçant par un google group à une seule section. * Niveau code Nous avons troqué le [framework de base](http://compoundjs.com/) de nos applications par un [framework plus léger](https://github.com/mycozycloud/americano) proposant une structure de fichiers plus claire. * Enfin, nous avons facilité le démarrage sur Cozy en tant qu'utilisateur en proposant des images prêtes à l'emploi. Les résultats ne se sont pas faits attendre, plus de gens ont posté sur notre forum, le nombre de téléchargements d'applications a presque doublé (passant à 3000 par mois) et nous avons eu le droit à une grosse contribution sur le code. **Cette approche a donc porté ses fruits**. Autre astuce, **un projet modulaire permet aux gens de travailler sur le projet sans avoir besoin de connaitre précisément l'ensemble du code**. Les contributions sont donc facilitées. Deux bons exemples de projets à qui cette approche réussit bien : Weboob, un outil qui permet de consulter du contenu web depuis la ligne de commande. Les contributeurs peuvent créer leur récupérateur de contenus en profitant des outils mis à disposition par le module principal. Et, Zmq, une bibliothèque d'échanges de messages, où la communauté s'est principalement développée autour des bindings pour les différents langages. ![Posts sur le forum]( http://gelnior.files.wordpress.com/2013/11/communaute_cozy.png?w=890) # Conclusion Je suis content d'avoir découvert toutes ces choses, mais maintenant que j'ai un peu plus de recul je me rends compte que **ça aurait été plus efficace de commencer mon expérience de développeur libre en contribuant à un projet existant**, j'aurais sans doute appris ces choses plus vites et dans un cadre plus convivial. Mais bon à l'époque j'avais un besoin pressant auquel répondre (avoir une alternative à Facebook) et pour me lancer il me fallait un moteur fort. Voilà c'est tout pour cette fois, j'ai encore plein de choses à partager mais ça fait déjà beaucoup, donc j'en resterai là. **Merci de m'avoir lu jusqu'au bout et à l'année prochaine !**

AltStyle によって変換されたページ (->オリジナル) /