Micropledge et Cofundos

08/01/2009

Toujours sur la question du financement mutualisé, je ne suis évidemment pas le seul à avoir de telles réflexions. Il y en a même qui se sont jetés à l'eau et ont proposé des services dans ce domaine.
C'est le cas des sites web micropledge et cofundos. Les deux sites, relativement jeunes (mise en ligne mi-2007 pour le premier et octobre 2007 pour le second) se veulent constituer des "places de marché" pour le financement du logiciel (libre).
Micropledge vient de fermer son service et tente de le faire évoluer vers une autre offre. C'est l'occasion d'en faire une petite analyse.

Le site s'affiche comme service permettant aux logiciels d'être développés et aux développeurs d'être payés. Il n'est pas précisé que les logiciels développés doivent être libres, bien que le principe est que le service soit gratuit pour tout projet de logiciel "open source". Pour le développement de logiciels non-libres, la société derrière le site prélèvera une commission sur la transaction. La distinction entre gratuit et payant se fait donc sur la déclaration que le projet développé sera "open source" ou non, terme qui, au passage, reste complètement flou.

Après enregistrement auprès du site, il est possible soit de proposer de nouveaux projets (le site parle plutôt de nouvelles "idées") en attente de financement, soit de faire des "promesses de financement" (pledge) sur un projet existant.
Un projet est généralement présenté en quelques lignes et un "forum" (une série de commentaires) permet aux visiteurs de demander précisions si besoin. Plusieurs développeurs peuvent faire des propositions concurrentes (sur la délai de réalisation et le coût) sur le même projet. Après discussions et passé un certain délai, un développeur est désigné.

En parallèle, les promesses de financement sont accumulées. Quand la somme des promesses atteint l'objectif fixé par le développeur, le développement peut commencer.

La chose intéressante est que micropledge est le seul site, à ma connaissance, à proposer de garder en lieu sûr l'argent des promesses (to escrow en anglais, mal traduit par "mettre sous séquestre") : plutôt que de simplement "faire une promesse", les financeurs dépensent réellement l'argent. Il est placé chez un tiers de confiance. Si l'objectif fixé par le développeur n'était pas atteint, le tiers rembourserait chacun des financeurs. L'avantage de ce fonctionnement est évident pour le développeur : les sommes mises sous séquestre sont "garanties" et il ne s'agit pas juste de paroles en l'air. L'engagement des financeurs repose alors sur la confiance qu'ils peuvent avoir dans le tiers en question et s'agissant d'une petite entreprise néo-zélandaise, inconnue par ailleurs, la confiance peut être difficile à donner. À ce propos, si le système était à reproduire, peut être existe t-il des systèmes bancaires permettant à la banque de garantir qu'une somme sera bien versée si toutes les conditions sont réunies (un peu comme la "caution" des vélos de JC Decaux où une opération par carte bancaire permet de vérifier que le compte possède bien 150€ et qu'ils seront débités seulement en cas de souci).

La principale critique de ce site est qu'il est trop proche des sites de levée communautaire de fonds (fundable, promesotheque). En fouillant dans les archives du site, on trouve rapidement des appels à dons pour des associations caritatives réelles ou fictives.

On trouve également trop souvent des idées mal rédigés ou rédigés par des personnes qui n'ont visiblement aucune connaissance technique. En général :

un projet similaire semble exister depuis bien longtemps et l'utilisateur n'en n'a pas connaissance ou n'a pas été capable de l'installer (dans ce cas, l'orientation vers une base de connaissances ou une associations d'utilisateurs serait le plus judicieux),
la description du projet est trop vague,
le projet est bien trop ambitieux, le site tendant à faire appel à des développeurs isolés, mettre en place de gros projets parait difficile.

Par ailleurs, sur les plus de 300 projets recensés, seule une petite quinzaine a été marquée comme projet "complété" (soit à peine 5%).

Le service s'est finalement arrêté à la fin de l'année 2008. Les concepteurs ont annoncé que leur intermédiaire (PayPal) refusait de servir de "tiers de confiance". Ils ont alors appelé aux dons pour le financement d'un développeur qui serait chargé de convertir le système actuel vers un autre système de paiement (qui reste toujours inconnu). Les dons n'ont pas été suffisants.

En première analyse, on retiendra que, pour qu'un tel système soit fonctionnel, deux choses paraissent essentielles :

la manière dont le besoin est exprimé. C'est en fait une étape capitale dans le processus de développement logiciel. Et c'est un problème valable quelque soit le modèle de financement retenu. Pour que les besoins deviennent plus clairs, les possibilités sont :
- un processus de sélection, d'accompagnement ou d'affinage des requêtes d'utilisateurs afin qu'elles deviennent un peu plus formelles soit en faisant appel à des intermédiaires (des techniciens capables de comprendre les désirs des utilisateurs) soit par un quelconque processus itératif. En particulier, si la requête est trop importante, proposer à l'utilisateur de la revoir à la baisse ou de la redécouper en plusieurs sous-requêtes ;
- de ne proposer dans un premier temps le système qu'à un "noyau" de techniciens dont les membres se financent entres eux et qui font venir petit à petit un public moins technicien tout en développant en parallèle une procédure capable de répondre à leurs requêtes particulières.
le deuxième point important est le système de "mise en confiance" des transactions. Il est nécessaire de s'assurer que les développeurs soient suffisamment rassurés pour se lancer dans le développement tout en n'alourdissant pas trop la demande d'engagement des financeurs. Ici aussi, un découpage en petits projets, petites livraisons permet au système dans son ensemble de gagner en confiance (release early, release often qu'ils disaient)

Suite au prochain numéro