Actualités

[22/03/2017] Smile vainqueur des IoT Awards 2017

Lors de l'IoT World à Paris, Smile a remporté l'IoT Award dans la catégorie "High-tech" pour son projet de cabine connectée avec Coved.

[17/03/2017] Smile dans le Journal de l'Emploi sur Demain TV

Géraldine Moreau-Luchaire, notre Responsable Recrutement, nous parle des 350 postes à pourvoir en 2017 !

[14/03/2017] Smile devient partenaire officiel de Docker

Docker est une technologie de conteneurisation applicative open source phare. La plateforme permet de construire, déployer et exécuter des applications sous formes de modules.

Toutes les actualités picto
       

Top consultation

Logo Smile : Open Source Solutions

Guillemet ouvrant introduction
à l'open source Guillemet fermant

Business Model

Business Model

Ce qu’on appelle business model, ce sont les principes de fonctionnement qui assurent la rentabilité d’une société.

On peut étendre l’analyse aux organismes à but non lucratif en s’intéressant du moins à leurs revenus et charges.

La question est souvent posée par les néophytes incrédules : Mais si c’est gratuit, alors comment ça peut marcher, il faut bien que quelqu’un paye à un moment ?

Et de fait, tout n’est pas gratuit dans l’open source, et il y a une vraie économie de l’open source, qui a ses particularités.

Nous étudions ici les 4 typologies d’acteurs de l’open source :

  • Fondations

A l’image de la fondation Apache, ou Eclipse, ce sont des organismes à but non lucratif, qui stimulent et pilotent le développement de grands produits open source.

  • Distributeurs

A la manière de Redhat ou Mandriva, ils sélectionnent des outils et composants autour d’un noyau Linux, en assurent le packaging, la distribution et le support.

  • Editeurs

Ils créent un produit logiciel, qu’ils diffusent sous licence open source, en tout ou partie. Ils assurent la promotion de leur produit, et proposent des offres de support.

  • Prestataires

Les prestataires de l’open source vendent des services, que ce soit dans un mode de régie ou de forfait. On peut distinguer des prestataires de support et des prestataires intégrateurs.

Les fondations

Les fondations et autres organismes à but non lucratif tiennent une place très importante dans l’écosystème de l’open source.

Les plus grands produits open source, et ceux qui ont la plus large diffusion, sont issus de ces fondations, ou bien repris en charge par celles-ci.

La Free Software Foundation, déjà évoquée plus haut pour sa définition du logiciel libre et des licences GNU GPL et ses missions de défense et de promotion du logiciel libre, continue de jouer un rôle clé dans le développement des composants du GNU Project qui sont associés au noyau Linux.

Voyons quelques unes des autres grandes fondations.

Apache

Le serveur Http Apache est le produit fondateur de la fondation éponyme. Il remonte aux tous débuts du web, soit 1995, où quelques développeurs réunis au sein de l’Apache Group entreprennent d’améliorer le premier Httpd du NCSA, comme alternative aux outils de Sun et Netscape. A partir de 1996 et jusqu’à aujourd’hui, le serveur Apache est le plus utilisé sur le web.

La Apache Software Foundation (ASF) est une association à but non lucratif de droit américain, et l’un des temples de l’open source. Dans le paysage de l’open source, c’est la seule entité qui ait à la fois les moyens de pousser des projets nombreux et d’envergure, et qui ne soit pas à la recherche d’un business model.

Du fait de cette vocation non commerciale, l’ASF est motivée à donner naissance à des projets de qualité, qui puissent être utilisés librement par le plus grand nombre. C’est aussi cette caractéristique qui amène des entreprises ou développeurs à donner des programmes à l’ASF.

Les programmes des projets Apache appartiennent à l’ASF, qui les diffuse sous licence APL, une licence non-copyleft.

La fondation Apache est financée par quelques sponsors, et tire de petits revenus de l’organisation de séminaires, vente de goodies et dons en ligne. Mais en fait, la fondation a surtout un tout petit budget.

Sur son bilan 2005-2006, elle déclare des recettes de 150 K$, dont 95 K$ de dons et 50 K$ de revenus de ses services, répartis entre recettes des conférences Apache (environ 30 K$) et des Codes Awards (20 K$).

Les dépenses, sur la même période, ne sont que de 33 K$, dont 28 consacrés à la mission principale de la fondation de diffuser ses logiciels open source au public gratuitement, c’est à dire principalement des coûts d’hébergement et d’exploitation.

On constate donc que les flux financiers sont minuscules, comparés à la puissance effective de la fondation dans sa mission de promotion et de développement de grandes applications open source.

L’avancement des projets est surtout basé sur le volontariat, mais également sur les dons en nature que peuvent faire des entreprises en autorisant certains de leurs développeurs à travailler sur des projets Apache sur leur temps de travail, pour une période convenue. Des accords spécifiques permettent d’assurer que le fruit de ce travail est propriété de l’ASF.

Il y a une bonne cinquantaine de projets Apache, dont la notoriété, la diffusion et la qualité sont variées. Dans l’ensemble, une caractéristique commune est d’avoir une architecture logicielle solide, basée sur des standards.

Citons quelques-uns de ces produits : Apache Httpd, Perl, Lucene, Tomcat, Ant, Cocoon, Lenya, OfBiz, Struts, et bien d’autres, ...

Eclipse

Eclipse est une initiative qui réunit de grandes sociétés informatiques, à l’initiative d’IBM, pour développer initialement une plateforme de développement intégrée (IDE, Integrated Development Environment), du même nom.

Le mouvement change de statuts en 2004 pour devenir fondation Eclipse, association à but non lucratif (non profit organization).

La mission de l’organisation est de créer et promouvoir un ensemble d’outils de conception, développement et gestion de programmes, ainsi que des composants et frameworks.

L’intérêt stratégique, pour IBM, est de contrer la plateforme Microsoft dans les entreprises. En effet, la qualité des outils de développement tient une part importante dans l’adoption d’une plateforme par les développeurs, et les outils de développement Java étaient souvent jugés moins bien intégrés et moins ergonomiques que ceux de Microsoft.

La fondation est financée par ses membres, de grandes sociétés proches de l’informatiques (IBM, Intel, BEA, Motorola, Nokia, Oracle, SAP, Zend, ...). Elle dispose de salariés pour des missions administratives, mais les développeurs sont des programmeurs indépendants, ou bien travaillant pour des entreprises qui leur accordent du temps pour participer à ces projets.

La fondation fournit 4 services à la communauté Eclipse :

  • une infrastructure matérielle qui héberge les travaux,
  • un cadre juridique pour les questions de propriété intellectuelle,
  • des processus pour le développement communautaire,
  • et la promotion et facilitation des projets au sein de l’écosystème.

Les distributeurs

Les distributeurs sont des sociétés comme Redhat, Ubuntu, Mandriva, Suse et quelques autres, dont l’activité est de :

  • Sélectionner des produits et versions, entourant le noyau Linux.
  • Valider la maturité et la robustesse de ces produits.
  • Distribuer ces produits et leurs mises à jour, c’est à dire assurer leur acheminement jusqu’aux utilisateurs-clients.
  • Assurer le support de ces produits : hot-line, traitement des demandes, conseil, formation.

Initialement, dans les années 90, le moyen de distribution privilégié était la disquette puis le CD-ROM, et la principale activité des distributeurs était le gravage et la distribution des CDs. Aujourd’hui, la diffusion est majoritairement online, et le cœur de métier des distributeurs s’est déplacé pour se centrer sur le support.

Les distributeurs distribuent essentiellement des produits dont ils ne sont pas détenteurs des droits. Ils n’ont donc pas le choix de proposer telle ou telle licence, ou bien une licence GPL et une licence commerciale comme le font certains éditeurs : c’est le détenteur des droits qui décide de la licence. Les distributeurs open source diffusent une majorité de produits sous GPL, et quelques produits sous BSD ou d’autres licences.

Certains sont aussi éditeurs de quelques produits de leur distribution.

Redhat

Fondé en 1994, Redhat domine de très loin ce marché, avec près de 300 M$ de chiffre d’affaire et 2200 employés dans le monde. Pour beaucoup d’entreprises, en particulier aux Etats-Unis, Redhat a donné sa crédibilité à l’open source. Redhat est aussi un des plus importants contributeurs du noyau Linux, et est également éditeur de produits open source, au premier rang desquels figure le serveur d’application JBoss, acquis en 2006, ou des outils tels que Hibernate.

Le support est disponible par abonnement (subscription), payé annuellement. Le prix dépend du périmètre de produits concernés, et du niveau de service. Au catalogue Redhat, ce support peut aller de $350 à $2500, par an et par serveur. Le modèle est donc par construction très récurrent. A noter que le contrat de support inclut une clause de « Intellectual Property protection », une assurance juridique qui protège le client d’éventuelles actions d’éventuels détenteurs de brevets. Une clause très prisée aux Etats-Unis.

Les souscriptions représentent 82% des revenus de Redhat, le reste provenant des prestations de formations et conseil. Du coté des coûts on peut identifier, sans connaître la part de chacun :

  • Les coûts habituels d’une société commerciale : services généraux, RH, services commerciaux, marketing. A noter que les coûts de commerce et marketing représentent 36% du chiffre d’affaire, et les autres coûts administratifs, 20%.
  • Les coûts associés aux prestations de support : hot-line, experts, consultants
  • Les coûts des développeurs contribuant aux produits open source distribués, ou recherche et développement : 18% environ.

Au total, le résultat net de Redhat pour l’année 2006 est d’environ 80 M$, soit une rentabilité de 28%, ce qui est excellent, au niveau des grands éditeurs traditionnels.

Mandriva

Si Redhat affiche une santé éclatante, les distributeurs Linux français ont connu au contraire des années difficiles. Anciennement Mandrakesoft, la société diffuse et supporte depuis 1998, la distribution Mandriva Linux, qui a accédé au ‘top 10’ des distributions au plan mondial.

Introduite en bourse en 2001, la société a un parcours mouvementé, traversant un redressement judiciaire en 2003, parvenant à quelques résultats positifs en 2004 avant de replonger dans le rouge. Sur le dernier exercice connu, 2006-2007, le chiffre d’affaire est de 4,2 M€ et la perte d’exploitation de 2,3 M€.

Mandriva est éditeur de produits en propre : la solution de gestion de parc informatique Pulse 2.0, et le serveur Ldap Mandriva Directory Server.

L’offre de support sur la distribution entreprise « Corporate server 4 » est constituée d’un forfait de maintenance annuel de 279€ par an par serveur, et de tickets de support de 50 € par incident.

Debian

Même si elle ne vise pas un semblable business model, il faut ici une mention spéciale pour Debian, une distribution Linux non-commerciale, la plus ancienne, la plus communautaire et finalement la plus proche des valeurs fondatrices de l’open source. C’est aussi la seconde distribution Linux la plus utilisée.

Projet fondé par Ian Murdock (aujourd’hui chez SUN), en 1993, il se caractérise par les Debian Free Software Guidelines, énoncées en 96 (qui inspireront l’Open Source Definition), et son système de gestion des packages. En 2007-08, le Debian Project Leader est français, il s’agit de Sam Hocevar, ancien élève de l’école Centrale et important contributeur du projet VideoLAN.

Les éditeurs open source

Editeur open source

L’éditeur, c’est celui qui détient les droits du produit, en assure le développement, la promotion, la diffusion et le support.

Dans un premier temps, les seuls acteurs commerciaux de l’open source étaient des distributeurs plus que des éditeurs, l’acteur emblématique étant Redhat.

C’est MySql qui a ouvert la voie de la logique de l’éditeur open source, et depuis quelques années, ce modèle a donné naissance à de nombreux nouveaux acteurs, particulièrement dynamiques.

Les éditeurs open source sont des sociétés commerciales ordinaires, c’est à dire à but lucratif. Comme un éditeur ordinaire, elles investissent massivement dans le développement de leur produit, et parfois également dans sa promotion, son marketing. La seule différence est que le produit est diffusé sous licence open source, ou parfois sous double licence.

Pourquoi choisissent-ils ce modèle ? Au delà de l’adhésion aux valeurs de l’open source, ils font sans doute l’analyse que l’open source est devenu le seul moyen de percer dans un marché prisonnier de quelques oligopoles. Un peu à la manière des compagnies aériennes low-cost, ces nouveaux acteurs amènent un business model légèrement différent, de nature à casser les positions acquises.

Si la finalité économique est très semblable, ces nouveaux acteurs ont néanmoins des caractéristiques spécifiques par rapport aux éditeurs classiques. En premier lieu, ce sont de petites structures, de très petites structures en comparaison des éditeurs en place. MySql, c’est 360 employés. Et leurs forces sont presque entièrement tournées vers le développement et le support du produit. Elles font peu de marketing, peu de commerce. Comme les compagnies low-cost, elles ont structurellement des coûts très inférieurs, ce qui leur permet de vivre avec de faibles revenus.

Business model de l’éditeur open source

Les éditeurs open source ont trois types de revenus :

  • Ventes de licences.
  • Vente de support.
  • Vente de prestations.

Auxquels s’ajoutent dans certains cas des revenus issus de leurs intégrateurs partenaires : partenariat payant pour certains, ou commission sur l’apport d’affaires, lorsque des prospects sont dirigés vers des partenaires.

Et bien sûr, au chapitre des dépenses, on trouve :

  • Le développement produit.
  • Le support.
  • Le commerce et le marketing.

Les éditeurs bénéficient aussi de l’open source au niveau des coûts : en pouvant s’appuyer sur l’extraordinaire patrimoine de code déjà disponible sous licence open source, ils font d’importantes économies de développement.

Vente de licence

« Vendre des licences » et « open source » semble une contradiction. Effectivement, même si ce n’est pas interdit, aucun éditeur ne vendrait une simple licence GPL.

Mais il y a plusieurs cas de figure de double licences possibles :

1. Sortir de la GPL

Le premier est une licence non open source, propriétaire donc, qui permet au client de ne pas être tenu par les obligations de la licence GPL. En particulier si le client veut distribuer une œuvre dérivée utilisant le programme, et ne souhaite pas diffuser ses sources, il lui faudra acquérir une licence commerciale. Des éditeurs comme eZ Systems ou MySql ont choisi ce modèle.

Pour des applicatifs de haut niveau, par exemple le CMS eZ Publish, ce n’est en général pas une source de revenus importante car la finalité est de faire un site et rarement de faire un produit. Mais dans le cas de MySql, la vente de licences représente plus de la moitié du CA.

2. Modules complémentaires payants

Le second cas de figure est celui où l’éditeur propose des modules complémentaires à l’application principale, ces modules étant exclusivement sous licence commerciale. Selon les cas, la partie open source pourra être plus ou moins complète. Mais si elle est trop légère, et donne l’impression d’être un simple appât pour ferrer le pigeon, elle sera rejetée. Si l’application open source est de qualité, et que les modules payants sont optionnels, le modèle peut tenir la route. On peut citer Talend et Pentaho, comme éditeurs ayant choisi ce modèle. eZ Systems, qui proposait quelques modules payants, a renoncé à ce modèle, pour une meilleure lisibilité de l’offre.

3. Dépendance entre le support et la licence

Le troisième cas est celui où l’éditeur crée une dépendance entre son offre de support et la licence commerciale. Dans ce cas l’éditeur ne propose aucun support, même payant, sur la version open source. Pour avoir du support, il est nécessaire de choisir la licence commerciale. C’est le cas de l’éditeur Alfresco.

Vente de support

Le support est la principale source de revenus pour la majorité des éditeurs open source. Les offres de support sont le plus souvent sur la base d’une souscription annuelle, par instance du produit, par serveur ou par processeur.

Le support inclut en général :

  • Un accès privilégié aux correctifs, et à des ressources spécifiques.
  • La prise en charge des problèmes, que ce soit anomalies ou problèmes d’utilisation ou de mise en œuvre.
  • Eventuellement des prestations d’audit, de certification, ou de prise de contrôle à distance, surveillance proactive et corrections.

Correctifs

Les éditeurs peuvent être tentés de maintenir un écart entre le niveau de correctif des clients sous support et le référentiel de sources public. Mais ils ne jouent pas trop là dessus, car c’est quand même la réputation de leur produit qui se joue sur la version open source. En revanche, les clients sous support reçoivent les correctifs en ‘push’, sans les avoir demandés.

Le contrat de support peut inclure également l’accès à certaines ressources privilégiées : forums, base de connaissances, mailing lists, voire même documentation. Mais là aussi, ne pas diffuser librement de documentation est en général plutôt pénalisant. Il faut se souvenir que les libres utilisations sont aussi des produits d’appel pour l’utilisation en conditions critiques, qui demandera du support.

Résolution de problèmes

Beaucoup de contrats de support distinguent différents niveaux, en termes de :

  • Nombre de problèmes sur l’année.
  • Temps de réaction sur problème.
  • Horaires d’ouverture de la hot-line.
  • Garantie de correction.
  • Prise de contrôle

La relation avec le support est en général de type web ou mail pour les contrats basiques, et téléphonique pour les contrats haut de gamme.

Prestations

Enfin, les éditeurs peuvent également proposer des prestations autour de leurs produits, dont ils sont nécessairement les meilleurs experts : conseil, audit, définition d’architecture, analyse de problèmes, formations.

Ces prestations sont également proposées par les prestataires intégrateurs, de sorte qu’une ligne de partage est en général trouvée :

  • L’éditeur assure les prestations qui requièrent la plus grande expertise, et sont peu liées au contexte spécifique du client.
  • L’intégrateur assure les prestations de proximité, liées à un déploiement et un environnement spécifique.

Dans certains cas, les clients peuvent également financer des développement du produit qui visent à mieux couvrir son besoin spécifique, mais pourront être utiles à d’autres clients, et donc être intégrés au produit.

Trois éditeurs open source

MySql

MySql A.B. est une entreprise suédoise, éditeur de la base de données du même nom.

En 1994, il n’existait pas de base de données relationnelle légère, et encore moins open source. Depuis 1990, il existait déjà Postgres, créé par Michael Stonebraker, déjà fondateur de Ingres. Mais à cette époque, Postgres n’utilisait pas SQL mais QUEL comme langage de requête.

Dans l’année 1994, Hughes, un étudiant australien, réalise pour Postgres un traducteur de requête de SQL vers QUEL, puis il finit par réécrire la couche de stockage, en simplifiant au maximum les fonctionnalités. Son projet s’appelle mSql, et il acquiert rapidement une belle notoriété.

En 1995, Michael Widenius, de la société suédoise TcX ajoute une interface SQL compatible avec mSql sur le moteur de base de données maison Unireg. Dès le début, la société adopte un modèle d’éditeur open source, ce qui crée rapidement une vague d’adhésion et de contributions.

Ce n’est toutefois qu’en 2000 que MySql passera sous licence GPL. Jusqu’à cette date, une licence spécifique excluait les plateformes Windows et interdisait à qui que ce soit de proposer un support payant. En fait une telle licence ne passe pas les critères de l’open source definition.

MySql AB compte 360 employés et a réalisé un chiffre d’affaire de 40M$ en 2006. Il faut bien mesurer à quel point ce sont des chiffres minuscules au regard des grands éditeurs traditionnels. Oracle compte 68 000 employés et un chiffre d’affaires de 17 Md$. C’est à dire 400 fois plus.

En 2004, avec la version 4, MySql a modifié ses conditions de licence, les connecteurs permettant à des programmes d’accéder à la base, sont passés de la licence LGPL à la GPL. Les implications sont très fortes. En effet, le fait qu’un programme appelle une base de données n’implique pas qu’il soit « construit sur » la base de données, au sens de la licence GPL. A priori donc, un programme peut utiliser en tant que serveur une base MySql sous GPL, sans tomber sous les obligations de la licence GPL. Mais pour réaliser cet appel, les applications utiliseront le plus souvent le connecteur fourni par MySql. Ainsi, en mettant les connecteurs sous licence GPL et non LGPL, MySql vise à propager aux applications utilisant son serveur les implications de la GPL, et de cette manière pousser davantage de clients vers ses licences non open source.

C’est pourquoi ce changement de politique commerciale a été mal vécu dans les communautés open source. Les développeurs de PHP en particulier ont invoqué l’incompatibilité entre la licence utilisée pour PHP. Pour y répondre, MySql a ajouté une clause particulier, la « FOSS exception », et l’armistice a été conclue avec la communauté PHP.

Enfin, en janvier 2008, SUN a acheté MySql pour environ 1 milliard de dollars, de l’ordre de 20 années de chiffre d’affaire. Le deal a été vu comme une prise de conscience, de la part des acteurs traditionnels, de la montée en puissance des éditeurs open source.

MySql vend son produit MySQL Enterprise, qui est essentiellement une offre de service. Les services relèvent principalement du support, de l’audit et du conseil.

L’offre de service est dissociée de la nature de la licence : elle concerne par défaut les programmes diffusés sous licence GPL, mais le client peut à son choix utiliser la licence commerciale, au même prix.

Sur son site, MySql énonce le principe général que l’utilisation de la base dans le contexte d’une organisation commerciale devrait être sous licence commerciale. L’autorisation de diffuser au sein d’une même organisation sans nécessité de rendre publiques les sources, n’est pas évoquée, mais elle découle de la licence GPL.

eZ Systems

eZ Publish est un outil de gestion de contenus (CMS) écrit par Bård Farstad en 1999 et diffusé sous GPL à partir de 2000. Le produit est d’entrée de jeu mieux conçu qu’une majorité des applications PHP, surtout de cette époque. Il adopte rapidement une modélisation objet, et une couche d’abstraction permettant de travailler avec n’importe quelle base de données.

Comme pour MySql, les revenus des premières années viennent surtout de l’intégration du produit dans ses propres projets, sur son marché local, la Norvège. En 2002, le produit a déjà une reconnaissance mondiale, et l’on parle déjà de « killer application du PHP » !

A partir de 2004, eZ Systems s’implante dans différents pays européens, puis aux Etats-Unis.

En 2006, eZ Systems met en open source les quelques composants associés au CMS, qui ne l’étaient pas. En avril 2007, eZ Systems lève 5 M$ de capitaux auprès d’investisseurs norvégiens, ce qui lui permettra certainement un élan nouveau vers son but de devenir le système de gestion de contenus de référence, y compris pour les plus grandes entreprises.

Le business model de eZ Systems est fondamentalement basé sur le support, avec des offres silver, gold, et platinum, qui se distinguent par le nombre de tickets d’incidents inclus, et le temps de prise en compte, pour des prix allant de $6990 à $13990.

Alfresco

Alfresco est fondé en 2005 par des anciens dirigeants de Documentum et de Business Objects, qui amènent avec eux des architectes de grands éditeurs, et des capitaux importants. Alfresco est donc le parfait exemple de la nouvelle génération d’éditeurs open source.

La première génération d’éditeurs open source avaient en général commencé à l’université ou dans leur garage, et s’étaient imposés petit à petit en construisant une communauté. Au contraire, Alfresco a directement les moyens de financer une équipe de haut vol, tant en développement qu’en marketing, et se fait reconnaître en à peine deux ans, comme un grand acteur sur son marché, celui de la Gestion Electronique de Documents (GED), typiquement un marché sclérosé entre les mains de quelques grands acteurs vieillissants.

Alfresco diffuse son produit de GED sous deux licences :

  • Une version Community, sous licence GPL.
  • Une version Enterprise, sous licence commerciale.
  • Alfresco ne propose pas de support, même payant, pour la version community, tandis que la version Enterprise au contraire, est indissociable de son support, sur un mode de souscription annuelle, par serveur.

En termes de licences, il est intéressant de noter que Alfresco a commencé par utiliser une licence issue de la MPL (Mozilla), avec une clause spéciale obligeant à présenter un message d’avertissement sur toutes les pages de l’application. Début 2007, Alfresco est passé sous licence GPL pour la version community, ici aussi pour une meilleure lisibilité de la politique open source.

Alfresco précise clairement dans sa FAQ qu’un déploiement au sein de son organisation, n’est pas considérée comme une distribution, ce que tous les éditeurs ne disent pas aussi clairement.

La version community est modifiée au fil de l’eau, tandis que la version enterprise est l’objet de releases trimestrielles validées.

A noter également que le contrat de partenariat que Alfresco signe avec ses intégrateurs leur fait interdiction d’intégrer la version community, de sorte qu’il est difficile pour les utilisateurs de cette version d’obtenir un support professionnel.

Loi des grands nombres

Pour prospérer, les éditeurs open source doivent être dans une logique de grands nombres, à la manière de MySql : le fait que 10 millions d’utilisateurs ne payent rien à MySql AB n’est pas problématique si sur ce nombre, il en reste 10 000 qui ont des utilisations suffisamment stratégiques, et souhaiteront disposer d’un support d’éditeur, avec délai d’intervention garanti.

Le pourcentage de clients qui feront appel au support éditeur dépend de la typologie de produit. Pour un produit grand public, par exemple un antivirus open source, il sera bien difficile de faire payer du support à beaucoup, ou de vendre sa version payante. Pour un produit dont la vocation est fortement B2B, par exemple une Gestion Electronique de Documents, la part des clients demandeurs de support sera naturellement plus grande.

Contributions communautaires

Les éditeurs open source comptent en général assez peu sur les apports communautaires, du moins sur le cœur de leur produit. Ils les acceptent car c’est dans la logique de l’open source, mais ne les encouragent guère et l’on peut penser qu’il ne leur déplait pas de garder la maîtrise de leur produit.

A noter que si son morceau de code est accepté, le contributeur devra généralement signer un accord spécifique qui permet à l’éditeur de disposer librement de son code. C’est assez naturel, car si chaque contributeur pouvait spécifier ses propres conditions de licence, le produit final serait un enchevêtrement de licences indémêlables.

Afin de bénéficier d’une dynamique communautaire, tout en conservant la maîtrise du noyau de leur produit, certains éditeurs mettent en place un dispositif d’extensions, qui permet d’apporter des enrichissements au produit, de manière propre et indépendante du noyau, en assurant la compatibilité avec les versions futures.

Noyau, extensions et ecosystème

Le modèle qui semble le plus efficace, et le meilleur compromis, est celui qui distingue le noyau du produit, sous la responsabilité de l’éditeur, et les extensions, réalisées par des contributeurs externes.

Les principes de cette séparation sont les suivants :

  • Le noyau doit être d’une grande robustesse, il est certifié par l’éditeur ; les contributions externes y sont rares.
  • L’interface entre le noyau et les extensions est bien documentée et stable, c’est à dire qu’un changement de version du noyau n’implique pas un changement de version des extensions.
  • L’éditeur stimule la réalisation d’extensions, car elles donnent de la valeur à son produit et témoignent aussi de l’existence d’une communauté, en soi une garantie de pérennité. L’éditeur offre en général une plateforme de mise à disposition des extensions. Il peut le cas échéant mettre en place un dispositif d’évaluation ou de certification des extensions.

Ce modèle noyau/extensions est celui qui réalise le meilleur point d’équilibre entre les rôles respectifs de l’éditeur et de la communauté, réunissant la garantie et l’engagement de l’éditeur, avec le dynamisme et le l’énorme capacité de développement de la communauté.

Les « Forks »

On appelle « fork » une scission dans un projet de développement, dans laquelle une nouvelle équipe de développement part de la même base logicielle pour faire évoluer le produit à sa manière.

Les licences open source autorisent toutes les forks, c’est dans la définition même de l’open source.

Il peut y avoir en gros deux raisons pour un fork : un désaccord quant aux orientations technologiques, ou bien un désaccord quant à la politique commerciale et de licences.

Ainsi, si un éditeur prend une orientation qui déplait à la communauté, il s’expose à un fork. Par exemple en 2006, l’ERP Adempiere, naît d’un fork de Compiere résultant d’une politique commerciale tournant le dos aux communautés, suite à l’entrée d’investisseurs dans Compiere Inc.

Autre exemple fameux, le fork donnant naissance à Joomla en 2005, à partir de Mambo, un outil de gestion de contenus très populaire.

Selon les cas, le fork peut l’emporter ou bien vivoter, selon le dynamisme de la communauté. Il y a aussi des forks non pas communautaires mais d’entreprises commerciales, par exemple l’ERP OpenBravo, s’appuyant également sur Compiere comme socle de son développement.

Le fork est une épée de Damoclès au dessus de la tête de l’éditeur, qui l’oblige à rester fidèle à ses valeurs et à sa communauté. Mais à contrario, certains éditeurs peuvent aussi en conclure qu’il vaut mieux éviter qu’il existe une réelle maîtrise de leur noyau dans les communautés.

Protection légale & Propriété Intellectuelle

Aux Etats-Unis en particulier, les éditeurs proposent, en association avec leurs offres de support, une protection légale vis à vis de possibles violations de brevets logiciels. Dans ce pays, une entreprise qui utiliserait des programmes violant des brevets pourrait se voire attaquer et réclamer des indemnisations potentiellement énormes si la compagnie est riche.

C’est devenu, ces dernières années, l’un des axes d’attaque les plus virulents des concurrents de l’open source, à commencer par Microsoft, qui a utilisé son accord avec Novell pour entretenir l’idée qu’il existe un risque à cet égard. Et paradoxalement, ces intimidations servent aussi les éditeurs open source commerciaux, qui vendent finalement de la protection légale autant que du support produit.

En Europe toutefois, les programmes informatiques sont explicitement exclus de la Convention sur le Brevet Européen, et d’une manière le recours au judiciaire est moins dans les mœurs, de sorte qu’il n’y a pas de crainte semblable.

Editeur-intégrateur

Le marché informatique se divise depuis longtemps entre éditeurs et intégrateurs. Les éditeurs développent des produits, susceptibles de satisfaire un nombre important de clients. Les intégrateurs s’appuient sur ces produits pour construire des systèmes d’information répondant au besoin spécifique d’un de leurs clients.

De tout temps, open source ou pas, il s’est trouvé des prestataires tentés par le double jeu : éditeur et intégrateur à la fois, éditeur qui intègre lui-même son produit, intégrateur qui n’a qu’un seul produit à son catalogue. Et de tout temps, cela n’a pas marché. Parce que pour gagner des marchés, l’éditeur doit construire un réseau d’intégrateurs partenaires, et il ne peut y parvenir s’il est lui même le premier concurrent de ses propres intégrateurs.

Sur le marché des solutions open source, on rencontre fréquemment de tels éditeurs-intégrateurs, mais ils ne donnent jamais naissance à des solutions leaders. La tentation est grande, pour l’éditeur qui a du mal à trouver son business model, et du mal aussi à convaincre des prestataires d’utiliser son produit, de le faire lui-même. Mais le marché sanctionne toujours ces combinaisons.

Les prestataires

Pour les prestataires IT, intégrateurs de solutions open source, le business model est pratiquement inchangé, basé sur la vente de prestations et d’expertise autour des produits open source, ceci sous la forme :

  • de support,
  • de projets clés en main,
  • de prestations de conseil ou d’expertise en assistance technique.

Nous distinguons ici deux types d’activités, auxquelles correspondent des prestataires souvent différents : le support open source et l’intégration open source.

Les prestataires de support open source

Nous avons distingué ici distributeurs et prestataires, même si les distributeurs sont prestataires, à leur manière. Mais d’un point de vue historique, la frontière reste marquée. Les distributeurs n’offrent aucune autre prestation que la diffusion, le support et la formation, autour des logiciels inclus dans leur "distribution". Sur ces composants, sur le noyau Linux en particulier, ils ont une expertise pratiquement irremplaçable.

Mais il existe une telle diversité de composants open source, que le besoin est apparu très tôt d’avoir un support global, concentré entre les mains d’un prestataire unique. C’est sur ce métier qu’est né en France le concept de SSLL, Société de Service en Logiciel Libre : une société qui se propose d’assurer le déploiement et le support de configurations multi-produits à base de logiciels open source. Elles ont été rejointes plus tard par les SSII généralistes, ouvrant des centres de support open source.

Les prestataires de support open source, tels que Linagora par exemple, peuvent également construire des applications spécifiques, mais leur cœur de métier est dans le support, par exemple de produits prêts à l’emploi tels que la suite Open Office.

L’intégration de solutions open source

Les prestataires intégrateurs de solutions open source – tels que Smile – construisent des applications globales, des systèmes d’information, à base de logiciel open source.

Bien sûr, ils assurent également le support de l’ensemble de leurs créations, incluant les développements et configurations spécifiques, et produits sous-jacents, mais leur cœur de métier est dans l’intégration, la construction d’applications.

La valeur ajoutée de l’intégrateur open source commence dans le choix de solutions. L’open source amène une immense profusion de solutions, dont certaines immatures, ou au contraire obsolètes. Cette richesse est aussi un handicap : beaucoup de clients craignent de faire un mauvais choix. L’intégrateur open source ne peut pas attendre que le Gartner ait sélectionné les heureux élus, il doit mener une action permanente de veille et d’évaluation, afin de déceler les produits prometteurs, et les produits les plus solides.

Après cela, un projet d’intégration de systèmes à base d’open source ressemble à un projet d’intégration en général, et demande la même expertise méthodologique, tant en développement qu’en conduite de projets.

Au chapitre consacré au modèle de développement, nous verrons que l’open source a aussi beaucoup fait progresser le développement, et les prestataires intégrateurs sont les premiers à faire usage des bonnes pratiques, mais aussi des bons outils, issus de l’open source : IDE, gestion des sources, outils de tests et d’intégration continue, suivi des anomalies, etc. Les intégrateurs open source ont, en la matière, une longueur d’avance.

Prestation open source et prestation traditionnelle

Les produits open source communautaires n’ont pas d’éditeur susceptible d’apporter une aide commerciale ou marketing, un support à l’avant-vente, ou un support en phase de projet. Même pour les produits open source commerciaux, les éditeurs sont souvent de petites structures, aux ressources limitées, et plutôt tournées vers le développement produit.

Le prestataire prend donc souvent à sa charge une partie de l’investissement amont qui incombait traditionnellement à l’éditeur : il sélectionne les produits les plus solides et pérennes, en assure la promotion et la vente, voire une partie du support.

Devant l’extraordinaire montée en puissance des solutions open source, tous les prestataires IT espèrent une part du gâteau ; c’est ainsi que les grandes SSII généralistes ont fini par s’y intéresser. Mais elles ont beaucoup de difficulté à trahir les grands éditeurs traditionnels, ‘propriétaires’ avec lesquels elles vivent en symbiose depuis des années, dans une logique de licences-chères/prestations-chères. N’investissant pas en amont dans la veille technologique et la relation avec les communautés ou éditeurs open source, elles manquent de légitimité sur ces territoires nouveaux.

Synthèse

En guise de synthèse, nous analysons les relations entre ces différents acteurs de l’open source, en considérant trois types d’interactions, en forme de flux :

  • Les prestations, y compris écriture de programmes, support, conseil, formation, intégration.
  • Le code source, c’est à dire les logiciels.
  • L’argent, enfin, qui fait de tout cela un business-model !

Les flux de prestations

Sur la figure suivante, nous représentons les flux de prestations intellectuelle entre les différents acteurs identifiés. Cette prestation peut être du développement de programme, ou bien de l’intégration, du conseil, du support, de la formation.

synthese_flux_de_prestations

On distingue les principaux flux de service :

  • Contributions en prestations de développeurs salariés, de la part des distributeurs tels que Redhat, de donateurs tels que IBM ou Google, et dans une moindre mesure, d’éditeurs commerciaux et d’intégrateurs, au bénéfice des fondations tels que Apache qui ont en charge de grands projets open source.
  • Offre de prestations d’intégration, développement et support des intégrateurs et des éditeurs commerciaux, vers les clients et utilisateurs finaux.

Les flux de code source

Sur la figure suivante, nous avons fait apparaître les flux de code source. Pour le distinguer de la prestation de développement, qui relevait des flux précédents, on ne considère ici que la livraison de programmes déjà écrits.

synthese_flux_de_code_source

Ici, les principaux flux sont :

  • Le code source constituant les grands logiciels open source, diffusés par les fondations et utilisés par les éditeurs commerciaux, et par les intégrateurs.
  • Les programmes distribués par les distributeurs, à destination des clients finaux.
  • Les programmes des éditeurs commerciaux, à destination des clients.

Les flux d’argent

Enfin, cette dernière figure représente les flux d’argent entre ces différents acteurs.

synthese_flux_argent

On y distingue les principaux flux suivants :

  • Le paiement par les clients finaux des prestations de support aux éditeurs commerciaux et aux distributeurs.
  • Le paiement par les clients finaux des prestations d’intégration et de support aux intégrateurs.