Vous voulez lancer un projet open source ? Quelques conseils pour réussir

Vous allez être utile, vivre une aventure extraordinaire, vous faire des amis, contribuer au progrès d'un monde de plus en plus numérique, connaître l'excitation des startups, et peut-être même vous enrichir. Faisons le tour des questions qui vont se poser à vous.

Sur quoi portera votre programme et à qui s'adressera-t-il ? Ce n'est pas le sujet ici. Nous supposerons que vous avez une idée originale et lumineuse. Open source ou pas, ça pourra aider.

La première question à se poser est évidemment celle-ci : que cherche-t-on vraiment ? A devenir riche ? A concrétiser une idée géniale, qui pourra changer le monde ? A se faire plaisir dans le développement ? A se faire connaître, pour recevoir des offres d'emploi ? A monter une startup et vivre l'aventure entreprenariale ? Ce projet open source est-il une aventure dans laquelle on se lance corps et âme, ou bien un passe temps pour le week-end ? Est-ce une histoire individuelle ou un travail d'équipe ? Beaucoup de questions pour démarrer... Nous ne traiterons pas ici de toutes les étapes standard d'un lancement d'activité : analyse de marché, panorama de la concurrence, plan stratégique, business plan, etc. Nous resterons focalisés sur les particularité d'un projet open source.

Faut-il un nouveau projet ?

N'y a-t-il pas déjà un projet semblable auquel vous pourriez contribuer ? D'une manière générale, il y a déjà beaucoup de projets open source, et donc trop de projet qui manquent d'activité. Chacun veut avoir son propre projet, être seul maître à bord. Chacun espère recevoir des contributions, plutôt que de contribuer aux autres projets. Le foisonnement de nouveaux projets a des effets favorables : il amène une concurrence motivante, et une forme de darwinisme qui globalement améliore l'offre.
Mais il peut représenter aussi beaucoup d'énergie perdue sur des travaux parallèles, ce qui n'est pas tout à fait dans l'esprit de l'open source, celui de l'enrichissement collectif de biens communs. Donc, si votre objectif n'est pas de lancer une startup mais de construire le patrimoine logiciel de l'humanité, voyez d'abord s'il ne serait pas plus utile de contribuer à des projets existants. Vous pourrez, petit à petit, y faire reconnaître vos talents, et, selon le principe de méritocratie qui prévaut en général, avoir votre mot à dire dans la gouvernance du projet.

Créer le buzz en même temps qu'on crée le programme.

D'une manière générale, quand on se lance dans un logiciel et qu'on espère en faire un business, la tendance du technophile est de passer 6 mois à développer dans son garage en buvant des litres de café, puis enfin sortir de la maison pour aller chercher des clients. C'est précisément la démarche qu'il faut éviter. Pour plusieurs raison. L'une d'elles étant que votre développement doit impérativement être confronté à quelques cas concrets d'utilisation. L'idéal est de trouver un ou plusieurs premiers clients, qui acceptent d'être des utilisateurs pilotes, et dont le besoin permettra de guider la conception.

Mais ce n'est pas la seule raison. Dans l'open source, davantage que dans le logiciel propriétaire, la clé du succès est dans la qualité du produit : aucun marketing ne sauvera un produit médiocre, et un produit exceptionnel fera son propre marketing. Mais votre produit ne sera peut-être pas tout à fait exceptionnel, et aura besoin d'un peu d'aide tout de même pour se faire connaître.

Votre projet doit avoir son site avant même que la première ligne de code ne soit écrite, aussitôt que le concept est posé. Un site au moins en anglais bien sûr. Pendant toutes la phase de développement, le site annoncera les avancées, d'abord les principes, ensuite la roadmap, puis même les difficultés rencontrées, les choix techniques, etc. Une forme de teasing : toute la vie du développement, en quasi direct, façon loft-story. Et bien sûr, vous accompagnez cela de tweets quotidiens, de commentaires posés dans les blogs abordant votre thématique, vous prenez le temps de répondre à toutes les questions, de discuter avec chaque personne qui remonte un bug, etc. Pendant que vous développez, le site commencera à éveiller l'intérêt, à créer le buzz, et à tisser des liens qui amélioreront son référencement.

La communauté

Voulez-vous faire naître une communauté de développeurs participant à votre développement ? C'est la démarche la plus naturelle pour un logiciel open source. Clairement, créer un logiciel open source sans accepter et stimuler les contributions de tiers serait un non-sens. Il existe pourtant quelques éditeurs qui sont dans cette logique, mais nous supposerons ici que ce n'est pas votre cas.

Une communauté permettra de partager la charge du développement, donc de dynamiser le projet, d'apporter des regards neufs quant à la roadmap, de stimuler la promotion et la diffusion du produit, de lui donner aussi de meilleurs gages de pérennité, condition à l'adoption par des utilisateurs exigeants.
Bref, une communauté est une bonne chose. Et soulignons qu'une communauté n'est pas faite que de développeurs. L'utilisateur qui parle du produit sur son blog, celui qui remonte un bug, qui propose une nouvelle fonctionnalité, qui enrichit la traduction, qui corrige la doc sur un wiki, tous ceux-là participent de la communauté, et sont précieux.

Mais comment lance-t-on une communauté ?

On connaît quelques créateurs de logiciel qui décident un jour de mettre leur œuvre en open source, déposent les sources sur une forge, font un petit communiqué, puis attendent désespérément les contributeurs. Une communauté ne se décrète pas. On sème la graine qu'est le code source, on veille aux conditions d'éclosion, on arrose chaque jour. La communauté va germer un jour, doucement, puis prendre racine, petit à petit. Et quelles sont ces conditions optimales à réunir ? Un bon produit, évidemment, mais aussi l'écoute, l'échange, la communication, une gouvernance équilibrée et transparente. Et des outils, bien sûr, comme support de tout cela.

En général, une communauté naît plus facilement lorsque votre projet n'a pas une finalité commerciale, car les contributeurs peuvent être réticents à l'idée que leur travail bénévole sert à vous enrichir. Dans le cas de produits commerciaux, un modèle noyau-extensions est parfois le bon moyen d'articuler un produit central dont le développement est centralisé, entouré par un foisonnement d'extensions, qui sont du ressort de la communauté.

Quels outils, quelle forge ?

Si vous avez choisi un modèle de développement communautaire, alors il vous faut choisir une forge pour accueillir vos sources, vos travaux, vos échanges.
Nous ne détaillerons pas ici des outils de développement proprement dits, outils d'infrastructure, environnement de développement, gestionnaire de source, tracker et compagnie. Si vous souhaitez ouvrir le développement et avez de petits moyens, le plus simple est de gérer votre projet sur l'une des forges disponibles gratuitement pour les projets open source. L’ancêtre est le célèbre SourceForge (sourceforge.net), mais les développeurs tendent à préférer maintenant des forges plus faciles à utiliser, mieux intégrées, telles que Google Code (code.google.com), Github (github.com/) ou encore Gitorious, une déclinaison plus communautaire.
Par rapport au classique SVN, Git est plus encore tourné vers le développement collaboratif. Chacun peut forker (amicalement) le programme pour y ajouter ses développements et l'auteur initial est libre de choisir les travaux qu'il intègre.
C'est une approche qui abaisse la barrière à l'entrée pour les contributeurs, tout en préservant une certaine maîtrise d'ensemble.
Outre les outils qu'elles proposent, ces forges contribuent aussi à faire connaître votre projet, puisque beaucoup vont y faire des recherches. Votre projet sera également référencé sur Ohloh.net, où il attirera peut-être l'attention de nouveaux contributeurs. Si vous avez plus de moyens, vous pouvez opter pour une forge dédiée, telle que Tuleap par exemple, ou des outils très simples tels que Redmine. Mais l'initiateur d'un projet open source a souvent tellement à faire avec son propre développement qu'il appréciera les outils prêts à l'emploi en mode SaaS, bien que les plus connus ne soient pas open source eux-mêmes.

Si votre projet a une finalité suffisamment générale, qu'il a un socle solide et déjà de multiples contributeurs, que vous acceptez les règles de gouvernance associées, alors vous pourrez un jour le soumettre à l'incubateur de la fondation Apache. Indépendamment des ressources et outils de la fondation, c'est évidemment une consécration pour un projet open source, et l'assurance d'attirer des contributeurs de qualité.

Choisir sa licence

Le choix de la licence peut s'avérer déterminant pour votre projet. Certes, si vous détenez le droit d'auteur sur l'ensemble de vos sources, vous pourrez toujours changer de licence ultérieurement, mais il est grandement préférable de faire le bon choix dès le départ.
Les utilisateurs, particulièrement en entreprise, n'aiment pas les licences exotiques. N'inventez pas des termes de licences qui vous seraient propres : il existe suffisamment de licences bien connues pour que vous soyez certains d'y trouver votre bonheur.
Il y a deux grandes familles de licences open source, qu'on appelle parfois « copyleft » et « non-copyleft ». Les licences copyleft, essentiellement la GNU GPL et ses variantes, se caractérisent par l'obligation qui est faite à ceux qui voudraient redistribuer le logiciel, éventuellement modifié, de le faire sous les mêmes termes. Autrement dit, un tiers ne peut pas refermer le code, ne peut pas construire un produit non-Libre à partir de votre produit Libre. Cela réduit donc les risques de devoir subir quelques concurrents profiteurs. C'est la raison pour laquelle la GPL est souvent choisie par les éditeurs à vocation commerciale.
A contrario, les licences « non-copyleft » exigent peu de choses, et sont choisies en général par ceux qui sont motivés par la plus large utilisation possible de leur logiciel. Pour être précis, entre les deux existent aussi des licences dites « weak-copyleft », qui ont une exigence intermédiaire.

Donc pour faire simple, si votre but est de voir votre logiciel utilisé le plus largement possible, quitte à ce que d'autres en fassent une version non-Libre, alors vous opterez pour une licence non-copyleft, telle que Apache, MIT ou BSD.
Si vous avez un objectif économique, vous choisirez sans doutes davantage une licence GPL, voire LGPL.

Attention, on ne dit pas ici que la licence GPL serait le moyen le plus sûr de gagner de l'argent !

En soi, elle ne vous rapportera rien, et en particulier ne vous permettra pas de réclamer un quelconque droit d'utilisation. Et l'objectif des licences copyleft n'est pas celui-ci, il est plutôt de promouvoir une logique de donnant-donnant, qui stimule de proche en proche l'utilisation de licences Libres. Du moins les licences copyleft permettent d'éviter des œuvres dérivées qui seraient propriétaires, et probablement concurrentes.
Citons également ici la licence Affero GPL (AGPL), qui oblige celui qui offrirait un service de type SaaS utilisant votre logiciel à publier son propre code source sous la même licence.
Une autre considération à prendre en compte en matière de licence est l'intégration d'autres composants open source, qui vous feront gagner du temps et de l'argent, mais qui feront de votre logiciel une œuvre dérivée, soumise donc aux obligations de licence de chacun de ces composants.
Vous devez ainsi vous intéresser vous-mêmes à ces exigences, et vérifier que la licence que vous souhaitez utiliser est bien compatible avec celles de tous les composants intégrés.

Quel modèle économique ?

Comme on l'a dit en introduction, votre but n'est peut-être pas de vous enrichir. Si votre effort est purement bénévole et humaniste, alors vous pouvez passer ce paragraphe.
Il existe de très belles success-stories commerciales dans le logiciel open source, parmi lesquelles ont peut citer Redhat évidemment, MySQL, JBoss, OpenERP, Talend ou encore Magento. Mais bien d'autres également.
A partir de 2000 environ, il semblait que toutes les startups du logiciel choisissaient un modèle en tout ou partie open source, ce qui a donné un formidable enrichissement de l'offre dans la dernière décennie.

Pourtant, il n'est pas aisé de gagner de l'argent avec un logiciel que chacun peut redistribuer librement, sans contrepartie. Il existe une diversité de modèles économiques pour le logiciel libre. Certains fondés sur la seule offre de support, et de quelques prestations associées. D'autres sur une politique de double licence avec – pour caricaturer – une licence Libre pour faire connaître le produit, une licence non-Libre pour gagner de l'argent.

Même s'ils partagent, en général les valeurs du Logiciel Libre, des valeurs de liberté et de biens communs, certains éditeurs choisissent un modèle open source à des fins marketing : ils comptent sur le bouche à oreille et la libre diffusion du logiciel pour créer une base installée rapidement. Et si le produit est bon, ça peut marcher. Et puis, une fois leur logiciel largement diffusé et utilisé, ils se demandent comment transformer ce succès d'estime en revenus.
Une chose est sûre : il ne faut malheureusement pas compter sur le sens du devoir ou la grandeur de l'âme humaine pour expliquer aux utilisateurs qu'ils ne sont pas tenus de payer, mais que ce serait sympa quand même.
Ce serait certainement légitime, mais ça ne marche tout simplement pas. Pour convaincre vos utilisateurs de vous payer alors qu'ils n'y sont pas contraints, il faut leur faire une promesse convaincante, leur offrir une réelle valeur ajoutée.

Si votre produit est entré dans des grandes entreprises, intégré à des utilisations critiques, alors la demande de support viendra naturellement : les DSI sérieuses n'imaginent pas qu'une fonction critique dépende d'un logiciel sans contrat de support.
Mais plus largement, il peut y avoir un équilibre délicat à trouver entre utilisations payantes, et utilisations gratuites. Si un jour vous comptabilisez les utilisateurs de votre produit qui ne payent rien, et que ce décompte vous fait enrager, inutile d'adresser des messages de supplication ou d'injure à votre base installée, l'open source n'était peut-être pas le modèle qui vous convenait !

Dans les années 2000, MySQLétait la figure emblématique de l'éditeur open source. Moins de un déploiement sur 1000 de la base de données qui donna son nom à la plateforme LAMP était source de revenu pour l'entreprise MySQL AB.
Mais par la loi des grands nombres, ce petit pourcentage suffisait à faire vivre une entreprise qui comptait 400 employés en 2008. Votre produit ne vise peut-être pas cette échelle, mais du moins il faut comprendre que, pour un modèle économique viable, il faudra soit une petite base installée et un fort taux d'utilisations payantes, soit une faible taux de payant mais une grande base.

Intégrateur de son propre produit

Il est probable que votre produit aura besoin d'intégrateurs, de prestataires capables de le mettre au service de ses utilisateurs finaux. Pour un logiciel libre et gratuit, la prestation d'intégration peut représenter la plus grande part de la facture du client final. Or personne mieux que vous ne saura faire le meilleur usage de votre produit. Pourquoi ne pas en proposer l'intégration vous-mêmes ?
Vous en serez le meilleur ambassadeur, ça vous fera des revenus rapides, ça vous permettra d'être en relation directe avec vos utilisateurs, et donc de bien sentir les forces et faiblesses du produit.
Bref, presque que des avantages. Et c'est ainsi que de nombreux éditeurs de logiciels, tout particulièrement open source, commencent par être leur propre intégrateur. Mais en grandissant, les quelques inconvénients apparaissent. L'intégration est un métier qui n'est pas « scalable », comme disent les investisseurs, c'est à dire que les coûts (les salaires) augmentent de manière linéaire quand augmente le chiffre d'affaire, de sorte que les bénéfices sont peut-être plus faciles au début, mais structurellement limités. Tandis que le métier d'éditeur pur, pour un produit à succès, peut amener des marges de plus de 50 %. Même si, dans l'open source, ce type de marge est difficile à atteindre sans quelques entorses au modèle.

Il est difficile aussi d'être intégrateur de son propre produit à l'international

Et c'est souvent lorsqu'il cherche à sortir des frontières de son pays d'origine que l'éditeur abandonne l'intégration pour se concentrer sur son cœur de métier. Les logiciels, surtout open source, franchissent facilement les frontières, pour peu qu'ils aient un site et une interface en anglais, voire multilingue. Sans y avoir œuvré particulièrement, on peut s'apercevoir un jour que son logiciel est déployé du Brésil aux Philippines. Il est temps alors d'organiser un véritable réseau de partenaires intégrateurs, de valider leur niveau d'expertise, de s'assurer qu'ils sont motivés à vendre votre offre.

L'international

Le marché du logiciel est global, mondial. Pour un logiciel propriétaire, le penchant naturel serait de se contenter d'abord de son marché national, voire même local.
Il est vrai que s'il faut embaucher des commerciaux, faire de la prospection, des rendez-vous, des démos, des salons, … pour arriver à vendre son produit, on ne peut pas faire tout cela à grande échelle dès le démarrage.
Mais ce sont là de vieilles méthodes, dont un logiciel open source peut se passer. Pas éternellement sans doutes, mais certainement au démarrage. Si le commerce se fait par bouche à oreille, si le libre téléchargement, et la libre utilisation du programme permet à chacun d'en mesurer les atouts, si les réseaux sociaux propagent la bonne nouvelle… le produit peut prendre son essor à l'international pratiquement sans effort.
La condition première, c'est que toute sa communication, son interface utilisateur et toute sa documentation soient au minimum en anglais, et autant que possible traduites en quelques langues. Ainsi, de nombreux créateurs de logiciels open source s'émerveillent de voire leur produit utilisé à l'autre bout de la terre. Même si ces utilisateurs lointains n'envoient pas de bon de commande, leur impact est énorme. Dans un an ou deux, peut-être commencerez vous à tisser un réseau d'intégrateurs à l'international, et ces utilisateurs de la première heure seront alors des atouts précieux.

Conclusion

Nous espérons avoir couvert ici les principales questions et démarches à intégrer pour lancer un projet open source. Rappelez vous que le succès de votre projet dépendra pour beaucoup de votre code, mais pas uniquement de votre code. De votre concept, bien sûr, de votre capacité à faire connaître votre projet, à faire naître une communauté, à piloter une startup aussi, et le cas échéant à convertir votre succès en revenus, qui pourront assurer la pérennité de votre aventure.