Introduction

Quelque soit le logiciel, la communauté associée évolue avec le temps et des évènements propres à ce logiciel. Cependant, certains des exemples que donne Angela Byron dans cette conférence s'appliquent (ou pourront s'appliquer) à d'autres, il m'a donc paru intéressant de se concentrer sur ceux-là.

Barrière mentale pour l'accueil de nouveaux contributeurs

En 2005, étudiante, Angela Byron a participé à un Google Summer Of Code sur Drupal. Auparavant, elle se sentait "trop bête pour contribuer". Le simple fait de participer à ce GSOC lui a permis de proposer des patchs, de travailler sur des fonctionnalités, et de se prouver à elle-même qu'elle pouvait tout à fait contribuer à cette communauté.

En fait, tout le monde à quelque chose à contribuer au logiciel, peu importe le niveau technique. Renforcer ce discours et faciliter l'arrivée de nouveaux contributeurs est donc une des tâches à mener pour permettre à un projet Open Source de perdurer.

Le pouvoir de la communauté

Peu après (au moment de ses partiels), le serveur hébergeant http://drupal.org (à l'époque, un serveur mutualisé) est tombé en panne. Sur la page de maintenance, Dries Buytaert, le créateur du projet, a simplement mis un bouton de paiement et demandé des dons pour pouvoir prendre un serveur dédié. Il demandait 300$, en a récolté plus de 10 000 $.

Quelque soit les actions que vous souhaitez entreprendre pour votre projet, ne négligez pas la force de la communauté !

Une phase de douleur… puis une phase de bonheur

En 2006, la sortie de la version 4.7 de Drupal a vu l'arrivée de la Form API dans Drupal. Ce gros patch / cette grosse réécriture a engendré beaucoup de frustrations, de douleur pour les développeurs (incompatibilité de beaucoup de modules développés pour les versions précédentes, retards dans la finalisation de la nouvelle version). Finalement, c'est cet ajout qui a amené un flux nouveau de nombreux contributeurs, ainsi qu'une plus grande satisfaction des développeurs de l'époque sur l'utilisation de Drupal.

On se dirige (probablement) vers le même type de phases (douleur / bonheur) avec le développement de Drupal 8, à cause de l'énorme refactoring actuel. C'est souvent une phase nécessaire pour permettre au logiciel d'évoluer d'un coup. Mais il faut prendre cela en compte, et gérer cette phase "douloureuse" au niveau de la communication du projet.

L'isolement… et sa sortie

En 2006, à cause d'une faille de sécurité, Drupal a souhaité s'éloigner de l'API XML-RPC universelle (ré)utilisée jusque là, et développer sa propre API pour ne plus dépendre d'autres composants et gérer sa propre sécurité. Cet événement  déclencheur a pris fin avec Drupal 8 (8 ans plus tard…) et la ré-utilisation (à nouveau) de composants (Symfony, Twig) et de normes PHP (PSR-4, Programmation Orientée Objet, Services…).

L'utilisabilité du logiciel

Drupal 6 est sorti en 2008, et durant le cycle de développement de Drupal 7 (2008-2011), des tests d'utilisabilité ont été menés, et ont indiqué quelques problèmes avec Drupal :

• le vocabulaire : "Content" contre "Content Type"
• l'interface : où suis-je (front end / back end) ? Que voient les visiteurs du site ?

Toutes ces études ont provoquées la création de l'initiative "d7ux", pour régler certains de ces problèmes (les autres seront réglés en Drupal 8). Ces changements ont encore amélioré l'adoption de Drupal, notamment en permettant plus simplement à des contributeurs non-expérimentés de saisir du contenu (une tâche critique pour un CMS ;-)).

La Drupal Association

Initialement, les tâches de l'association étaient essentiellement de recueillir de l'argent pour financer les évènements, et de fournir une assistance légale au logiciel. Elle ne devait pas agir sur le logiciel lui-même.

Aujourd'hui, elle prend un peu plus le pas sur le serveur drupal.org, par exemple, parce que les contributeurs font des choses qui leur plaisent, mais pas forcément les choses les plus stratégiques pour le projet lui-même. C'est alors le rôle de l'association de financer certaines tâches "moins plaisantes" (régler les problèmes de performance du serveur, le redesign graphique du site…).

Une "do-ocracy"… qui doit évoluer pour survivre

Drupal est une "do-ocracy", ce qui signifie que tout ce qui est fait est fait parce que quelqu'un a eu envie de le faire. Cette valeur de la communauté a permis à la communauté de se développer pour atteindre la taille qui est la sienne aujourd'hui, mais pose également quelques problèmes :

• le manque de décisions claires entraîne parfois des frustrations ;
• ceux qui ont beaucoup de temps libre / qui "crient" le plus fort ont tendance à "dominer" les échanges ;
• un certain nombre de "burnouts" ont eu lieu dans la communauté (les contributeurs principaux se sentent coincés dans leur rôle).

Drupal va donc évoluer vers une "do-ocracy" avec une gouvernance formelle (composée de groupes de travail sur des sujets précis). De nouveaux rôles vont également être créés (responsable produit, responsable framework), …

Tout cela permet d'apporter plus de transparence, de support pour les rôles clés, ainsi que des préoccupations de stratégie et tactiques séparées.