Sommaire
Et oui ça va devenir presqu'une tradition, comme les deux années précédentes (1, 2), 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. Ce qui m'amena 18 mois plus tard à monter une startup proposant une solution de cloud personnel libre, nommé Cozy. 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 (merci 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 donne un bon moyen de définir de bons alias à ajouter.
De la même manière, je me suis forcé à utiliser vim 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é.
Talks
Dans le cadre de Cozy, j'ai eu l'occasion de faire un bon nombre de talks. 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.
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 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 de nos applications par un framework plus léger 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.
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 !
# Merci pour le retour
Posté par Nicolas (site web personnel) . Évalué à 10.
Même si ton projet est court (dans le temps j'entends) je pense que tu en as tiré une grande expérience. C'est ce que laisse transparaître ton journal. C'est très instructif et enrichissant. Merci.
# Bravo et question
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 26 novembre 2013 à 12:47.
Du libre, mais pas fermé sur le libre pour "experts ayant du temps à perdre" (comprendre le besoin des gens et y répondre : les images disque etc…) comme on voit (trop) souvent, un seul mot : bravo.
toutefois, je suis un peu frustré car de mon point de vue c'est tout aussi important dans un bilan de projet libre : et financièrement, est-ce viable à long terme?
PS : pour troller un peu sur l'actualité pas très vieille, je constate avec effroi que tu passes plusieurs dimanches à coder plutôt que de le passer en famille, salaud qui veut casser le principe du dimanche sacré qu'on ne doit pas utiliser pour travailler, tu devrais être pendu pour ça.
[^] # Re: Bravo et question
Posté par gelnior (site web personnel) . Évalué à 2.
Pour le projet de startup oui, il y a beaucoup d'entreprises qui ont été séduit par le modèle d'Androïd, du coup pouvoir continuer à se concentrer sur leur coeur de métier en profitant d'une plateforme communautaire les intéresse, même si ça implique de payer du service ou de partager les gains engendrés. Je parle ici des fabricants de hardware, de FAI, d'hébergeurs, etc.
# Je t'attendais !
Posté par berumuron . Évalué à 4.
J'apprécie beaucoup tes retours d'expérience et j'ai bien cru que tu n'allais pas le faire cette année, ouf !
Je retiens aussi les conseils, notamment ceux au niveau de la communauté, ça pourrait m'être utile :)
Tu as aussi sans doute appris des choses que tu n'aurais pas apprises en contribuant à un projet existant plus tôt, qui sait ? L'important est de savoir où tu en es aujourd'hui et comment progresser encore plus ; pas nécessairement comment tu en es arrivé là (mais ce n'est que mon avis :))
Bon courage et à octobre prochain !
[^] # Re: Je t'attendais !
Posté par gelnior (site web personnel) . Évalué à 2.
Oui je suis d'accord, en fait je pense que je voulais surtout exprimer le fait que ça aurait bien complété mon apprentissage du développement libre. Les aspects création de projet et participation à un projet existant sont complémentaires et du coup le deuxième me rend curieux.
Je me disais aussi que si quelqu'un passait par là et voulait s'impliquer dans le libre ce serait mieux de lui indiquer de commencer par un projet existant pour connaitre les ficelles et gagner du temps lorsqu'il voudra lancer le sien !
# workflows git à base de beaucoup de branches sont un peu surcôtés...
Posté par cosmocat . Évalué à 7.
C'est ton choix des version supportées qui va impliquer le choix que tu vas faire au niveau de ton worklow git. Si tu dois faire du support (avec correctifs) sur de nombreuses versions, je ne pense pas que des workflow comme gitflow soient sur-côtés. Je ne pense pas qu'un éditeur de logiciel serait du même avis…
Il s'avère juste que tu es pile dans le cas du développement d'un service web donc tu peux te permettre de n'avoir qu'une seule version maintenue car tu n'as qu'une seule version en prod à un moment donné. Dans ce cas, n'avoir qu'une seule branche
masterdans laquelle tu merges tes feature branches (workflow github) est effectivement largement suffisant (jusqu'à ce que tu doives faire un changement 'cassant' dans ton architecture et que pendant ce temps tu doivent continuer à développer la version courante…)[^] # Re: workflows git à base de beaucoup de branches sont un peu surcôtés...
Posté par rewind (Mastodon) . Évalué à 4.
Même quand on est tout seul, gitflow est très bien, ça permet de bien organiser son travail. Je dirais que le choix vient essentiellement du type d'application (web, pas web) plutôt que de la taille de l'équipe.
[^] # Re: workflows git à base de beaucoup de branches sont un peu surcôtés...
Posté par cosmocat . Évalué à 2.
Tout à fait. Il suffit même d'être juste 2 pour que ça permette une revue de code assez facile…
Aussi, e fait de brancher et merger ajoute de l'information et permet une meilleure recherche de régression lorsqu'on a besoin de plonger dans l'historique…
[^] # Re: workflows git à base de beaucoup de branches sont un peu surcôtés...
Posté par gelnior (site web personnel) . Évalué à 2.
Oui c'est vrai pour la v2 on veut revoir notre système de déploiement et maintenir le tout avec un système de branches pourra être utile. ZMQ fonctionne toujours sans branche malgré plusieurs versions, ça vaudrait le coup de voir comment il gère cet aspect.
Pour répondre aux autres commentaires, l'historique et les discussions sont en fait maintenus par les pull requests. Cela rend dépendant de Github, mais ça permet des interactions intéressantes et facile à appréhender pour un débutant git.
Bref après t'avoir lu je me rends compte que le terme sur-côté n'était pas forcément bien choisi et un peu trollesque. En fait ce que je voulais exprimer c'est qu'au début j'en étais fan et je me suis vite rendu que c'était un peu overkill pour nos besoins. Le guide ZMQ pointe aussi du doigt que ce système un peu complexe ne facilite pas l'arrivée de nouveaux venus, ce qui m'avait conforté dans ma position.
# Sur les exposés
Posté par fmaz fmaz . Évalué à 10.
Pour parler plus fort et éviter d'avoir un ton trop monotone—je n'utilise jamais de micro --, j'utilise la technique suivante.
Il n'y a qu'à voir le volume sonore que peut produire un bébé qui pleure pour se persuader que n'importe qui doit pouvoir facilement se faire entendre dans une salle de 50 personnes. Le problème, c'est que quand on n'en a pas l'habitude, on a tendance à se crisper. Le truc est d'oublier les 50 personnes et d'imaginer qu'on parle à un pote qui est au dernier rang. On est tout de suite plus détendu et la voix porte mieux. Pour s'entraîner, on peut prendre un ami et s'amuser à discuter en étant à 30 mètres de distance.
Par ailleurs, quand on cause avec un pote, on n'a pas un ton monotone. On lui raconte un truc, on rythme le discours. Ça corrige aussi le second point.
Une dernière chose. Quand je fais un exposé long, j'essaye de prendre une petite bouteille d'eau et de me forcer à en boire une partie non négligeable. D'une part, parler à tendance à déssécher la gorge, ce qui n'est pas bon pour les cordes vocales. Boire permet de ne pas se détruire la voix. Mais ça force à rythmer le discours. Quand on boit, on ne parle pas.
[^] # Re: Sur les exposés
Posté par vlamy (site web personnel) . Évalué à 3. Dernière modification le 26 novembre 2013 à 14:36.
Je suis assez d'accord, 50 personnes dans un amphithéâtre de taille raisonnable, ça se fait sans micro, mais ça donne soif :)
J'ajouterai quand même que la préparation joue en rôle énorme, même si on n'a pas toujours le temps de la parfaire. Pour les gros nerveux, je conseille d'apprendre le discours par chœur (ce qui n'interdit pas l'improvisation), en mettant l'accent sur les phrases de liaisons (celles qui introduisent les transparents). J'ai pu faire ça une fois pour un gros exposé (en 12H de temps pour un exposé de 45 minutes) et j'avoue que ça a été salvateur : tout le stress s'était envolé et j'ai même pu improviser.
Sinon, pour les « moins expérimentés » (étudiants, doctorants,etc), ne négligez jamais la répétition devant public (même une personne). En effet, comme le dit un peu
gelniordans son journal : on a du mal à ne pas faire trop compliqué au début (5/6 premiers talk).Sinon, tant que j'y suis : joli journal ! Et jolie
futuresuccess story ![^] # Re: Sur les exposés
Posté par Mais qui suis-je ? :) . Évalué à 1.
Faire des bon talks ca vient aussi avec l'expérience mais les astuces données plus tot son vraies,
J'ajouterai juste quelques petits trucs
Ne pas chercher à remplir ou broder : Tu as reservé 15 minutes mais tu n'as de la matière que pour 10 personne ne se plaindra. Il y a un truc qui m… ne le cache pas de toute facon ca se verra
Attention aux slides, un minimum de travail sur le template du slide et sur le choix des couleurs est indispensable, n'hésites pas à tester tes slides sur video projecteurs avant, j'ai trop vu de presentation illisibles avec des courbes en jaunes, et du texte en gris clair. Méfie toi aussi des Daltoniens, si il y en a un influent dans l'auditioire tu vas te faire engueuler si t'as pas penser à eux.
Le soufle et le verre d'eau : Si tu veux pouvoir projeter ta voix en parlant lentement et clairement c'est (juste) une histoire de soufle, Si ta présentation est longue, prévois les moment pour boire le verre d'eau à l'avance, par exemple en montrant une petite vidéo (Ou lors d'un slide de changement de chapitre)
[^] # Re: Sur les exposés
Posté par Le Gab . Évalué à 0.
Que trop vrai mais surtout, ne pas hésiter à faire un essai avec un rétro projecteur ne serait-ce que pour voir que tu n'auras pas de problème technique du genre:
Projection du mauvais bureau (si en mode étendu), si le mode copie ne rogne pas sur ton diapo et simplement voir si un signal vga/hdmi sort ou est compatible car soit dit en passant, c'est souvent le truc bien casse couille qui n'arrive que trop souvent mais il est à noter qu'on peut rencontrer plus d'orateurs se battant avec leur Mac ou Wintel qu'avec des machines sous Linux. :)
[^] # Re: Sur les exposés
Posté par gelnior (site web personnel) . Évalué à 1.
Effectivement je n'ai pas trop parlé des slides, car les remplir me vient plutôt naturellement. Quelques conseils quand même là dessus:
[^] # Re: Sur les exposés
Posté par Dr BG . Évalué à 3.
Le risque du discours appris par cœur (surtout pour les anxieux), est que si on a oublié ne serais-ce q'un mot ou une petite phrase, en prend le risque d'être déstabilisé et de paniquer. Je pense qu'il faut mieux connaître parfaitement son plan, et réfléchir avant aux phrases de liaison comme tu le suggères.
[^] # Re: Sur les exposés
Posté par vlamy (site web personnel) . Évalué à 1.
Personnellement je ne le vis pas du tout comme ça, mais c'est très subjectif j'en conviens. Quand j’apprends le plan, tu peux être sûr qu'à un moment donné je vais bafouiller des conneries le temps de retrouver ce que je voulais dire. Le résultat est très moyen. Cela n'arrive pas quand on a le discours par chœur.
Et de manière général, cela permet de travailler les tournures de phrases, ce qui est super important, surtout quand on parle dans une langue étrangère qu'on « speak very approximatively ».
[^] # Re: Sur les exposés
Posté par fmaz fmaz . Évalué à 1.
La limite à 50 personnes, c'est celle que je pense que n'importe qui peut atteindre. Au delà, il faut un minimum d'entraînement. Je sais que je n'ai aucun problème avec un amphi de 90 minutes avec 120 étudiants.
Sinon, pour ce qui est de répéter quand on n'a pas l'habitude, oui c'est important. Mais je me souviens que j'avais tendance à m'installer dans un bureau avec mes potes. C'était une très mauvaise idée. Quitte à répéter, il faut se mettre le plus possible en condition réelle, donc dans un amphi ou dans une salle avec les amis loin.
Et si vous en avez l'occasion, prenez des cours de chant avec un vrai professeur. De façon générale, si on n'y réfléchit pas trop, on place naturellement pas trop mal sa voix. Les conseils que j'ai donné tendent à placer l'orateur dans une situation ou naturellement, il ne fait pas n'importe quoi. Mais si on a vraiment appris à place sa voix, ça reste incomparable.
[^] # Re: Sur les exposés
Posté par gelnior (site web personnel) . Évalué à 1.
Oui, je n'ai pas trop développé dessus mais quand je dis parler fort, c'est parlé très fort. Chose qu'on ne peut faire qu'en utilisant son thorax. Les cours de chant peuvent effectivement aider car les chanteurs ont le même problème (en tout cas les vrais chanteurs), pour être musical ils doivent moduler leur voix et ne peuvent le faire qu'en chantant très fort.
[^] # Re: Sur les exposés
Posté par Claude SIMON (site web personnel) . Évalué à 6.
Ah non, on peut également, et c'est préférable, utiliser l'abdomen. C'est plus efficace et cela a un effet relaxant, contrairement à la respiration thoracique…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Sur les exposés
Posté par Tonton Th (Mastodon) . Évalué à 10.
C'est vrai que c'est moins fatiguant de faire ça à plusieurs.
[^] # Re: Sur les exposés
Posté par gelnior (site web personnel) . Évalué à 2.
Très bon conseil, je note !
Pour l'eau j'avais oublié d'en parlé mais oui c'est très important. J'avais oublié ma bouteille à ma dernière présentation et ça m'a manqué.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.