Avec l’arrivée des nouveaux éditeurs, le métier de la prestation Open Source est en pleine mutation. Le modèle historique, basé sur l’offre de support perd de sa pertinence. Quel avenir pour les sociétés de services centrées sur ce segment ?
Produits Open Source commerciaux
Pourquoi ?
Faut-il s’en réjouir ? Est-ce une bonne chose pour l’Open Source ?
Pour certains, les acteurs économiques de l’Open Source seront toujours suspectes, qu’ils soient éditeurs ou prestataires d’ailleurs. Mais ici, comme Richard Stallman l’avait analysé il y a 20 ans déjà, ce qui compte vraiment, c’est la licence ; peu importent les motivations de l’éditeur, du moment que le code est bien libre. Et c’est bien le cas, puisqu’une majorité de ces nouveaux acteurs choisissent la licence GPL, qui a le mérite d’être sans ambiguïté.
Et les prestataires, alors ?
Ce changement du côté de l’offre de produits logiciels Open Source amène également un changement du côté des prestataires.
En France, le modèle de la SSLL, Société de services en logiciel libre, s’est construit en premier lieu sur une offre d’expertise et de support des logiciels libres. On sait que le support communautaire faisait peur aux entreprises, tant par son absence de contractualisation, que par la multiplicité de ses intervenants. Le besoin d’un interlocuteur responsable était manifeste, et les premières SSLL se sont posées en intermédiaires, assurant le support de niveaux 1 et 2 sur une diversité de composants, et gérant le niveau 3 en coordination avec les différentes communautés.
Or aujourd’hui, une part croissante des composants provient de ces nouveaux éditeurs Open Source. Le support de leurs produits étant la base de leur business model, ils voient d’un très mauvais oeil ces prestataires qui voudraient leur prendre leur gagne pain. De plus, indépendamment de l’aspect business, ils ont évidemment une capacité et une légitimité supérieures à corriger leurs propres bugs. Et pour que les choses soient claires, même si n’importe qui a le droit de corriger un programme en GPL, une version du produit patchée par un tiers n’est en général plus supportée par l’éditeur.
Le support, du haut en bas de la pile
Il reste quand même à traiter le support du bas de la pile. On appelle “pile logicielle” l’ensemble des composants constituant une plate-forme logicielle. Par exemple, de bas en haut : Linux, Apache, PHP, progiciel, extensions et configuration.
Dans cette pile, les composants du bas, validés par des millions de déploiements, sont d’une robustesse extrême. Plus on remonte dans la pile, plus on est dans du spécifique, plus la base d’utilisateurs est réduite, et donc plus la possibilité d’anomalies et le besoin de support sont grands.
A tel point que certains utilisateurs seraient prêts à faire l’impasse sur le support du bas de la pile. Leur besoin central est d’avoir un bon support sur le produit qu’ils ont déployé, et sur les développements spécifiques de leur prestataire. Et à la rigueur, si leur support de niveau 2 leur dit que tel problème relève d’un bug Apache, ils compteront sur lui pour le contourner, ou proposer une version nouvelle. Ces clients se tourneront soit vers le support de l’éditeur soit vers leur prestataire intégrateur, mais non vers un support généraliste.
Au final, la situation est la suivante : sur les couches hautes, intégrateurs et éditeurs Open Source revendiquent le support, tandis que sur les couches basses, le besoin de support est sensiblement plus faible.
Le business model du prestataire de support Open Source, qui était le modèle fondateur des SSLL, a du plomb dans l’aile. Alors, restera-t-il une place pour les prestataire Open Source ? Hors du seul support, deux voies sont ouvertes.
L’éditeur-intégrateur
La première est celle de l’éditeur-intégrateur. Intégrateur de son propre produit, éditeur qui n’a que lui-même comme intégrateur. Pour l’éditeur, la prestation d’intégration c’est la perspective de revenus immédiats. Pour l’intégrateur, tenir un rôle d’éditeur c’est une visibilité très forte, et l’espoir de valorisations importantes. C’est donc un modèle tentant, de part et d’autre, mais ce peut être un piège également.
Le métier d’éditeur est un métier à fort investissement, à forte prise de risques et fort potentiel de gains. Mais le métier d’éditeur Open Source est bien plus dur encore, car il ne devient rentable qu’avec de très grands volumes, c’est-à-dire donc une position de leader mondial sur son domaine. La contrepartie, c’est qu’avec l’Open Source il est possible de devenir leader mondial en 18 mois, si l’on a un produit excellent. Mais du moins, dans le monde du logiciel propriétaire, un petit éditeur peut survivre ; pas dans le monde du libre.
L’éditeur qui ne peut pas vivre de son seul produit, de son offre de support ou de ses licences ‘entreprise’ payantes, ayant besoin de financement, sera tenté d’assurer lui-même la prestation sur son produit. Mais faisant cela, il se place en concurrent de tous ses possibles intégrateurs, et aura donc beaucoup de difficultés à construire son réseau, obligatoire pour un déploiement mondial.
A bien y regarder, en réalité, une majorité des éditeurs Open Source leaders d’aujourd’hui ont en fait vécu à leurs débuts comme intégrateurs de leur propre produit, dans leur propre pays. Citons par exemple MySql, eZpublish ou TinyERP. C’est au moment de quitter leur marché local pour partir à l’attaque du reste du monde qu’ils ont dû se recentrer sur leur strict métier d’éditeur. Le business model de l’éditeur-intégrateur peut être une étape transitoire, le palliatif d’un manque de capitaux d’amorçage. Au delà, il devient une voie sans issue.
Alors, restera-t-il une place pour les prestataire Open Source ?
Il reste bien sûr le métier d’intégrateur Open Source. L’intégrateur Open Source est celui qui construit une expertise sur une diversité de solutions, est capable non seulement de les déployer et de les configurer, mais aussi de construire de véritables plates-formes, de véritables systèmes d’information à base d’une diversité de composants. Et bien entendu, assure le support de ce qu’il a construit.
Intégrateur Open Source, un métier banalisé ?
L’intégration de solutions Open Source est-il déjà un métier banalisé ? Y a-t-il une différence fondamentale entre intégrateur tout court et intégrateur Open Source ? Après tout, il arrive aussi aux SSII généralistes d’intégrer des composants Open Source. Le feraient-elles moins bien ?
La vache à lait, et le dilemme de l’innovateur
Une première analyse est que, à chaque révolution, qu’elle porte sur la technologie ou le modèle économique, les acteurs en place sont devant un dilemme inextricable que l’on peut résumer à “peut-on se permettre de tuer la vache à lait historique ?”.
Le phénomène est connu, et a été parfaitement analysé, dès 1997, par C. Christensen dans The Innovator’s Dilemma. Compagnies aériennes traditionnelles contre compagnies low-cost, opérateurs téléphoniques historiques contre nouveaux entrants triple-play, mais aussi IBM contre Microsoft, et maintenant Microsoft face à Google. Pour attaquer le nouveaux marchés issus de la rupture, il faudrait tuer la poule aux oeufs d’or du marché ancien, où l’on est en position dominante.
L’opposition libre vs propriétaire, pour les intégrateurs, est du même acabit : un intégrateur traditionnel ne peut pas renoncer à la manne qu’il tire du logiciel propriétaire, ses licences chères, ses prix de jour élevés et ses fortes marges. C’est pourquoi l’intégrateur généraliste pourra faire de l’Open Source de manière opportuniste, mais privilégiera les solutions propriétaires chaque fois qu’il aura les mains libres.