Les logiciels open source et propriétaires sont parfois coude à coude et les business model basés sur l’édition de logiciel open source ont fait le succès d’entreprise comme Google, Red Hat ou encore SensioLabs (créateur du framework PHP Symfony).

Avec la “libération des sources”, vient également le risque de perdre des rentrées d’argent et le fruit d’un investissement long et coûteux.

Dans cet article nous donnerons quelques éléments d’analyse pour permettre à une entreprise de faire le “bon” choix.

Si vous n’êtes pas à l’aise avec les termes d’ “open source”, “libre” et logiciels “propriétaires”, je vous conseille la lecture de “Qu’est-ce que l’open source”.

Éditeur open source, vraiment ?

Qu’est ce qu’un éditeur open source ? La question fait débat.

Nous considérerons ici qu’un éditeur open source est une entreprise qui investit des ressources sur un projet open source.

On peut par exemple considérer SensioLabs comme éditeur open source puisqu’elle a considérablement investi dans des logiciels comme le framework Symfony mais également dans la création du moteur de template Twig et une multitude d’autres logiciels.

Google investit également dans de nombreux logiciels open source, le plus connu étant le système d’exploitation mobile Android.

On ne peut — par contre — considérer une agence web qui vend des thèmes Wordpress comme un éditeur open source, on parlera alors d’intégrateur de solutions open source (le plus connu en France étant Smile).

Les sources de revenus

Les sources de revenus qu’une entreprise peut attendre d’un logiciel open source sont les mêmes que pour un logiciel propriétaire et on peut les caractériser en trois activités.

La vente de licences

Il peut sembler très curieux de vendre un logiciel open source. Pourtant, bien que la licence impose la libre redistribution des sources rien ne s’oppose à la vente d’un logiciel.

Dans la grande majorité des cas, l’éditeur va effectuer un “double-licensing” avec une première version “gratuite” et open source et une version commerciale basée sur la version open source, complétée de fonctionnalités qui ne sont pas “versées” dans la version open source.

Deux exemples:

RHEL (Red Hat Enterprise Linux) est une version de GNU/Linux basée sur Fedora (un système d’exploitation GNU/Linux libre) mais fournie avec un support et une suite logicielle professionnelle;

Magento (un logiciel pour créer une boutique e-commerce) qui se présente en version “communautaire” et en version entreprise payante;

Selon Smile, les souscriptions représenteraient 82% des revenus de Redhat, le reste provenant des prestations de formations et conseil.

Vente de prestations

C’est le modèle utilisé pour la plupart des CMS (“Content Management System” ou Système de gestion de contenu) et frameworks web comme Wordpress, Drupal, Typo3 ou encore Zend Framework.

Les solutions open source découvertes et devenues attractives grâce à la libération de code, offrent l’assurance pour une entreprise que le projet sera et pourra être maintenu, l’éditeur percevant des revenus en paiement de prestations de développement et de formation.

Que se passe-t-il quand un éditeur qui a réalisé tout votre système d’information avec une technologie propriétaire “coule” ?

En cela, “l’initiateur” du projet a une position privilégiée par rapport à ses concurrents (les “intégrateurs de solution open source”) de part sa plus grande implication dans le projet et sa (supposée) plus grande maîtrise de sa création.

Deux exemples:

SensioLabs , avec son parcours de formation d’une part et son offre d’accompagnement technique complète d’autre part;

Wordpress, par une offre cloud de livraison d’un site en quelques clics entièrement configurable mais aussi par la présence d’un “marketplace” de thèmes et d’extensions;

Vente de support et de maintenance

Un bon projet open source disposera d’un programme de livraison des prochaines mises à jour et d’une durée de maintenance pour chaque version majeure.

Les entreprises ont cependant besoin d’un support professionnel pour régler rapidement les bugs et pouvoir parfaitement intégrer le logiciel à leur système d’information.

Parfois, comme c’est actuellement le cas avec Windows XP (qui n’est pas open source, bien sûr), les entreprises ont besoin de maintenir le logiciel au de-là de l’engagement originel de l’éditeur et peuvent le rémunérer pour cela.

Encore deux exemples:

Docker, une solution de déploiement d’applications dont le business model repose uniquement sur le support;

La politique de support du SGBD (Système de Gestion de Base de Donnée) MySQL, en complément de différentes versions de MySQL déjà proposées en propriétaire et open source;

Les sources de dépenses

Le développement et la maintenance d’un logiciel — qu’il soit propriétaire ou open source — est long et coûteux sur la durée. Pour chaque logiciel qui est au cœur d’une stratégie commerciale, il faut également prendre en compte le coût de commercialisation et de promotion du logiciel.

Développement et maintenance du logiciel

Le développement d’un logiciel open source reste long et coûteux, mais présente deux avantages par rapport à son “équivalent” propriétaire:

Les sources du code étant accessibles à tous, et il y a donc statistiquement plus de chances qu’un bug soit remonté. C’est pourquoi on a tendance à trouver plus de bugs dans un logiciel open source que dans un logiciel propriétaire, ce qui est une bonne chose;

Si une communauté se crée autour du projet, des personnes travailleront à l’amélioration du projet sur la base du volontariat. A titre d’exemple, le CMS Drupal affirme avoir reçu depuis sa création plus de 30 000 contributions, ce qui est une économie certaine et un gage de qualité;

100 bugs connus ou 5 non connus ?

C’est la différence entre un logiciel open source et un logiciel propriétaire.

La promotion du logiciel

La clé du succès d’un logiciel open source, c’est de devenir suffisamment populaire pour que les acteurs des systèmes d’information (autrement appelés “les décideurs”) connaissent votre produit et pensent qu’il est suffisamment bon et stable pour intégrer leur système.

Chaque introduction d’un nouveau logiciel dans un système d’information étant considérée comme un risque potentiel, les logiciels open source ont été inclus que très tardivement dans les grandes entreprises, privilégiant la “sécurité” du support de très grandes entreprises comme Microsoft et Oracle.

Les entreprises sont très sensibles à l’activité, à la taille et à la maturité de la communauté autour d’un logiciel, c’est pourquoi un éditeur open source doit communiquer auprès de deux publics:

Sa communauté, par le biais d’un forum, d’événements dédiés mais également d’ une documentation complète et à jour ;

; Les décideurs, en réalisant des études de cas clients, des livres blancs et / ou des présentations commerciales;

Smile par exemple, est une référence pour la qualité de ses livres blancs que je vous invite à consulter si vous êtes intéressés par l’open source.

Le support

C’est probablement le coût qui est le plus difficile à évaluer pour une entreprise, puisque dépendant de l’utilisation du logiciel. Le support peut autant concerner le logiciel, que ce qui a pu être réalisé avec celui-ci, et les entreprises seront très sensible au support minimal offert par l’éditeur et sur quelles périodes s’étendent les maintenances évolutives et de sécurité.

A titre d’exemple, voici le planning de maintenance et de sortie du projet Symfony:

(sources: la documentation Symfony)

Jaune: phase de développement

Bleu: phase de stabilisation

Vert: phase de maintenance (évolutive et de sécurité)

Quelques conseils

De ma propre expérience et des entretiens que j’ai pu avoir avec des acteurs du monde open source, voici une liste de conseils (subjective) à enrichir de la connaissance que vous avez de votre logiciel et du marché dans lequel il évolue.

Open sourcez si …

vous avez un logiciel suffisamment intéressant et abouti, dédié aux professionnels et basé sur un projet open source communautaire

=> licence ( $$$ );

=> licence ( ); puissant, stable et dont la courbe d’apprentissage est longue

=> support ( $ ), prestations( $ ), formations ( $$ );

=> support ( ), prestations( ), formations ( ); super modulable et extensible par le biais d’extensions ou thèmes par exemple

=> support($), plateforme cloud ($$), marketplace ($$$);

N’open sourcez pas si …

vous n’avez pas les ressources nécessaires pour assurer l’effort initial en termes de développement, communication, documentation;

votre produit répond à un besoin clairement identifié, et que vous n’avez aucune concurrence (ex: la suite Adobe);

vous ne souhaitez pas céder le “pouvoir de décision” à autrui, la libération des sources implique très souvent un fonctionnement démocratique qui ne convient pas au mode de fonctionnement de tous les éditeurs logiciels;

Cet article est maintenant terminé. N’hésitez pas à me faire part de vos questions et commentaires en utilisant le formulaire ci-dessous.

Le prochain article sera un retour d’expérience de la mise en open source du CMS open source BackBee que nous développions en interne chez Lp digital.