Un marché libre pour les logiciels libres ?

L'idée de créer une place de marché mettant en relation des projets proposés par des entreprises et/ou des particuliers et des développeurs n'est pas neuve. Diverses expériences de ce type, permettant la rémunération des développeurs traditionnellement bénévoles, ont été tentées. Elles ont pour la plupart échoué. Nous analyserons dans ce papier les cas de CoSource, SourceXchange et GPL Farm. Ce document analyse les causes de ces échecs et propose une solution alternative jugée plus en phase avec les réalités du logiciel libre.

Les places de marché venant en support de développement libres ont pour la plupart vu le jour dans les années 1998/1999. Citons :

• Oasis,
• Asynchrony¹,
• SourceForge,
• Free Software Bazaar²,
• CoSource,
• SourceXchange,
• Open Avenue³.

Plus tard (2000/2001), sont apparues :

• GPL Farm,
• Software Carpentry⁴.

Certaines, comme SourceForge, fournissent une infrastructure pour des projets libres. D'autres introduisent un mode de financement des développeurs actifs sur la plate-forme. C'est le cas de Cosource et de Sourcexchange ou de GPL Farm⁵.

Méthodologie d'analyse

Nous analyserons ces trois places de marché en fonction de trois critères :

• l'origine de la place de marché,
• les projets hébergés (type de projet, choix de la licence logicielle, attribution des projets, évaluation du logiciel délivré),
• le financement (source de financement, fixation des tarifs, moyen de paiement).

Les recherches de financements

Parallèlement à ces places de marché, plusieurs communautés recherchent des financements. Ces derniers peuvent être de faible importance, grâce à l'utilisation du système PayPal. C'est notamment le cas de FreeBSD et NetBSD.

Bernhard Herzog propose pour sa part un système original : racheter via donation (multiple de $10) du temps à son employeur pour pouvoir travailler sur son logiciel libre de dessin vectoriel Sketch (renommé depuis en Skencil) !

Causes des échecs

Différentes causes ont été avancées pour expliquer ces échecs. Parmi celles-ci, citons :

• la faiblesse des sommes drainées,
• la complexité des projets.

Cette explication est valable pour SourceXchange. En effet, cette initiative provient d'une volonté de Hewlett-Packard d'externaliser certaines développements de grande envergure. Mais elle ne s'applique pas à CoSource, qui visait essentiellement de petits projets.

D'autres éléments sont venus s'ajouter :

• la possibilité de créer des programmes non libres (donc perdus pour la communauté),
• la lourdeur du processus d'attribution des projets, rassurant pour les entreprises mais décourageant pour les programmeurs.

La processus de fixation des prix, bloquant chez CoSource, a également pu gripper le mécanisme.

Une proposition alternative

Sur cette base, nous pouvons faire la proposition suivante.

Avant tout autre considération, les motivations du programmeur à contribuer à des projets libres sont :

• la possibilité d'exprimer sa créativité sur des problèmes concrets,
• l'amélioration de son expertise technique,
• une façon agréable d'occuper ses loisirs.

Le plaisir reste donc une composante fondamentale dans l'activité du contributeur !

La culture du don prévaut. Le recherche d'argent n'est pas une préoccupation première. Cet élément ne surprend pas, puisque le développeur de logiciels libres possède généralement une activité rémunérée.

Par ailleurs, le statut de freelance risque de créer une concurrence farouche entre développeurs et d'aboutir à une précarisation du métier d'informaticien.

Le libre fonctionne selon une méritocratie stricte, mais privilégie néanmoins la solidarité, en partageant le travail de tous. La concurrence est plus sportive qu'économique.

Une place de marché ne peut pas fonctionner si elle ne respecte pas la culture du libre et les éléments cités plus haut.

Sources de revenus pour la communauté

Rémunérer les développeurs traditionnellement bénévoles appelle l'existence de sources de financement. L'idée est ici de proposer aux entreprises et aux particuliers, moyennant finance :

• un support technique préférentiel (c'est-à-dire sans délai garanti, mais stimulé par un incitant financier ou en nature),
• l'ajout de fonctionnalités particulière à des projets existants, voire l'ouverture de projets nouveaux.

Sources de revenus pour les membres

Les contributions apportées donneraient droit à des points⁸. Ces derniers seraient notamment échangeables contre des cents. Le barème pratiqué -conversion des points en cents- résulterait d'un calcul simple :

     1 point = financement total / nombre total de points

Par exemple, si le nombre total de points accumulé par la communauté est de 100.000 points et le financement total de 1.000 euros, un point vaudra 1 cents.

Le gain de point dépendra :

• de la nature de la contribution, selon une échelle du type support technique < fixation d'un bogue < ajout d'une fonctionnalité ;
• de la présence d'un financement pour l'objet de la contribution, les projets financés donnant droit à un supplément de points ;
• de l'évaluation par les pairs (et par les " clients " en ce qui concerne les projets financés).

Ce dernier aspect est important, car il permet de garantir un code de qualité. Par ailleurs, le système reste basé sur une méritocratie stricte. L'argent est uniquement introduit comme outil d'orientation des contributeurs⁹.

Les points devraient être dépréciés dans le temps, de manière à favoriser les membres actifs.

L'utilisation d'un système de points présente plusieurs avantages.

• Le point permet de dématérialiser les échanges et peut être converti en n'importe quoi : argent (cents) mais aussi formation, matériel informatique, livre,… Ce système est comparable aux points collectionnés par les carte de fidélité des grands magasins et donnant droit à des bons de réduction (argent) ou à des cadeaux (nature). Ce système peut donc également être vu comme un outil basique de fidélisation du contributeur, voire d'acquisition.
• Les points sont accumulés par tous les contributeurs, quel que soit l'objet de leur contribution. Les projets financés donnent droit à un bonus, mais globaement chacun est récompensé pour ses efforts. La solidarité est donc préservée.

Par ailleurs, ce système ne présente pas les contraintes des précédents (pas de proposition écrite à rendre, pas de contrat avec le développeur, etc.). Il permet de préserver le plaisir du programmeur.

Validation par l'entreprise

Le support technique préférentiel serait payé à la communauté sous forme d'une rente mensuelle.

Le financement des projets de développement pourrait fonctionner sur cette base (ce qui correspond à du mécénat) ou sur base de la fixation d'un taux d'avancement (ce qui correspond à une rémunération pour un service).

Dans ce dernier cas, afin de préserver l'intérêt des entreprises, une date de clôture pourrait être spécifiée au delà de laquelle le financement prendrait fin. Par ailleurs, l'entreprise libérerait le don proposé au fur et à mesure de l'avancement du projet, en fixant régulièrement un taux d'avancement. Un taux d'avancement de x% correspondrait à un versement de x% de la somme proposée pour le projet.

Aller plus loin : la commercialisation ?

Le site Asynchrony a pour sa part développé une idée intéressante : la prise en charge de la commercialisation du produit fini. Les projets finalisés peuvent en effet être diffusés sous forme de sharewares, avec un partage des gains entre les contributeurs. Asynchrony touche une commission plus ou moins élevée, suivant :

• qu'elle certifie ou non le projet,
• qu'elle fournit ou non une assistance marketing.

Ce modèle n'est pas reproductible tel quel pour le logiciel libre mais peut fonctionner dans certains cas particuliers. Citons le système de la double licence¹⁰ ou la vente des binaires¹¹.

Le mot de la fin

Le système proposé tient compte des spécificités du Libre pour stimuler le développement de projets répondant au mieux aux besoins des utilisateurs finaux, entreprises ou particuliers. Il constitue un complément intéressant à d'autres structures de développement de logiciels libres : communautés informelles, associations, entreprises privées, administrations, etc. ¨

----------
Notes de bas de page

(1) Asynchrony était plutôt orientée sharewares ; nous y reviendrons ultérieurement.

(2) Créé par Axel Boldt en 1998, le Free Software Bazaar visait des projets de $50à $1000. Une douzaine de projets ont abouti.

(3) Open Avenue ciblait les développement sous Visual Basic et Delphi (pour diminuer les barrières à l'entrée). Il fut fermé en 2001, par manque de financement.

(4) Créé en 2000/2001, Software Carpentry fonctionnait sous forme d'un concours, dont le challenge était de réimplémenter en Python quatre outils Open Source. Un des objectifs était de découvrir des manières de travailler avec la communauté Open Source.

(5) Fin 2003, une autre initiative est apparue. OpenSourceExperts.Com avait pour objectif de collecter des fonds pour financer des projets Open Source. Les fonds peuvent être apporté par plusieurs entités (mutualisation). Le projet peut démarrer dès lors que la somme est récolté et qu'un développeurs accepte le budget. Postérieure à cette étude, cette initiative n'a pas été incluse dans ce papier.

(6) La tierce partie joue un rôle important. Sur base d'un cahier des charges écrit par le demandeur, elle évalue l'atteinte des objectifs par les développeurs et, si cette évaluation -indépendante du demandeur- est positive, décide de libérer la somme budgétée.

(7) Source : Boston Consulting Group.

(8) Ce principe est notamment inspiré du modèle de fonctionnement de communauté de consommateurs telles que Ciao.Fr ou Epinions.Com, qui rémunèrent leurs membres pour la création de contenus.

(9) Début 2004, IBM a déposé un brevet aux Etats-Unis sur les "paiements prédéterminés d'encouragements", dont le principe est proche des idées exprimées dans ce papier. " Concrètement, lorsqu'il y a plusieurs développeurs travaillant sur le même module: au lieu de payer uniquement celui dont le module a été retenu, les responsables du développement vont également verser une somme, moins conséquente, aux développeurs ayant proposé des modules acceptables mais non choisis. Un système censé ainsi motiver fortement tous les développeurs. Un procédé, cela dit, basé plus sur la compétition que sur le travail en équipe. " (Source : ZDNet)

(10) Qt chez Trolltech, MySQL chez MySQL A.B., Berkeley DB chez SleepyCat, etc.

(11) Les binaires du logiciel libre QCad (dessin technique en 2D) sont ainsi disponibles en payant (à partir de $25 environ). Les sources sont fournies dans la version Community, gratuite, mais sans les fichiers binaires (la compilation demande des compétences techniques).

Sources

Etudes

• The Boston Consulting Group/OSDN Hacker Survey : http://www.osdn.com/bcg/

Articles "papier"

• Amabile T., How to kill creativity ?, Harvard Business Review, Septembre-Octobre 1998.

Articles de forums

• IBM brevète une méthode de rémunération des développeurs d'Open Source, Da Linux French page, 28/01/2004.
• Portail de regroupement de professionnels du logiciel libre, Da Linux French Page, 21/11/2003.
• GPL farm : rémunération des auteurs de logiciels GPL, Da Linux French Page, 24/08/2001.
• Libre et rémunération ?, Da Linux French Page, 23/02/2003.

News anonymes

• Developements Projects, LWN.Net, 30/08/2001.
• A New Year's Idea : Pay for some freedom, Slashdot.org, 27/12/2001.

Articles électroniques

• Guillemin C., États-Unis: IBM obtient un brevet pour rémunérer les programmes open source, ZDNet France, 29 janvier 2004.
• Laird C., Open source matchmaking, Linux World, 10/2000.
• Raymond E., Le chaudron magique, 06/1999.
• Searls D., It's an industry, Linux Journal, 21/05/1999.
• Shankland S., Open-source programming sites go live, CNET.com, 10/12/1999.
• Markets for Open Source Software : http://www.ms.lt/en/workingopenly/markets.html

Sites

• Da Linux French Page, http://www.linuxfr.org.
• Sketch, http://sketch.sourceforge.net.

Posté le16 juin 2004.