L'Open Source est omniprésent, mais tous les projets libres n'ont pas la communauté qu'ils méritent. Comment se forment ces communautés ? Comment l'entretenir, la faire vivre ? Cette conférence abordera les différents aspects d'une telle communauté, et les moyens possibles pour la faire croître.
1. Faire grandir une communauté
Open Source
Xavier Borderie
Open Source Advocate @ PrestaShop
2. Qui suis-je
D’où viens-je,
où vais-je en venir.
Xavier Borderie
● PrestaShop
Documentation Manager depuis 2011.
+ Open Source Advocate depuis 2015.
● WordPress
Traducteur FR depuis 2004.
Co-fondateur de WPFR en 2005,
président jusqu’en 2015.
Organisateurs des 8 premiers
WordCamp Paris (barcamp, conférence).
● Paris Web
Membre-organisateur pendant 6 ans.
Secrétaire du Bureau en 2014 et 2015.
4. La communauté
Celles et ceux
qui en font partie
Une tentative de définition
« La communauté d'un projet open-source
comprend toutes les personnes de confiance
qui travaillent activement, de concert et en
toute transparence à l'amélioration et à la
promotion de ce projet, dans tous ses
aspects, qu'ils soient ou non payés pour en
faire partie. »
5. La communauté
Celles et ceux
qui en font partie
Il s’agit donc de...
● Créateurs : développeurs, designers,
testeurs, etc. ;
● Utilisateurs ;
● Traducteurs ;
● Participants au forum d’entraide ;
● Organisateurs d’évènements locaux ;
● Revendeurs : éditeurs tiers, agences,
freelances, etc.
Tous contribuent à leurs niveaux respectifs.
7. La communauté
Son origine
Le premier pas : la distribution
● Application d’une licence Open
Source/Libre.
● Quatre libertés fondamentales :
○ Exécuter ;
○ Étudier (et adapter) ;
○ Redistribuer ;
○ Améliorer (et publier ses
améliorations).
● Licence de distribution.
● Loi de Linus : “given enough eyeballs, all
bugs are shallow”.
8. La communauté
Comment elle se forme
“If you build it, they will come.”
● Création spontanée.
● Nécessité de lieux d’échanges :
○ Hébergement du code ;
○ Bugtracker ;
○ Forum / mailing-list ;
○ Site avec blog, Twitter ;
○ Documentation / wiki ;
○ Traduction collaborative.
● Développeurs et “power users”.
9. La communauté
Pourquoi il en faut une
De l’intérêt d’avoir une communauté
● Source quasi-intarissable de volontaires.
○ Idées.
○ Correctifs.
○ Entraide.
○ Promotion.
○ Traduction.
● Cercle vertueux.
● Intérêt purement business.
11. Cinq piliers
Communication
Méritocratie
Collaboration
Technologie
Fun !
Faire vivre sa communauté
Un projet Open Source suppose un haut de
degré de franchise et de transparence.
● Communiquer ses intentions : roadmap,
tickets publics, réunions ouvertes avec
notes, etc.
● Outils d’échanges : bugtracker, forum,
etc.
Sinon, “fauxpen source” : licence ouverte
mais un processus de développement
relativement fermé.
13. Cinq piliers
Communication
Méritocratie
Collaboration
Technologie
Fun !
Faire vivre sa communauté
Passée la période de découverte, les
nouveautés ne suffisent parfois pas à
maintenir l'intérêt des contributeurs.
Sortir de sa tour d’ivoire :
● S’ouvrir à d’autres projets/partenaires ;
● Évènements/projets communs.
Chaque communauté s’ouvre, et profite des
bonnes idées des autres.
Les projets ont tout à gagner à se
sociabiliser.
14. Cinq piliers
Communication
Méritocratie
Collaboration
Technologie
Fun !
Faire vivre sa communauté
Un Open Source darwiniste : s’adapter ou
être dépassé.
Risques :
● Rester sur une technologie obsolète ;
● S’enfermer dans un framework à
l’abandon ;
● Choisir des outils/méthodes dépassés.
Danger :
● Perdre des contributeurs ;
● Ne pas en attirer de nouveaux.
● Dilution des intéressés.
15. Cinq piliers
Communication
Méritocratie
Collaboration
Technologie
Fun !
Faire vivre sa communauté
Une contribution !== Une contributrice.
Pour les faire revenir :
● Proactivité : être rapide sur les décisions,
les commentaires, la review du code, et
les remerciements !
● Créer de l’humain : désanonymiser la
contribution. Présence sur le forum /
le blog, webcast/vidéos, IRC, etc.
● Accompagner leur “montée en grade”.
● Montrer qu’ils/elles comptent. Que c’est
LEUR projet.
● Grandir avec sa communauté.
17. Prochaine étape
Visibilité et accessibilité
Une communauté à portée de tous
Même le projet FLOSS le plus simple à besoin de
documentation.
● Description et fichier README : explications sans
jargon/acronymes, images, tutoriel de contribution,
etc.
● Code de conduite : Ada Initiative, Contributor
Convenant, ou votre propre version.
● Moins d’obstacles : optimiser pour la 1ère
contribution. YourFirstPR, UpForGrabs.
● Pas de normes sévères.
● (ré)Activité communautaire à tous les niveaux du
projet.
● Évènements : apéros informels, meetups et
rencontres.
Vous n’avez pas à être parfait dès le début :)
18. Merci à toutes et tous !
xavier@prestashop.com
http://build.prestashop.com