On distingue trois grandes familles de logiciels open source : (1) les produits de fondations (Apache, Eclipse, Linux, …), (2) les produits communautaires et (3) les produits d’éditeurs. La question des modèles économiques se pose essentiellement pour ces derniers, dont l'offre constitue une part croissante du patrimoine open source.

On sait bien que les logiciels open source ne sont pas tous écrits par des bénévoles, le soir après leur travail, pour le plaisir ou pour la gloire. Ils existent, ces développeurs passionnés qui prennent sur leur temps libre pour faire avancer des projets. Ils existent, et on peut les remercier, mais ils n’écrivent au final qu’une toute petite partie des programmes open source que nous utilisons.

Or développer un programme de qualité coûte cher, même s’il est open source. Un peu moins cher peut-être que son équivalent propriétaire, parce que (a) il peut s’appuyer sur d’autres briques open source, pour autant que leur licence le permette, (b) il peut bénéficier de contributions communautaires, et (c) il a probablement plus de développeurs passionnés. Mais tout cela ne fait pas du logiciel à moitié prix.

Puisque développer un programme coûte cher, il faut bien que l’éditeur trouve un retour sur son investissement. Et même une certaine prime de risque, puisque son risque est grand de ne pas rencontrer le succès espéré.

Ce qui pose la question du modèle économique des éditeurs open source, souvent indissociable du choix de licences. Nous proposons une petite revue de ces modèles, et des grandes tendances du moment.

Vraiment open source ?
Certains éditeurs pourraient être tentés d’être « plus ou moins open source », diffuser les sources sans les droits d’utilisation, ou avec différentes conditions restrictives, bref de se proclamer open source sans l’être vraiment.
Heureusement, ce n’est pas possible, et c’est l’apport fondamental d’institutions comme la FSF et l’OSI, que de définir sans ambigüité ce qui est, et ce qui n’est pas, une licence open source.
Les éditeurs open source ne peuvent donc pas tricher, ils doivent diffuser leurs produits sous une licence agréée. Ce qui signifie que les utilisateurs peuvent librement et gratuitement redistribuer lesdits produits, c’est la définition même.
La plupart des éditeurs choisissent la licence GPL, qui présente pour eux deux grands avantages : (1) elle est connue et donc parfaitement lisible, elle est perçue par le marché comme un gage de transparence, (2) elle interdit à d’autres d’intégrer le produit dans un développement propriétaire, et donc de se faire de l’argent sur le dos de l’auteur ou détenteur du droit d’auteur.

Quels revenus ?
Pour un éditeur open source, les sources de revenus possibles sont  les suivantes :
- le support et la maintenance
- les prestations associées: audit, conseil, formations, voire intégration
- les droits d’utilisation associés à la licence, à une licence non libre, donc.
- les reversements de prestataires habilités

Dans une logique d'une expansion globale et rapide, les éditeurs ne peuvent pas miser beaucoup sur les prestations. Faire l’intégration de son propre produit est tentant au début, mais cela ne permet pas de construire un réseau de partenaires intégrateurs.

Mais surtout, un modèle économique basé sur la prestation est perçu par les éditeurs, et ceux qui les financent, comme un modèle « non scalable », c'est-à-dire qui ne permettra pas d’augmenter les revenus sans augmenter les effectifs, et donc les coûts. En somme un modèle qui ne permettra pas les taux de marge des éditeurs propriétaires.

Modèle 1 : faire payer le support
Certains éditeurs ont un business model fondé presque uniquement sur l'offre de support. Dans cette catégorie on trouve eZ Systems, Nuxeo, Tiny (OpenERP), Spago.
Il n’y a qu’une version du produit, et une licence unique - open source donc - un seul référentiel de sources, et des correctifs disponibles à tous. Le produit peut être librement téléchargé et déployé, et les « clients » ont le droit d’utiliser le produit sans payer le support.

Le support étant clairement facultatif, il faut savoir démontrer aux clients les bénéfices qu’ils peuvent en attendre. Auprès des DSI de grands comptes, ce n’est généralement pas trop difficile. En cas de plantage d’une application critique, personne n’imagine d’aller expliquer au président qu’il était possible de souscrire un support mais qu’on avait préféré s’en passer ! Et par ailleurs, les grandes DSI perçoivent bien que l’économie est déjà très grande par rapport aux logiciels qu’elles utilisaient précédemment. Mais auprès de plus petites entreprises, la démonstration est parfois plus difficile.
L'une des difficultés du pur support annuel et que s’il n’a pas servi pendant une année, certains pourront hésiter à le renouveler. Bien sûr, on leur dira : il y a une logique d’assurance dans une prestation de support, ce n’est pas parce que vous n’avez pas été cambriolé cette année que vous allez résilier votre assurance ! Mais de leur côté ils répondront : si cette appli a tourné sans problème pendant un an, elle pourra bien continuer de tourner un an de plus !
C’est le problème et le paradoxe du support : plus le produit est de qualité, moins le support est facile à vendre.

Mais en fait, une majorité de produits sont en permanente évolution, sous la pression concurrentielle. Et c’est la force des produits open source que d’évoluer souvent plus vite que les autres. Le produit n’est jamais totalement stabilisé, toujours en mouvement, et le support toujours précieux pour une utilisation professionnelle.

Modèle 2 : faire payer la stabilité
D'autres éditeurs choisissent un modèle qui fait payer la stabilité. Ils distribuent leur produit sous deux licences, l'une libre, l'autre non-libre. Mais ce n'est pas tout à fait le même produit.
Dans cette catégorie, on peut citer Alfresco, Jahia, Pentaho, eXo, Liferay.

Avec la licence non-libre, on a une version « enterprise-ready », « production grade », « fully tested », etc. tandis que la version libre, intitulée « community », ou encore « labs », est présentée comme pas stable, pas testée, vraiment le truc pour les geeks, limite dangereux, à ne surtout pas déployer en production.

Le vocabulaire est celui-ci, mais dans les faits les différences ne sont pas toujours bien identifiées. L’éditeur ne peut pas faire vivre deux référentiels de code différents sur le long terme, il faut donc au minimum resynchroniser community et enterprise de temps en temps. En général, la version community est la version en cours de développement, sur laquelle les développeurs interviennent en continu, tandis que la version enterprise est celle qui a été gelée puis validée en profondeur, a reçu différents correctifs et en reçoit en continu, distribués dans le cadre du support.

Ainsi, paradoxalement, la version community est en avance de phase, elle dispose des dernières fonctionnalités, mais elle est moins stable, soit du fait d’une avance de phase dans les développements, soit du fait d’un retard dans les correctifs. Dans un bon gestionnaire de sources, on pourrait espérer pouvoir extraire la dernière version stable, voir même y réappliquer les patchs, mais ici ce n’est pas le but.
Le support vient en bundle avec la licence entreprise, dont il est indissociable, tandis qu'au contraire on ne peut espérer aucun support, même payant, sur la version libre.

Pour l’éditeur, les avantages sont nombreux.
La version community aide à diffuser le produit, à le faire connaître largement au niveau mondial, tant par les clients potentiels que par les intégrateurs potentiels.
Et par ailleurs, une fois parti sur la version enterprise et son support annualisé, il est délicat pour le client de revenir à une version community. Le downgrading serait à gérer comme une véritable migration. Il y a donc une forme de fidélisation que ne permet pas le seul support payant.

A l’inverse, l’inconvénient est que si la version community est trop instable, elle ne contribue pas à la bonne image du produit et à sa promotion. Et si au contraire elle est d’une bonne qualité, elle risque d’être utilisée malgré les mises en garde alarmantes.

Laisser les utilisateurs expérimenter une version instable n’est pas toujours suffisant. Le processus complet d’adoption est bien souvent : recueil d’information, téléchargement, expérimentation, projet réel non critique, et enfin projet stratégique. Pour beaucoup d’entreprise, la version community doit permettre d’aller jusqu’au projet réel non critique, qui permettra de faire un choix stratégique. C’est en cela que le degré de stabilité doit être étalonné avec soin.

Modèle 3 : 
faire payer les fonctionnalités avancées
Enfin, le troisième modèle est celui d’une licence double définie selon le niveau de fonctionnalités : une version GPL avec des fonctionnalités réduites, une version enterprise non libre avec des fonctionnalités avancées.

Dans ce dernier modèle, on trouve par exemple Talend, Jasper, ou encore MySql.
Dans ce cas, il n’y a pas de différence de qualité, de stabilité. Les programmes correspondant au premier niveau de fonctionnalités sont les mêmes. Comme pour n’importe quel programme, le gestionnaire de sources identifie les dernières versions stables, et les derniers builds, mais n’importe qui peut aussi télécharger la dernière version stable. En revanche, les sources de la version enterprise ne sont parfois pas diffusées du tout.
Ne pas définir la différence en termes de qualité offre d’une certaine manière une meilleure image de l’éditeur, de sa capacité à produire un logiciel solide. Elle évite l’association d’idées « libre = instable », qui est assez désagréable et par ailleurs infondée.

Mais ici aussi, toute la difficulté réside dans le tracé de la frontière : il faut en mettre suffisamment dans la version libre pour qu’elle soit largement diffusée et donne l’impression d’un produit riche, et suffisamment limitée ne pas permettre des utilisations à forte valeur ajoutée.

Conclusion
Depuis quelques années, l’open source commercial est une branche particulièrement vivace, et apporte des applications professionnelles de grande qualité. Il faut bien comprendre que la vitalité de ces nouveaux acteurs n’est possible que si un mode de financement équitable du développement est assuré.
L’analyse des business models est importante, mais il faut souligner surtout que l’open source ne se définit pas comme un moyen différent d’acheminer l’argent du consommateur vers le producteur, un intitulé différent en haut de la facture en somme. L’open source se définit surtout par des modèles de développements différents, l’association d’un noyau d’éditeur et d’extensions communautaires amenant une exceptionnelle dynamique de développement, une diffusion plus large apportant des produits plus rapidement matures et stables, et au final, un coût global très favorable, apportant de réels gains de compétitivité. Et on pourrait y ajouter une liberté accrue, un meilleur respect des standards et une pérennité supérieure.

Même pour les plus ardents défenseurs du libre, gagner de l’argent n’est pas interdit : c’est la licence qui définit le logiciel libre et non la gratuité. Les nouveaux éditeurs open source sont en position de challenger, et cherchent un modèle qui respecte les principes de l’open source et qui néanmoins leur assure des revenus, un retour sur l’investissement énorme du développement. Quel que soit le modèle retenu, les nouveaux éditeurs open source sont d'importants contributeurs au patrimoine logiciel open source de l’humanité.

Patrice Bertrand est auteur du livre blanc intitulé "Introduction à l'open source et au logiciel libre