Évaluer les besoins du marché pour votre projet

Une entreprise perçoit souvent le logiciel libre comme un moyen de sauver un projet, de gagner en notoriété, ou simplement de placer de façon élégante une catégorie de produits sur une voie de garage. Ce ne sont pas de bonnes raisons pour lancer un projet Open Source, et une entreprise déterminée à poursuivre ce modèle a besoin de connaître exactement ce dont le produit a besoin pour garantir le succès d'une stratégie fondée sur du code ouvert.

La première étape consiste en une étude de l'existant, donc de tous les concurrents commerciaux ou libres, même les plus modestes. Soyez très attentif afin de déterminer ce que votre produit offre en séparant les parties qui peuvent être potentiellement offertes avec un produit commercial, vendues, ou bien dont le code source peut être publié séparément. De même, n'excluez pas des combinaisons de logiciels libres et commerciaux qui offrent les mêmes services.

Revenons à l'exemple du vendeur de base de données ci-dessus. Son produit comporte trois parties : un serveur SQL, un gestionnaire de transactions et de sauvegardes, et une bibliothèque de développement. Il ne doit pas seulement comparer ses produits avec ceux des leaders comme Oracle et Sybase, et ceux des petits concurrents dynamiques comme Solid et Velocis, mais aussi avec les bases de données libres telles que MySQL et Postgres. Une analyse de ce genre montrera peut-être que le serveur SQL apporte seulement quelques fonctionnalités supplémentaires à MySQL, et dans un domaine qui n'a jamais été considéré comme étant décisif sur le plan commercial mais simplement nécessaire pour rester en phase avec les concurrents. Le gestionnaire de sauvegardes et de transactions n'a aucun concurrent libre, et la bibliothèque Perl DBI surpasse la bibliothèque de développement proposée mais n'a pas de véritable concurrent en Java ou en C.

Cette société pourrait envisager les stratégies suivantes :

• Constituer un nouveau produit en remplaçant le serveur SQL par MySQL, auquel elle ajoutera les fonctionnalités spécifiques de son serveur SQL ainsi que le gestionnaire de sauvegardes et de transactions. De plus elle vendra les bibliothèques Java et C, et fournira la bibliothèque libre en Perl et l'assistance technique correspondante. Cela permettra de bénéficier de l'engouement pour MySQL et de l'incroyable bibliothèque de plug-ins et de codes additionnels proposés par des utilisateurs de ce logiciel. Cela vous permettra de conserver la propriété de tout le code breveté ou brevetable, ou simplement du code qui confère un avantage compétitif. Présentez-vous en tant qu'entreprise capable de déployer MySQL même au sein des environnements les plus étendus.

• Offrir la « fonctionnalité spécifique » aux développeurs de MySQL afin qu'ils l'y intègrent, puis modifier le gestionnaire de sauvegardes et de transactions afin de prendre en charge un grand nombre de bases de données, et afficher une nette préférence pour MySQL. Ceci a un revenu potentiel plus faible, mais permet à votre entreprise de rester plus focalisée et d'atteindre un plus large groupe de consommateurs. Un tel produit peut aussi être plus facile à maintenir.

• Aller dans la direction opposée : commercialiser le serveur SQL et les bibliothèques mais libérer le code source du gestionnaire de sauvegardes et de transactions, en tant qu'utilitaire général destiné à un grand nombre de types de serveurs. Cela réduirait votre coût de développement pour ce composant, et offrirait un avantage marketing à votre serveur. Cela réduirait un peu l'avance que vos concurrents auraient gagné grâce à l'Open Source, même si cela réduirait aussi un peu la vôtre.

• Libérer la totalité du serveur SQL en tant que tel, séparément de MySQL, de Postgres ou de tout autre logiciel existant, et vendre des contrats d'assistance technique pour votre logiciel. Vendre l'outil de sauvegarde mais libérer le code source des bibliothèques afin d'encourager de nouveaux utilisateurs. Cette stratégie augmente le risque car un logiciel populaire comme MySQL ou Postgres existe depuis déjà longtemps et un développeur manifeste d'ordinaire une réticence au changement si le logiciel déployé fonctionne correctement. Pour faire cela, vous devez souligner les avantages patents de votre produit pour que les utilisateurs soient tentés de l'essayer : plus rapide, plus souple, plus facile à administrer ou à programmer, ou riche de nouvelles fonctionnalités. Vous devez aussi consacrer davantage de temps aux actions susceptibles d'attirer l'attention de la clientèle potentielle, et trouver un moyen d'éloigner les développeurs des produits concurrents.

Je ne proposerais pas la quatrième solution dans ce cas, car MySQL a une très nette avance ici, beaucoup d'ajouts, et de nombreux utilisateurs.

Un projet de logiciel libre décline parfois à cause d'un manque de dynamisme des membres du noyau de l'équipe de développement, ou parce que le logiciel devrait s'affranchir des limites de sa propre architecture afin de satisfaire de nouveaux besoins, ou bien parce que la demande dépend d'un contexte révolu. Quand cela arrive, les gens cherchent alors d'autres solutions et il devient donc possible d'introduire un autre produit qui attirera l'attention même s'il ne constitue pas une avance significative sur le statu quo.

La demande engendre de nouveaux projets de logiciels libres, son analyse est donc absolument nécessaire. Le développement d'Apache commença lorsqu'un groupe de webmestres partagèrent les corrections apportées au logiciel serveur Web du NCSA, puis décidèrent qu'échanger des corrections comme autant de cartes à collectionner restait peu efficace et sujet aux erreurs. Ils décidèrent donc de proposer une distribution séparée du serveur du NCSA incluant leurs modifications. Aucun des acteurs principaux des débuts ne s'est engagé parce qu'il voulait vendre un serveur commercial, bien que ce soit certainement une raison valable de le faire.

Une analyse de la demande du marché pour un projet particulier de logiciel libre impose aussi de s'abonner aux listes de diffusion et les forums Usenet pertinents, de fouiller les archives, et d'interroger vos clients et leurs collègues. Alors seulement vous pouvez déterminer si certains souhaitent participer au projet.

Revenons aux débuts du serveur Apache. Ceux d'entre nous qui échangions des corrections, les envoyions aussi au NCSA dans l'espoir de les voir inclus dans la distribution, ou tout au moins validés afin de nous faciliter leur intégration à des versions ultérieures. Puis Netscape embaucha certains des développeurs de ce serveur, et les autres ne parvinrent plus à gérer les messages électroniques expédiés par toutes les parties intéressées. Construire notre propre serveur fut plus une action d'auto-préservation qu'une tentative visant à proposer un serveur Web. Il est important de commencer avec des objectifs limités donc faciles à atteindre, et de ne pas devoir attendre que votre projet domine le marché avant de réaliser des bénéfices.