J'avoue que de mon côté ça me dérange du français
sans accent, à vrai dire, ça n'est plus du français. Mais plutôt que d'être critique, je préfère être constructif, ainsi j'ai accentué
et corrigé le texte, en essayant de rester le plus possible à la philosophie du texte. Je pense monsieur Penso que ça serait sympa d'en faire la version « officielle » en virant les corrections qui ne te plaisent pas. Ci dessous le texte corrigé:
La nouvelle du changement de licence de TuxRacer m'a poussé à mettre par
écrit quelques petites réflexions sur la GPL, le logiciel libre et l'économie,
que je voudrais partager avec vous. C'est un peu long et c'est sans accents
(parce que ca va beaucoup plus vite à taper comme ca, je prie humblement les
lecteurs que cela gêne de m'excuser
-> NdT: ça me gêne alors qu'on maltraite ainsi notre si belle langue et de plus
sans accent, ça peut porter à confusion. Alors j'ai fais une petite traduction,
en essayant de respecter le texte original tout à fait brilliant, envoyez-moi
les corrections à cgillot@free.fr si par hazard une faute se serait
malencontreusement introduite...).
J'espère que ça éclairera mieux certains comportements.
I- barrière à l'entrée
----------------------
Dans l'économie normale, si on prend un marché donné où il y a un certain
nombre d'acteurs, tout nouvel entrant rencontre une barrière à l'entrée.
Les anciens possèdent une technologie mature, de l'expérience et une base de
clients, ce qui leur permet de vendre respectivement un produit, du service et
des partenariats. C'est la difficulté à obtenir la même technologie, la même
expérience ou les mêmes clients qui détermine la barrière a l'entrée.
La barrière à l'entrée est une chose importante car elle donne une stabilité à
l'écosysteme du marché. Pour être rentable une entreprise a en effet besoin de
pouvoir affirmer qu'elle possèdera une part de marché sur une période quelques
années. Pour une société technologique de taille moyenne, cinquante à deux cent
personnes, six ou sept ans constituent une période de rentabilité raisonnable.
Si la barrière à l'entrée est élevée, cela conduit à un monopole ou à un
oligopole. Les quelques acteurs dominants se partagent le marché, qui s'il
est large, peut être très juteux.
Si la barrière à l'entrée est très élevee, cela devient difficile de
s'installer même pour les leaders. C'est le cas par exemple de l'industrie des
console. Le coût de développement d'un jeu ou d'une console est tellement
élevé que même Sony et Nintendo ne sont jamais sûr de leur operations. Sega a
renoncé et Nintendo est en train de le faire.
Le marché de la téléphonie mobile troisième génération (UMTS) est un
autre exemple de marché nouveau avec une barrière à l'entrée très élevée.
Les coûts de licences et d'infrastructures sont tellement importants que
la rentabilité n'est pas assuré, même pour un oligopole (très peu d'acteurs
sur un marché).
Notons que dans ces deux cas (UMTS et consoles), on vend à des particuliers.
C'est un marché particulièrement difficile car le comportement des particuliers
est difficile a prévoir. Achètera, achetèra pas ?
Si la barrière à l'entrée est très faible, on obtient un marché volatile et
instable. Il y a beaucoup d'acteurs qui essaient de rentrer en permanence sur
le marché. Du coup, le marché devient extrêmement divisé et perturbé, la part
de chaque acteur devient très petite et aucun des acteurs n'est rentable.
Beaucoup de sociétés disparaissent. Ceux qui arrivent à survivre aux
phases initiales restent. Au fur et à mesure que les autres tombent ceux-là
stabilisent leurs parts de marché et leur position dominante. Au final, tout
nouvel entrant aura du mal à prendre une part de marché aux gros qui ont
réussi à survivre. Il y a donc après la stabilisation du marché une barrière
d'entrée qui s'est relevée.
C'est ce qu'on a vu pour les startups. Un marché en création, avec une
barrière a l'entrée extrêmement faible (un site web) et des bénéfices potentiels
élevés. Des centaines d'acteurs se sont rués naïvement dessus et ça a donné ce
qu'on a vu. En fait, on s'aperçoit que la barrière à l'entrée n'est pas si
faible puisqu'il faut fournir un réel service, puis que les revenus eux sont
très faibles (marge sur des achats, publicité, ça ramène pas lourd) et que
donc c'est un marché difficile. Un type intelligent disait qu'il y avait de la
place pour dix acteurs dans la publicité en ligne. C'est ce qu'on a
aujourd'hui, maintenant que le marché s'est stabilisé : yahoo, voila,
boursorama, spray, etc. La barrière a l'entrée est très élevée maintenant, parce
que les acteurs se sont établis et que les marges sont très faibles. On note
encore que là-aussi, c'est un business qui vend aux particuliers, donc
difficile à prévoir.
Ce que je veux faire comprendre, c'est que la barrière à l'entrée sur un
marché est quelque chose de capital pour le succès d'une entreprise. S'il n'y
a pas de barrière à l'entrée suffisamment elevée, les entreprises n'arrivent
pas à protéger leurs acquis et ne rentabilisent donc pas leurs
investissements. Elles disparaissent, l'économie devient morose, on licencie,
il y a des plans sociaux, bref, ça va mal.
II- Business model
------------------
Le business model, qui doit bien s'appeler quelque chose comme « modèle
d'affaire » en francais bien de chez nous, c'est le truc qui décrit comment
vous gagnez de l'argent. En general, quatre paramètres interviennent dans un
business model :
- ce que vous vendez : produit ou service
- combien ca coûte à faire : un logiciel à la con, ça prend six mois de dev à
deux. Un gros logiciel, c'est trois ans, voire plus, pour une équipe de dix
personnes. C'est ce qu'on retrouve pour de très gros logiciels d'entreprise
ou pour les jeux modernes.
- combien vous en vendez : évidemment, c'est important à savoir.
- à qui vous le vendez :
. Entreprises : c'est un marché previsible : elles achètent si ça leur fait
gagner du temps ou de l'argent (ce qui revient au même). Elles ont beaucoup
d'argent donc on peut éventuellement vendre très cher à un petit nombre de
clients privilégiés.
. Particuliers : c'est un marché relativement imprévisible. Le particulier
achète si ça lui plait et si ça coûte pas trop cher.
Si un outil est indispensable à une entreprise, elle est prête à le payer
cher. Donc on peut mettre une grosse équipe pendant trois ans sur un logiciel
qu'on est sûr ensuite de vendre à plusieurs centaines de milliers de francs ou à
plusieurs centaines de milliers d'exemplaires. Pour être sûr de le vendre, il
suffit de prouver à l'entreprise qui l'achète qu'elle va gagner de l'argent
avec.
L'avantage du marché des particuliers, c'est qu'il y en a beaucoup. On peut
donc vendre un logiciel pas cher à beaucoup d'unités pour rentabiliser un gros
et long developpement (typiquement, un gros jeu). Mais le marché des
particulier est assorti d'une incertitude, on n'est jamais sûr qu'ils vont
acheter.
Dans les deux cas que je viens de citer (gros développement), la valeur
ajoutée est sur la technologie. C'est une grosse techno qui coûte cher qu'on
vend. Celle-ci constitue la barrière avec le concurrent qui devra passer
beaucoup de temps pour en avoir une similaire.
On peut aussi vendre des logiciels à faible technologie, mais dans ce cas, il
n'y a pas de barrière technologique. Si on veut empêcher un concurrent de
prendre toutes les parts du marché, il faut trouver un autre type de barrière :
un très bon contact avec le client, une relation privilégiée, un partenariat,
des services spécifiques, une image, un bon réseau de distribution.
III- Logiciel libre.
--------------------
Maintenant, regardons quels « business models » sont viables pour le logiciel
libre.
Pour gagner de l'argent, une boîte doit d'une part se protéger de ses
concurrents, et d'autre part s'en différencier.
Le gros problème lié à la commercialisation du logiciel libre (sous GPL),
c'est que quand vous livrez toutes vos sources, rien n'interdit à votre
concurrent de reprendre votre outil à son compte et de le vendre aussi. Votre
technologie n'est pas protégée. C'est agréable idéologiquement d'avoir un
logiciel en GPL, mais ça peut aussi vous faire perdre de l'argent si vous essayez de
le vendre.
La barrière à l'entrée que constitue la technologie est éliminée.
Voire même dans certains cas, elle est négative. Imaginons un gros
développement technologique qui soit livré sous GPL. Celui-ci coûte cher à son
auteur. Un nouvel entrant arrive. Tout ce qu'il a à faire, c'est récupérer le
développement fait gentiment par son concurrent, et le commercialiser. Comme
il économise sur les coûts de développement, il peut se permettre de dépenser
plus sur la commercialisation. Si le développeur original n'arrive pas à
capitaliser assez sur son expérience, il se sera fait injustement fait prendre
le fruit de ses efforts.
On a vu ça récemment avec le portage de Linux sur Itanium. Il a été fait à
quatre-vingts pourcents par Suse. Quand il fût fini, Redhat l'a recupéré, puis
packagé et vendu. C'est de l'argent facilement gagné par Redhat, facilement perdu
par Suse.
On a vu ça aussi avec la naissance de Mandrake. Au départ, Mandrake, ce
n'était qu'une Redhat pour laquelle on avait packagé Kde. Par la suite,
Mandrake a ajouté ses propres couches par dessus celles de Redhat, mais il n'en reste
pas moins que Mandrake a récuperé tout le travail de Redhat gratuitement.
Étant donné que les trois distributions se partagent aujourd'hui grosso modo
le marché à parts égales, on peut à peu près estimer de façon très simple que
Redhat a perdu cinquante pourcents de son marché.
Je vois souvent des gens critiquer le modèle du logiciel commercial en prônant
le tout-GPL. Mais il faut bien se rendre compte que dans bien des cas, le
modèle du tout-GPL n'est pas économiquement viable.
Ce qu'il faut voir, c'est d'où provient le revenu d'une société :
1. la vente d'un produit logiciel
2. la vente d'un service basé sur un logiciel
3. la vente d'une bibliothèque logicielle
Avec des développements propriétaires, les trois modèles peuvent être viables.
Attention, le modèle 1, c'est uniquement la vente d'un produit fini sans
service. Sinon, c'est le modèle 2.
Avec du logiciel GPL:
- Le 1 n'est pas viable. Votre concurrent n'aura qu'à recuperer tout votre
développement pour le vendre à votre place. Vous ne pouvez pas capitaliser
sur votre expérience puisqu'elle est déjà incluse dans votre produit. Vous
pouvez uniquement jouer sur votre image et votre relation client, ce qui
est très risqué comme unique moyen de sécuriser une position sur un marché.
On est dans le cas d'une barrière à l'entrée negative, c'est-à-dire qu'un
nouvel entrant intelligent est en meilleur position que vous, puisqu'il
recupère vos développements sans les payer.
- Le 2 est le modèle souvent prôné dans le logiciel libre. Ce sont ceux qui ont
développe le logiciel libre qui vendent du service dessus. Ils peuvent
capitaliser sur leur expérience et n'ont qu'à développer leur relation
client. En général, ça marche bien si on trouve des clients. Cependant, un
concurrent peut toujours arriver, acquérir de
l'expérience et revendre le même service. C'est ce qu'il semble se passer
dans l'affaire MySql. Si le marché trop petit, le simple fait de le
segmenter peut suffire à tuer les deux acteurs.
- Le 3 est en général viable. Avec une bibliothèque logicielle, toute entreprise
raisonnable achète du support. Comme votre bibliotheque est en GPL,
l'entreprise utilisatrice devra mettre son produit en GPL et si c'est un
produit qu'elle vend, elle ne le voudra probablement pas (parce qu'elle ne veut
pas se retrouver dans le cas 1. Donc elle achètera une licence commerciale
qui coûte cher et vous gagnerez de l'argent. C'est le modèle choisi par
Trolltech pour Qt et par l'ex-Cygnus pour Cygwin [1]. Le risque est que votre
bibliothèque soit utilisée pour un produit interne, auquel cas la GPL peut
convenir et vos clients ne vous achètent rien.
Si vous vendez votre bibliothèque en LGPL, vous vous retrouvez dans le cas 1
(donc très risqué), avec le seul espoir de vendre du service dessus. Si vous
vous retrouvez à vendre du service sur votre bibliothèque, c'est d'une part
qu'elle est difficile à utiliser donc pas géniale, d'autre part que vous êtes
dans le cas 2.
Une petite remarque tout de même. Je parle de modèle viable et non viable. On
va sûrement m'exhiber des sociétés vivant du modèle 1, alors que je viens
de le décrire comme non viable. Le terme viable ici est à prendre dans le sens
« viable à long terme », c'est-à-dire « qui ne risque pas de disparaître ». On
peut faire de l'argent en étant dans le modèle 1 pendant des années sans avoir
de soucis. Mais le jour où quelqu'un se rend compte qu'il peut se faire de
l'argent facilement avec votre technologie, vous êtes grillés. Le risque est
important. Notamment, si vous commencez à gagner beaucoup d'argent, des petits
malins vont vouloir vous en prendre et vous devriez éviter de leur donner
votre technologie.
Il y a un cas qui n'est pas traité dans cette brève présentation, c'est quand
une entreprise récupère un logiciel GPL développé bénevolement et le
commercialise. Certes, elle peut s'accomoder du modèle GPL, mais si le logiciel
est un produit, elle se retrouve dans la situation 1. Comme toute entreprise
n'aime pas prendre de risques, même quand elle n'a pas payé le developpement,
elle va plutôt essayer de récupérer les développeurs sous son aile de façon à
pouvoir changer la licence. C'est ce qui s'est passe en ce moment pour TuxRacer.
C'est ce qui est en train de se passer pour Quanta (et cela ne fait pas la joie de
tout le monde, cf http://dot.kde.org/995743381/995776534/(...)) et pour deux ou trois
autres produits de The Kompany.
Du point de vue d'un développeur libre, on est rarement content quand un
« fork » se produit, c'est-à-dire qu'un autre projet démarre à partir de votre
projet. Mais quand on est une société et qu'un concurrent récupère votre
produit principal, c'est un risque de faillite donc c'est très grave. Tout ce
qui permet de s'en prémunir est bon.
IV: Conclusions
----------------
C'est pour ça que je pense que si une société veut vendre TuxRacer sans
prendre de risque inutile, elle ne doit pas le releaser sous GPL. Certains ont
imaginé que l'on pourrait garder le moteur en GPL et ne vendre que les
graphismes. Mais le risque reste encore trop important. Une societe
concurrente peut très bien payer une équipe de trois personnes pendant
trois mois pour refaire un jeu complet à partir du moteur et vous griller
sur votre marché. Donc il faut tout passer sous une licence commerciale.
Si les gens d'Id Software avaient mis son moteur 3D sous GPL, ils seraient
beaucoup beaucoup moins riches à l'heure actuelle. Peut-être même qu'ils
auraient coulé, à cause du manque à gagner.
Il y a à Paris une boîte dont j'ai oublié le nom qui est en train de
développer un jeu dont le moteur sera sous GPL mais pas les graphismes ou les
clients (je ne me souviens plus très bien des détails). Je leur envois tous
mes voeux de réussite, mais je crois qu'ils se placent dans une position très
dangereuse d'un point de vue de rentabilité de leur société.
Les implications de cette petite démonstration vont loin. Il n'y aura
jamais à mon avis de jeux sous Linux, développé par une société, en GPL. Un jeu
ça coûte très très cher à développer (une très bonne équipe de dix personnes
pendant trois ans, à plein temps) et une société ne peut se permettre de risquer
un tel investissement. Il n'y a que deux types de jeu sous Linux pour
l'instant. Ceux qui sont sous une licence commerciale payante et ceux,
purement GPL, qui sont developpés par des bénévoles. Ces derniers étant
réalisés par des personnes non payées, sur leur temps libre, ils ont beaucoup
de mal à atteindre en qualité et en diversité les logiciels commerciaux. Le
travail d'une équipe pendant dix personne pendant trois ans, c'est dur à récuperer
sur ses week-ends et ses soirées [2].
Personellement, je rêve depuis longtemps d'être payé pour developper un
logiciel sous GPL. La découverte de ce que je viens de vous exposer m'a
fichu un coup. Alors, le GPL (à part pour mettre dans les voitures), ça sert à
rien ? En tout cas, ça ne peux pas rapporter d'argent ?
Ce qui est sûr, c'est que vendre un produit et le développer sous GPL est
incompatible. Ce qui reste possible, c'est vendre une bibliothèque sous GPL
(Bravo Trolltech !) ou vendre des services basés sur des logiciels GPL (Vive
Zope !).
Pour une société, il est également très intéressant d'utiliser des logiciels
GPL s'ils fournissent les même fonctionnalités que des logiciels payants, ça
coûte moins cher. Et si les logiciels ne sont pas tout à fait a niveau, ça
peut même être super rentable de payer les développeurs pour qu'ils
rajoutent ce qu'il faut, plutôt que d'acheter ce qui manque. En fait, c'est
un des modèles les plus intéressants pour une société. Si elle a un besoin
qu'elle pourrait couvrir par un développement, qui n'a rien à voir
avec ce dont elle tire son revenu, elle a tout interêt à s'associer avec
d'autres qui ont le même besoin et à payer une petite équipe pour faire ça en
GPL. C'est cela qui a donné naissance à Apache et à d'autres logiciels serveurs
très utilises.
Et puis si une societe montée par des fans de logiciel libre vend un produit
sous licence commercial qui marche bien, ça peut lui permettre de faire du
logiciel libre _par ailleurs_.
Je vous invite tous à réflechir à la demarche de Suse. Oui, leur outil
d'installation n'est pas sous GPL. Oui, il est interdit de copier une Suse.
Oui, elle n'est pas disponible gratos sur le net pour l'install. Mais du coup,
il n'est pas possible de faire à Suse ce que Mandrake a fait à Redhat. Suse
possède réellement sa distribution. Et certes, elle ne donne pas ses outils de
config. Mais elle est une des distributions qui paye le plus de developpeurs.
Je n'ai pas la liste detaillée, mais Suse paye au moins deux developpeurs de
XFree, tout le projet alsa, quatre ou cinq développeurs sur le noyau
Linux, cinq développeurs pour Kde, un développeur pour Gnome, des développeurs sur
la libc. Donc quand on dit que Suse ne redonne pas à la communaute, je ne suis
pas du tout d'accord. Payer des développeurs, ça me parait autrement plus
productif et utile que de mettre HardDrake sous GPL.
---
1: Et oui, peu de gens le savent mais il est écrit je ne sais plus ou que
comme la libc patchée et utilisée par cygwin est en GPL, tout programme produit
avec cygwin gcc est en GPL. Pour faire du propriétaire avec, vous devez payez
une licence de 10000 dollars !
2: Cela dit, on voit des jeux magnifiques arriver en GPL. Comme d'une part
l'industrie du jeu peine à apporter de nouveaux concepts, et d'autre part les
jeux en GPL peuvent se réutiliser les uns les autres, on va peut-être finir
par avoir un jeu de qualité commerciale sous GPL.
# « Traduction »
Posté par Anonyme . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 2.
sans accent, à vrai dire, ça n'est plus du français. Mais plutôt que d'être critique, je préfère être constructif, ainsi j'ai accentué
et corrigé le texte, en essayant de rester le plus possible à la philosophie du texte. Je pense monsieur Penso que ça serait sympa d'en faire la version « officielle » en virant les corrections qui ne te plaisent pas. Ci dessous le texte corrigé:
La nouvelle du changement de licence de TuxRacer m'a poussé à mettre par
écrit quelques petites réflexions sur la GPL, le logiciel libre et l'économie,
que je voudrais partager avec vous. C'est un peu long et c'est sans accents
(parce que ca va beaucoup plus vite à taper comme ca, je prie humblement les
lecteurs que cela gêne de m'excuser
-> NdT: ça me gêne alors qu'on maltraite ainsi notre si belle langue et de plus
sans accent, ça peut porter à confusion. Alors j'ai fais une petite traduction,
en essayant de respecter le texte original tout à fait brilliant, envoyez-moi
les corrections à cgillot@free.fr si par hazard une faute se serait
malencontreusement introduite...).
J'espère que ça éclairera mieux certains comportements.
I- barrière à l'entrée
----------------------
Dans l'économie normale, si on prend un marché donné où il y a un certain
nombre d'acteurs, tout nouvel entrant rencontre une barrière à l'entrée.
Les anciens possèdent une technologie mature, de l'expérience et une base de
clients, ce qui leur permet de vendre respectivement un produit, du service et
des partenariats. C'est la difficulté à obtenir la même technologie, la même
expérience ou les mêmes clients qui détermine la barrière a l'entrée.
La barrière à l'entrée est une chose importante car elle donne une stabilité à
l'écosysteme du marché. Pour être rentable une entreprise a en effet besoin de
pouvoir affirmer qu'elle possèdera une part de marché sur une période quelques
années. Pour une société technologique de taille moyenne, cinquante à deux cent
personnes, six ou sept ans constituent une période de rentabilité raisonnable.
Si la barrière à l'entrée est élevée, cela conduit à un monopole ou à un
oligopole. Les quelques acteurs dominants se partagent le marché, qui s'il
est large, peut être très juteux.
Si la barrière à l'entrée est très élevee, cela devient difficile de
s'installer même pour les leaders. C'est le cas par exemple de l'industrie des
console. Le coût de développement d'un jeu ou d'une console est tellement
élevé que même Sony et Nintendo ne sont jamais sûr de leur operations. Sega a
renoncé et Nintendo est en train de le faire.
Le marché de la téléphonie mobile troisième génération (UMTS) est un
autre exemple de marché nouveau avec une barrière à l'entrée très élevée.
Les coûts de licences et d'infrastructures sont tellement importants que
la rentabilité n'est pas assuré, même pour un oligopole (très peu d'acteurs
sur un marché).
Notons que dans ces deux cas (UMTS et consoles), on vend à des particuliers.
C'est un marché particulièrement difficile car le comportement des particuliers
est difficile a prévoir. Achètera, achetèra pas ?
Si la barrière à l'entrée est très faible, on obtient un marché volatile et
instable. Il y a beaucoup d'acteurs qui essaient de rentrer en permanence sur
le marché. Du coup, le marché devient extrêmement divisé et perturbé, la part
de chaque acteur devient très petite et aucun des acteurs n'est rentable.
Beaucoup de sociétés disparaissent. Ceux qui arrivent à survivre aux
phases initiales restent. Au fur et à mesure que les autres tombent ceux-là
stabilisent leurs parts de marché et leur position dominante. Au final, tout
nouvel entrant aura du mal à prendre une part de marché aux gros qui ont
réussi à survivre. Il y a donc après la stabilisation du marché une barrière
d'entrée qui s'est relevée.
C'est ce qu'on a vu pour les startups. Un marché en création, avec une
barrière a l'entrée extrêmement faible (un site web) et des bénéfices potentiels
élevés. Des centaines d'acteurs se sont rués naïvement dessus et ça a donné ce
qu'on a vu. En fait, on s'aperçoit que la barrière à l'entrée n'est pas si
faible puisqu'il faut fournir un réel service, puis que les revenus eux sont
très faibles (marge sur des achats, publicité, ça ramène pas lourd) et que
donc c'est un marché difficile. Un type intelligent disait qu'il y avait de la
place pour dix acteurs dans la publicité en ligne. C'est ce qu'on a
aujourd'hui, maintenant que le marché s'est stabilisé : yahoo, voila,
boursorama, spray, etc. La barrière a l'entrée est très élevée maintenant, parce
que les acteurs se sont établis et que les marges sont très faibles. On note
encore que là-aussi, c'est un business qui vend aux particuliers, donc
difficile à prévoir.
Ce que je veux faire comprendre, c'est que la barrière à l'entrée sur un
marché est quelque chose de capital pour le succès d'une entreprise. S'il n'y
a pas de barrière à l'entrée suffisamment elevée, les entreprises n'arrivent
pas à protéger leurs acquis et ne rentabilisent donc pas leurs
investissements. Elles disparaissent, l'économie devient morose, on licencie,
il y a des plans sociaux, bref, ça va mal.
II- Business model
------------------
Le business model, qui doit bien s'appeler quelque chose comme « modèle
d'affaire » en francais bien de chez nous, c'est le truc qui décrit comment
vous gagnez de l'argent. En general, quatre paramètres interviennent dans un
business model :
- ce que vous vendez : produit ou service
- combien ca coûte à faire : un logiciel à la con, ça prend six mois de dev à
deux. Un gros logiciel, c'est trois ans, voire plus, pour une équipe de dix
personnes. C'est ce qu'on retrouve pour de très gros logiciels d'entreprise
ou pour les jeux modernes.
- combien vous en vendez : évidemment, c'est important à savoir.
- à qui vous le vendez :
. Entreprises : c'est un marché previsible : elles achètent si ça leur fait
gagner du temps ou de l'argent (ce qui revient au même). Elles ont beaucoup
d'argent donc on peut éventuellement vendre très cher à un petit nombre de
clients privilégiés.
. Particuliers : c'est un marché relativement imprévisible. Le particulier
achète si ça lui plait et si ça coûte pas trop cher.
Si un outil est indispensable à une entreprise, elle est prête à le payer
cher. Donc on peut mettre une grosse équipe pendant trois ans sur un logiciel
qu'on est sûr ensuite de vendre à plusieurs centaines de milliers de francs ou à
plusieurs centaines de milliers d'exemplaires. Pour être sûr de le vendre, il
suffit de prouver à l'entreprise qui l'achète qu'elle va gagner de l'argent
avec.
L'avantage du marché des particuliers, c'est qu'il y en a beaucoup. On peut
donc vendre un logiciel pas cher à beaucoup d'unités pour rentabiliser un gros
et long developpement (typiquement, un gros jeu). Mais le marché des
particulier est assorti d'une incertitude, on n'est jamais sûr qu'ils vont
acheter.
Dans les deux cas que je viens de citer (gros développement), la valeur
ajoutée est sur la technologie. C'est une grosse techno qui coûte cher qu'on
vend. Celle-ci constitue la barrière avec le concurrent qui devra passer
beaucoup de temps pour en avoir une similaire.
On peut aussi vendre des logiciels à faible technologie, mais dans ce cas, il
n'y a pas de barrière technologique. Si on veut empêcher un concurrent de
prendre toutes les parts du marché, il faut trouver un autre type de barrière :
un très bon contact avec le client, une relation privilégiée, un partenariat,
des services spécifiques, une image, un bon réseau de distribution.
III- Logiciel libre.
--------------------
Maintenant, regardons quels « business models » sont viables pour le logiciel
libre.
Pour gagner de l'argent, une boîte doit d'une part se protéger de ses
concurrents, et d'autre part s'en différencier.
Le gros problème lié à la commercialisation du logiciel libre (sous GPL),
c'est que quand vous livrez toutes vos sources, rien n'interdit à votre
concurrent de reprendre votre outil à son compte et de le vendre aussi. Votre
technologie n'est pas protégée. C'est agréable idéologiquement d'avoir un
logiciel en GPL, mais ça peut aussi vous faire perdre de l'argent si vous essayez de
le vendre.
La barrière à l'entrée que constitue la technologie est éliminée.
Voire même dans certains cas, elle est négative. Imaginons un gros
développement technologique qui soit livré sous GPL. Celui-ci coûte cher à son
auteur. Un nouvel entrant arrive. Tout ce qu'il a à faire, c'est récupérer le
développement fait gentiment par son concurrent, et le commercialiser. Comme
il économise sur les coûts de développement, il peut se permettre de dépenser
plus sur la commercialisation. Si le développeur original n'arrive pas à
capitaliser assez sur son expérience, il se sera fait injustement fait prendre
le fruit de ses efforts.
On a vu ça récemment avec le portage de Linux sur Itanium. Il a été fait à
quatre-vingts pourcents par Suse. Quand il fût fini, Redhat l'a recupéré, puis
packagé et vendu. C'est de l'argent facilement gagné par Redhat, facilement perdu
par Suse.
On a vu ça aussi avec la naissance de Mandrake. Au départ, Mandrake, ce
n'était qu'une Redhat pour laquelle on avait packagé Kde. Par la suite,
Mandrake a ajouté ses propres couches par dessus celles de Redhat, mais il n'en reste
pas moins que Mandrake a récuperé tout le travail de Redhat gratuitement.
Étant donné que les trois distributions se partagent aujourd'hui grosso modo
le marché à parts égales, on peut à peu près estimer de façon très simple que
Redhat a perdu cinquante pourcents de son marché.
Je vois souvent des gens critiquer le modèle du logiciel commercial en prônant
le tout-GPL. Mais il faut bien se rendre compte que dans bien des cas, le
modèle du tout-GPL n'est pas économiquement viable.
Ce qu'il faut voir, c'est d'où provient le revenu d'une société :
1. la vente d'un produit logiciel
2. la vente d'un service basé sur un logiciel
3. la vente d'une bibliothèque logicielle
Avec des développements propriétaires, les trois modèles peuvent être viables.
Attention, le modèle 1, c'est uniquement la vente d'un produit fini sans
service. Sinon, c'est le modèle 2.
Avec du logiciel GPL:
- Le 1 n'est pas viable. Votre concurrent n'aura qu'à recuperer tout votre
développement pour le vendre à votre place. Vous ne pouvez pas capitaliser
sur votre expérience puisqu'elle est déjà incluse dans votre produit. Vous
pouvez uniquement jouer sur votre image et votre relation client, ce qui
est très risqué comme unique moyen de sécuriser une position sur un marché.
On est dans le cas d'une barrière à l'entrée negative, c'est-à-dire qu'un
nouvel entrant intelligent est en meilleur position que vous, puisqu'il
recupère vos développements sans les payer.
- Le 2 est le modèle souvent prôné dans le logiciel libre. Ce sont ceux qui ont
développe le logiciel libre qui vendent du service dessus. Ils peuvent
capitaliser sur leur expérience et n'ont qu'à développer leur relation
client. En général, ça marche bien si on trouve des clients. Cependant, un
concurrent peut toujours arriver, acquérir de
l'expérience et revendre le même service. C'est ce qu'il semble se passer
dans l'affaire MySql. Si le marché trop petit, le simple fait de le
segmenter peut suffire à tuer les deux acteurs.
- Le 3 est en général viable. Avec une bibliothèque logicielle, toute entreprise
raisonnable achète du support. Comme votre bibliotheque est en GPL,
l'entreprise utilisatrice devra mettre son produit en GPL et si c'est un
produit qu'elle vend, elle ne le voudra probablement pas (parce qu'elle ne veut
pas se retrouver dans le cas 1. Donc elle achètera une licence commerciale
qui coûte cher et vous gagnerez de l'argent. C'est le modèle choisi par
Trolltech pour Qt et par l'ex-Cygnus pour Cygwin [1]. Le risque est que votre
bibliothèque soit utilisée pour un produit interne, auquel cas la GPL peut
convenir et vos clients ne vous achètent rien.
Si vous vendez votre bibliothèque en LGPL, vous vous retrouvez dans le cas 1
(donc très risqué), avec le seul espoir de vendre du service dessus. Si vous
vous retrouvez à vendre du service sur votre bibliothèque, c'est d'une part
qu'elle est difficile à utiliser donc pas géniale, d'autre part que vous êtes
dans le cas 2.
Une petite remarque tout de même. Je parle de modèle viable et non viable. On
va sûrement m'exhiber des sociétés vivant du modèle 1, alors que je viens
de le décrire comme non viable. Le terme viable ici est à prendre dans le sens
« viable à long terme », c'est-à-dire « qui ne risque pas de disparaître ». On
peut faire de l'argent en étant dans le modèle 1 pendant des années sans avoir
de soucis. Mais le jour où quelqu'un se rend compte qu'il peut se faire de
l'argent facilement avec votre technologie, vous êtes grillés. Le risque est
important. Notamment, si vous commencez à gagner beaucoup d'argent, des petits
malins vont vouloir vous en prendre et vous devriez éviter de leur donner
votre technologie.
Il y a un cas qui n'est pas traité dans cette brève présentation, c'est quand
une entreprise récupère un logiciel GPL développé bénevolement et le
commercialise. Certes, elle peut s'accomoder du modèle GPL, mais si le logiciel
est un produit, elle se retrouve dans la situation 1. Comme toute entreprise
n'aime pas prendre de risques, même quand elle n'a pas payé le developpement,
elle va plutôt essayer de récupérer les développeurs sous son aile de façon à
pouvoir changer la licence. C'est ce qui s'est passe en ce moment pour TuxRacer.
C'est ce qui est en train de se passer pour Quanta (et cela ne fait pas la joie de
tout le monde, cf http://dot.kde.org/995743381/995776534/(...)) et pour deux ou trois
autres produits de The Kompany.
Du point de vue d'un développeur libre, on est rarement content quand un
« fork » se produit, c'est-à-dire qu'un autre projet démarre à partir de votre
projet. Mais quand on est une société et qu'un concurrent récupère votre
produit principal, c'est un risque de faillite donc c'est très grave. Tout ce
qui permet de s'en prémunir est bon.
IV: Conclusions
----------------
C'est pour ça que je pense que si une société veut vendre TuxRacer sans
prendre de risque inutile, elle ne doit pas le releaser sous GPL. Certains ont
imaginé que l'on pourrait garder le moteur en GPL et ne vendre que les
graphismes. Mais le risque reste encore trop important. Une societe
concurrente peut très bien payer une équipe de trois personnes pendant
trois mois pour refaire un jeu complet à partir du moteur et vous griller
sur votre marché. Donc il faut tout passer sous une licence commerciale.
Si les gens d'Id Software avaient mis son moteur 3D sous GPL, ils seraient
beaucoup beaucoup moins riches à l'heure actuelle. Peut-être même qu'ils
auraient coulé, à cause du manque à gagner.
Il y a à Paris une boîte dont j'ai oublié le nom qui est en train de
développer un jeu dont le moteur sera sous GPL mais pas les graphismes ou les
clients (je ne me souviens plus très bien des détails). Je leur envois tous
mes voeux de réussite, mais je crois qu'ils se placent dans une position très
dangereuse d'un point de vue de rentabilité de leur société.
Les implications de cette petite démonstration vont loin. Il n'y aura
jamais à mon avis de jeux sous Linux, développé par une société, en GPL. Un jeu
ça coûte très très cher à développer (une très bonne équipe de dix personnes
pendant trois ans, à plein temps) et une société ne peut se permettre de risquer
un tel investissement. Il n'y a que deux types de jeu sous Linux pour
l'instant. Ceux qui sont sous une licence commerciale payante et ceux,
purement GPL, qui sont developpés par des bénévoles. Ces derniers étant
réalisés par des personnes non payées, sur leur temps libre, ils ont beaucoup
de mal à atteindre en qualité et en diversité les logiciels commerciaux. Le
travail d'une équipe pendant dix personne pendant trois ans, c'est dur à récuperer
sur ses week-ends et ses soirées [2].
Personellement, je rêve depuis longtemps d'être payé pour developper un
logiciel sous GPL. La découverte de ce que je viens de vous exposer m'a
fichu un coup. Alors, le GPL (à part pour mettre dans les voitures), ça sert à
rien ? En tout cas, ça ne peux pas rapporter d'argent ?
Ce qui est sûr, c'est que vendre un produit et le développer sous GPL est
incompatible. Ce qui reste possible, c'est vendre une bibliothèque sous GPL
(Bravo Trolltech !) ou vendre des services basés sur des logiciels GPL (Vive
Zope !).
Pour une société, il est également très intéressant d'utiliser des logiciels
GPL s'ils fournissent les même fonctionnalités que des logiciels payants, ça
coûte moins cher. Et si les logiciels ne sont pas tout à fait a niveau, ça
peut même être super rentable de payer les développeurs pour qu'ils
rajoutent ce qu'il faut, plutôt que d'acheter ce qui manque. En fait, c'est
un des modèles les plus intéressants pour une société. Si elle a un besoin
qu'elle pourrait couvrir par un développement, qui n'a rien à voir
avec ce dont elle tire son revenu, elle a tout interêt à s'associer avec
d'autres qui ont le même besoin et à payer une petite équipe pour faire ça en
GPL. C'est cela qui a donné naissance à Apache et à d'autres logiciels serveurs
très utilises.
Et puis si une societe montée par des fans de logiciel libre vend un produit
sous licence commercial qui marche bien, ça peut lui permettre de faire du
logiciel libre _par ailleurs_.
Je vous invite tous à réflechir à la demarche de Suse. Oui, leur outil
d'installation n'est pas sous GPL. Oui, il est interdit de copier une Suse.
Oui, elle n'est pas disponible gratos sur le net pour l'install. Mais du coup,
il n'est pas possible de faire à Suse ce que Mandrake a fait à Redhat. Suse
possède réellement sa distribution. Et certes, elle ne donne pas ses outils de
config. Mais elle est une des distributions qui paye le plus de developpeurs.
Je n'ai pas la liste detaillée, mais Suse paye au moins deux developpeurs de
XFree, tout le projet alsa, quatre ou cinq développeurs sur le noyau
Linux, cinq développeurs pour Kde, un développeur pour Gnome, des développeurs sur
la libc. Donc quand on dit que Suse ne redonne pas à la communaute, je ne suis
pas du tout d'accord. Payer des développeurs, ça me parait autrement plus
productif et utile que de mettre HardDrake sous GPL.
---
1: Et oui, peu de gens le savent mais il est écrit je ne sais plus ou que
comme la libc patchée et utilisée par cygwin est en GPL, tout programme produit
avec cygwin gcc est en GPL. Pour faire du propriétaire avec, vous devez payez
une licence de 10000 dollars !
2: Cela dit, on voit des jeux magnifiques arriver en GPL. Comme d'une part
l'industrie du jeu peine à apporter de nouveaux concepts, et d'autre part les
jeux en GPL peuvent se réutiliser les uns les autres, on va peut-être finir
par avoir un jeu de qualité commerciale sous GPL.
Peut-être.
Quand on aura des scénaristes notamment.