À partir de quand un projet open source doit-il faire passer les aspirations de ses utilisateurs – ou de ses clients – avant celles de ses contributeurs ? C’est le sujet d’une des conversations que j’ai eu la chance d’avoir avec Chris Heuer, co fondateur du Social Media Club, à l’occasion de son passage en France pour la Drupal Con.
Nous avons comparé Wordpress, dont j’ai bien connu la communauté, et Drupal. Les deux outils sont fondamentalement différents. Là où Wordpress est un produit fini, destiné à être utilisé out of the box, et donc très orienté utilisateur final, Drupal se rapproche plus d’un framework sur lequel il sera possible de construire à peu près n’importe quoi.

La courbe d’adoption d’un projet open source passe généralement par un certain nombre d’étapes identifiées que suit également sa communauté.

Le projet est d’abord conduit par des développeurs, et se destine essentiellement à d’autres développeurs. Cela vient à la fois du manque de support et de documentation, du manque de maturité du projet, et des canaux utilisés par les développeurs pour communiquer : IRC, listes de diffusion habituellement technique, wiki, et bug tracker.

Un premier pas est franchi le jour où le projet se dote d’un forum destiné aux utilisateurs finaux, et animé par des contributeurs non techniques. En parallèle, la communauté d’utilisateurs s’élargit à mesure que le produit devient plus simple, mieux présenté, et qu’il offre suffisamment de ressources pour une personnalisation sans efforts : thèmes, plugins…

Une fois une certaine masse critique atteinte, et avec elle l’assurance que le produit restera maintenu un certain temps, des sociétés vont commencer à proposer le produit dans leurs prestations, voire à y apporter leurs contributions, cherchant ainsi à l’orienter dans la direction qui les arrange.

On peut donc dire, même s’il est difficile à situer, qu’il existe un point de rupture au delà duquel les retours cessent d’être des avis de contributeurs, techniquement intelligents, pour devenir les retours des utilisateurs finaux eux-mêmes. Cela implique qu’on leur donne des canaux de communication – forums, sites, ou services à la Feedback 2.0 ou Get Satisfaction – mais également des gens qui parlent le même langage qu’eux pour les écouter et leur répondre. C’est particulièrement vrai pour un outil comme Wordpress, avant tout destiné au grand public. La très grande force de la communauté Wordpress, vient du fait que ses utilisateurs finaux sont également ses meilleurs évangélistes. Et cela devrait d’ailleurs être le cas de n’importe quel produit.

En étant avant tout orienté développeurs, Drupal a plus de mal à se constituer une communauté d’utilisateurs finaux. Parce que Drupal est un framework, et non un produit fini, ses développeurs sont en contact avec des intégrateurs, eux-même en contact avec des clients qui rassemblent les retours des utilisateurs finaux, non pas sur le produit, mais sur les adaptations qui en ont été faites. Et les utilisateurs finaux du produit sont généralement des gens avec un minimum de culture technique, au moins pour publier. Et ils ont payé pour le faire.

On se retrouve donc avec deux cas très différents, qui appellent des réponses différentes.

Dans le cas de Wordpress, on a un retour d’utilisateurs finaux qui expriment des demandes pour leur usage personnel. Se mettre à leur écoute, et implémenter ces demandes avec discernement, permet d’améliorer le produit pour tous. Il est donc intéressant de le faire dès que la communauté sort du cercle des initiés pour entrer dans le grand public. Je ne dis pas qu’il ne faut pas écouter la communauté plus technique, mais leur point de vue sur le produit ne sera jamais le même que celui de madame Michu.

Dans le cas de Drupal, les retours émanent de personnes qui utilisent le produit pour leur business, et ont donc tout intérêt à lui voir prendre telle ou telle orientation. C’est évidemment dangereux. Et le projet court deux risques identifiés.

Les demandes des intégrateurs risquent – à moins de demandes génériques – de ne profiter qu’à eux-même, et encore dans le cadre d’un projet précis, et donc non réutilisable partout.
Corollaire, le framework risque de se transformer en produit, et ainsi de perdre cette nature qui le rendait intéressant pour de l’extension / intégration (sans compter que de nombreux intégrateurs devront mettre la clé sous la porte).

Comme vous le voyez, il n’y a pas vraiment de réponse à la question posée en introduction. Il est important de prendre en compte les retours de ses utilisateurs finaux dès lors qu’ils sortent du sérail technophile, mais sans pour autant dénaturer son produit ou l’orienter au gré d’un client particulier.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: