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

Cet article a été publié il y a 13 ans 6 mois 2 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 :

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 :

• Nagios : de l’open source à l’open core ?

[Source]

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