L’Open core un modèle à éviter ?

closeCet article a été publié il y a 11 ans 3 mois 16 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Open core, voici un terme que je vois revenir régulièrement dans les articles de la presse informatique numérique anglo-saxone. D’où vient cette expression, quelle réalité recouvre-t-elle et qu’apporte-t-elle à l’open source ?

L’apparition de ce terme semble relativement récente. Sa paternité pourrait être attribuée à Andrew Lampitt qui décrit dans cet article paru en août 2008 ce que serait l’open core ou plus exactement son modèle économique.

L’idée de l’auteur est de lever l’ambiguïté qui s’est développée autour du modèle dit de double licence proposé par certains éditeurs commerciaux open source. Il faut en effet différencier les offres de type double licence :

  • Le modèle MySQL pour lequel il n’y a pas de différence de fonctionnalités entre la version open source et la version commerciale. La version commerciale doit être utilisée si l’on souhaite inclure la base de données dans un logiciel à code fermé.
  • Vient ensuite le modèle SugarCRM dans lequel la version commercial apporte des fonctionnalités supplémentaires par rapport à la version open source. C’est une caractéristique que l’on retrouve chez d’autres logiciels comme Zimbra.

Ces deux types d’offre présentée toutes les deux comme open source peuvent entraîner une confusion et laisser à penser qu’il y aurait plusieurs définitions de l’open source. Or il n’existe qu’une seule définition donnée par l’OSI (Open Source Initiative). Mais il y a plusieurs modèles économiques. C’est la différence de ces modèles que veut tenter d’éclaircir Andrew Lampitt. Celui de l’open core correspondrait à la description suivante :

  • Le « core » est la base du logiciel. Il est sous licence GPL. Si vous encapsulez cette base dans un programme fermé, vous devez payer une licence commerciale,
  • Le support technique pour le logiciel GPL peut-être payant,
  • Les abonnements commerciaux annuels incluent : indemnités, support technique et des fonctions additionnelles (le code source de ces fonctions additionnelles est ouvert ou fermé). Ces fonctions peuvent éventuellement intégrer le coeur GPL au bout d’une certaine période)
  • Les services d’intégration et de formation sont payants.

Le schéma suivant illustre le principe de ce modèle :

Open core licensing business model

Crédit image certains droits réservés par Roebot

Quelle utilité pour ce terme ?

Si la pertinence de la définition ne se pose pas vraiment, car elle permet de mettre un nom sur une pratique de certains éditeurs de logiciel, son utilité peut faire débat.

Tout d’abord, il est probable qu’il ne sera presque jamais utilisé dans le discours marketing des éditeurs. Le terme open est affaibli par la notion de « core » ou de coeur qui met trop en avant le fait que tout n’est pas ouvert. Une approche qui pourrait faire fuir certains clients potentiels. Mais en cela il n’y a pas de certitudes.

Ce terme supplémentaire risque de ne pas aider à la compréhension des utilisateurs venant à l’open source quand on leur dira qu’il y a plusieurs famille d’éditeurs dans cette famille. Les consultants en logiciels open source ont encore de beaux jours devant eux pour expliquer tout cela à leurs clients.

L’open core est-il à recommander ?

L’open core est probablement à rapprocher de la notion de fauxpen source. J’aurais personnellement tendance à me méfier de ces éditeurs et à les déconseiller. Un point que l’on peut cependant modérer en tenant compte des fonctionnalités disponibles. Certains logiciels open core comme Zimbra fournissent déjà des solutions très évoluées dans leurs versions « de base ».

L’approche open core ne facilite pas non plus le développement d’une communauté de développeurs actifs autour du logiciel. Sans communauté, l’éditeur est tout de même à la merci d’un « prédateur » façon ORACLE qui pourra alors se contenter de retirer les développeurs du projet causant ainsi la disparition d’un concurrent. Les conséquences pour l’utilisateur sont évidentes.

Sans communauté, il ne peut y avoir de poursuite du projet. Le code source dans le cas de l’open core n’est disponible que de façon partielle. Le salut pour l’utilisateur ne peut venir que d’une reprise du projet par un autre éditeur.

La boucle semble alors bouclée, l’utilisateur est prisonnier d’un éditeur pour autant que les fonctions dont il a besoin ne soient accessibles que dans la version commerciale. Et quand bien même l’utilisateur se contenterait de la version « de base », la probabilité de voir apparaître un fork sur ce type de projet est fortement abaissée.

Sur le même sujet :

[Source]

Illustration Certains droits réservés par Monica’s Dad

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

5 réponses

  1. Sylvain dit :

    Bonjour Philippe

    Voilà un article très intéressant qui a le mérite d’ouvrir le débat sur l’open-core et le « dual-licensing ».

    Personnellement, je me suis interrogé plusieurs fois sur mon blog à ce sujet, plus particulièrement dans le domaine des solutions décisionnelles open source (OSBI). Pour les éditeurs BI open source actuels (JasperSoft, Pentaho, Actuate, Talend, Jedox, SpagoBI…), les différences sont importantes au niveau des Business Models, ceux-ci ayant en plus une certaine tendance à évoluer de façon sensible dans le temps… !

    A mon sens, il convient donc surtout de se poser les questions suivantes dans l’évaluation d’un modèle « open source commercial ». (vous noterez d’ailleurs qu’on y retrouve plusieurs points de votre article)

    1/ La solution open source en question répond-elle de façon globale à mes besoins fonctionnels ainsi qu’à mes contraintes et exigences techniques ?

    2/ Existe-t’il suffisamment de documentation disponible me permettant de monter en compétence et d’acquérir une autonomie suffisante sur l’outil (wiki, forums, blogs, livres) ou avec un accompagnement minimal (assistance,formation) ?
    Bref, la solution me permet-elle d’obtenir un degré d’autonomie certain ?
    Un très bon indicateur est la présence (ou non) d’une communauté importante, visible et active autour du projet est le nombre de contributions de toute nature : fonctionnalités additionnelles (plugins, composants greffons), groupes de traduction, articles techniques sur des blogs ou des forums, etc.

    Comme vous l’indiquez, une solution open source ne doit jamais rendre captif et dépendante d’un éditeur ou d’un intégrateur (sinon il faut se poser quelques questions et se tourner vers des solutions propriétaires non ?)

    3/ La solution est est-elle modulaire ?
    Puis-je facilement faire cohabiter cette solution avec une autre solution open source, ou si besoin enrichir cette solution via un développement spécifique ?
    La méthode d’enrichissement a-t’elle été rendue possible nativement dans la solution de base (API, framework de développement, mécanisme de plugin) ?

    4/ Quel est le degré d’ouverture de la solution ?
    Quel sont les différences entre la version gratuite (« community ») et la version professionnelle payante (« enterprise ») ?
    L’écart fonctionnel est-il important ?
    Ou se situent les différences ?
    Y’a-t’il un vrai et grand écart fonctionnel (très gênant) ou bien les différences se situent-elles plutôt au niveau de l’amélioration de la productivité à grande échelle (moins gênant, la version pro est clairement dans ce cas destinée aux grands comptes)

    Enfin, pour mon(mes) projet(s), ai-je nécessairement besoin de la version PROFESSIONNELLE pour bénéficier des fonctionnalités complémentaires et du support éditeur ?
    Sinon, existe-t’il des composants open source gratuits permettant de combler les éventuels manques fonctionnels de la version libre ?

    Une fois que vous aurez répondu à toutes ces questions, vous pourrez déjà avoir une bonne idée de ce qui est utilisable en « mode open source »
    Et dans l’OSBI, ce n’est pas toujours défavorable à l’open core (ou pas !)…

    Bref, ça nécessite une bonne connaissance des solutions 🙂

    Sylvain – http://www.osbi.fr

  2. Bernard Réveillault dit :

    Bien d’accord avec la conclusion

    Mais pas pour ce passage
    Ce terme supplémentaire risque de ne pas aider à la compréhension des utilisateurs venant à l’open source quand on leur dira qu’il y a plusieurs famille d’éditeurs dans cette famille. Les consultants en logiciels open source ont encore de beaux jours devant eux pour expliquer tout cela à leurs clients.

    Pour avoir mené une étude sur les outils BI Open source
    l’open core y est légion et trier l’open source façon Talend, BIRT, Jasper, SpagoBI, Vanilla,..
    m’a demandé un certains temps
    Avoir des termes différents pour différencier ces modèles
    permet faire le trie dans  » ce fourre tout » Open Source qui abrite des réalités bien différentes

    Cordialement

  3. Philippe dit :

    @Sylvain : merci pour la contribution au sujet.
    @Bernard : Content de voir passer par ici ! Je vois que tu ne t’ennuies pas 😉 . Oui le terme open core permet de mettre un mot sur une pratique. Le problème c’est qu’au fond tu n’es guère plus avancé car il y a encore open core et open core comme le montre bien Sylvain. Personnellement je préfère les représentations plus visuelle comme celle qui avait été présentée dans cet article. Peut-être que ça aurait pu t’aider à classer les solutions.

  4. Bernard Réveillault dit :

    Merci pour ce lien qui reprend en beaucoup mieux les idées que j’ai essayé d’expliquer entre BPM-Conseil (Vanilla), Actuate (BIRT), JasperSoft (JasperReport), Eng.it (SpagoBI), Talend et d’autres

    Force est de constater que leur modèle économique engage de toute manière vers une dépendance à un éditeur et l’open source pour l’ensemble de ces cas est très loin de l’idée qu’on peu s’en faire

    Postgresql est très loin ! ! !

  1. 27 octobre 2010

    […] This post was mentioned on Twitter by Philippe Scoffoni and Ronan, Louis Roché. Louis Roché said: http://philippe.scoffoni.net/open-core-modele-a-eviter/ L’Open core un modèle à éviter ? […]