Bonsoir,

Depuis quelques jours, la communauté anglophone bouillonne d'une controverse sur le modèle économique le plus approprié pour pérenniser l'existence des modules contributifs. Si j'ai bien compris, elle est née de l'annonce d'une intervention de Robert Douglass aux DrupalDevDays de Bruxelles (dans 10 jours), intitulée "Sell your code: Announcing the DroopyAppStore". Quelques unes des pointures de la communauté se sont déjà exprimées sur le sujet, notamment Earl Miles (Monsieur Views, aka MerlinofChaos) ou Morten Birch Heide-jørgensen (qui se fait reconnaître en ligne sous le pseudonyme mortendk, puisqu'il est danois, et dans la vraie vie sous une indéboulonnable casquette beige). Parmi les commentateurs de leurs billets, d'autres noms connus apparaissent, comme celui de Gabor Hojtsy, qui est avec Dries le co-maintainer de Drupal 6. Un hashtag twitter a même été lancé (#drupalappstore). Dries lui-même n'est pas (encore) intervenu directement dans le débat, mais dès qu'il aura été relâché par les kangourous, il dira peut-être un mot ou deux.

le problème

Drupal est un logiciel open-source mis à la disposition de tous sous la licence GPL. Les modules et thèmes offerts par leurs développeurs à la communauté sur le site drupal.org doivent impérativement être placés sous cette même licence. Celle-ci n'interdit pas exactement de vendre le produit qu'elle protège, mais dans les faits, les thèmes et les modules présents sur drupal.org sont gratuits.

De nombreuses sociétés ont développé des thèmes premium, vendus sur leurs propres sites. Pour les modules, beaucoup de développeurs proposent, sur la page "project" du module, des services de personnalisation ou d'aide particulière contre espèces sonnantes et trébuchantes ; on trouve aussi parfois un bouton de don Paypal.

Mais l'utilisation simple d'un module déposé sur drupal.org n'entraîne aucune obligation de rémunérer son créateur. Or il est bien évident qu'un développeur ne vit pas tout-à-fait de code et d'eau fraîche. Parfois, il mange une pizza ou boit de la bière. (oui, un développeur a des goûts bizarres). La situation peut être différente selon que l'individu en question est salarié par une société / institution qui croit en Drupal et finance les heures de travail qu'il y passe, ou bien free-lance responsable de ses propres revenus. Quoi qu'il en soit, le développement d'un module représente un travail parfois considérable, sans parler de sa maintenance.

Se pose donc la question de la rentabilité de ce travail, et du modèle économique capable de pérenniser le fonctionnement de la communauté, sans le gripper. Comme dirait l'autre, l'open-source est gratuit... quand il a été payé.

Le système "logiciel gratuit, service payant autour du logiciel" (la vache est gratuite, nous vendons le lait) recueille généralement un relatif consensus dans l'open-source. Mais payer pour du service nécessite qu'en face, le service puisse être assuré. En conséquence, ce modèle est surtout réalisable par des entités commerciales, des entreprises d'une certaine taille (et capables d'embaucher), pour des services professionnels proposés autour d'une offre conséquente. En clair, il s'applique plus facilement à des distributions qu'à des "petits" modules. La question d'une rémunération des créateurs reste donc entière pour ces derniers.

les pros & cons

Ce qui rend le débat si animé, c'est tout d'abord le fait que chacun des deux camps cherche à oeuvrer pour le bien de Drupal, et qu'il est toujours difficile d'accorder des bonnes volontés. C'est aussi le fait que chacun a des arguments très valables à soumettre. 

Ainsi, quand cet article met en valeur le gain de qualité qu'une rémunération (par les utilisateurs du module) permettrait de réaliser, Morten montre de son côté qu'un système de modules payants conduirait à concentrer les compétences sur le plus lucratif, au détriment de la qualité générale du reste. D'ailleurs, l'exemple de la communauté Joomla (où beaucoup d'extensions sont payantes) démontre que l'équation payé = qualité n'a rien d'automatique. 

Pour une société/organisation qui finance, dans le cadre d'un projet, le développement d'un module, il n'est pas toujours facile de comprendre son intérêt à continuer d'en financer la maintenance pour d'autres qui l'utilisent gratuitement. En réalité, elle y a un intérêt : une masse importante d'utilisateurs, c'est un meilleur feedback et une mutualisation des risques liés aux éventuels bugs du module.

Par ailleurs, la gratuité a beaucoup d'avantage pour les utilisateurs, mais elle a une contrepartie fort inopportune : c'est l'incapacité à avoir une visibilité sur le développement et le cycle de vie d'un module. Impossible de savoir précisément dans quel sens un module va évoluer, quand il sera prêt (cette dictature du toujours disponible, jamais abouti !). Le problème, comme le relève Earl Miles avec raison, c'est qu'il est extrêmement difficile de fédérer des développeurs d'horizons divers et aux intérêts variés sur des objectifs complémentaires ; alors qu'une petite équipe bien constituée et disposant d'une source de revenu peut travailler beaucoup plus efficacement. C'est d'ailleurs, je crois, ce à quoi s'attellent les Commerce Guys qui se concentrent sur une problématique particulière (l'e-commerce avec Drupal) ; du reste, le développement de Drupal 7 n'a finalement abouti qu'avec l'affectation "officielle" de quelques ingénieurs et développeurs, dans plusieurs sociétés locomotives (notamment Acquia). Sans cet apport rémunéré, on y serait sans doute encore.

Mais quels sont les modules susceptibles de générer un vrai revenu ? En réalité, seulement les modules les plus utilisés, mais qui sont aussi (souvent) ceux qui demandent le plus de travail de configuration. L'utilisateur sera-t-il prêt à payer pour découvrir derrière que le module ne fait pas exactement ce qu'il veut, et qu'il faut encore y travailler / voire, qu'il faut en payer un autre ? De plus, si un module devient payant, les développeurs qui l'utilisent et auraient la compétence de participer à sa maintenance (et à son amélioration) accepteront-ils de collaborer gratis pro deo ? Un système de redistribution des fonds entre participants parait peu envisageable à l'échelle internationale et micro-paiement-esque (oui le mot est moche mais je commence à fatiguer). Au final, il n'est pas certain du tout qu'un paiement garantisse quoi que ce soit à  long terme, et pas forcément la qualité du module.

Quelles solutions ?

En dehors des modules sponsorisés par une société, certains développeurs demandent aux volontaires une donation par PayPal. Je ne sais pas si cela a un réel impact. Un commentateur (dans l'un des articles pré-cités) suggère le recours au crowdsourcing, qu'on pourrait assimiler à la souscription. Ainsi qu'il le dit, un développeur réputé pour la qualité de son travail trouverait facilement la confiance, sonnante et trébuchante, de ses fans.

C'est un peu le système de Flattr ("social micro-payment") dont parle Morten à la fin de son message, et qui parait une bonne solution pour encourager et remercier les "petits" développeurs.

En tout état de cause, aucune solution n'est totalement satisfaisante - pas même le statu quo qui n'est pas très gratifiant pour les plus engagés.

Et la doc ?

Notez qu'au-delà du développement de modules, le problème se pose aussi pour les créateurs de documentation et autres aideurs qui essaient de résoudre les problèmes rencontrés par les utilisateurs ; et là, bien sûr, je sais de quoi je parle. Différents modèles co-existent au sein même de la communauté francophone (pour ne parler que d'elle) : Yoran Brault et Cyprien Roudet ont édité un livre (même si j'imagine qu'ils ne vivent pas encore de leur plume, c'est tout de même une rémunération) ; il y a de la publicité sur biboo.net de Robin Toularastel ; Vincent Caillerez (DrupalFrance.com) organise des formations professionnelles. Tous (qui sont free-lance) participent occasionnellement aux forums de drupalfr, de même que Stéphane Vial (Lektum) et que les deux Juliens (Dubreuil et Dubois) qui tiennent par ailleurs un blog gratuit (je veux dire sans publicité), comme moi - les deux derniers sont dans la même situation que moi, salariés "pour faire du Drupal". 

Il y a plusieurs raisons qui peuvent pousser des utilisateurs à s'engager "gratuitement" dans un travail d'aide, de documentation. Il y a la volonté de se faire "un nom", une réputation ; je n'ai pas de honte à l'avouer, c'est l'une de mes motivations, même si pour le moment je ne me suis pas encore directement "servi" de ma réputation. Les forums communautaires servent à tous de vitrine, clairement. C'est aussi un bon moyen d'obtenir plus facilement de l'aide quand on en a soi-même besoin. Il y a aussi le fait que s'intéresser à un problème rencontré par quelqu'un d'autre est souvent enrichissant en termes de connaissance de l'écosystème. Je répond plus volontiers (sous réserve de disponibilité) à des questions de modélisation du contenu qu'à des problèmes de paramètres ou de code.

Je ne peux cependant pas cacher qu'il est souvent démotivant de compter les heures passées (près de quatre heures et demie rien que pour ce billet !) et de ne pas voir un réel retour sur investissement, voire, quand on participe beaucoup sur les forums, de devoir encore passer du temps à refuser les demandes abusives (pourquoi croyez-vous que les participants les plus actifs ont quasiment tous fermé leur formulaire de contact personnel sur drupalfr ? je crois qu'on aurait tous quelques anecdotes pendables à raconter, depuis les "pourriez-vous regarder le problème que j'ai posté sur les forums ?" aux "pourriez-vous me dire comment construire mon site [en substance] ?".... sans parler des commentaires du blog que je ne publie pas !).

L'un dans l'autre, j'essaie de me dire que l'écosystème est général, et que moi aussi je profite du bénévolat d'autres personnes, à commencer par les développeurs dont je parle depuis le début (et en passant, coup de chapeau à tous ceux qui traduisent, parce que eux, leur travail est totalement "souterrain"), et ceci même au-delà du monde Drupal. Alors le jour où je penserai que mon travail n'est pas suffisamment compensé par les bénéfices que j'en retire, je fermerai boutique.

Au moins, on aura bien rigolé.