Les extensions, arme fatale des solutions Open Source

Coût, liberté, respect des standards, ouverture… Les atouts des solutions Open Source sont bien connus, mais il est une force toute particulière de ces produits qui est moins connue et pourtant déterminante: le modèle noyau-extensions.

Coût, liberté, respect des standards, ouverture, ... les atouts des solutions open source sont bien connus, mais il est une force toute particulière de ces produits qui est moins connue et pourtant déterminante: le modèle noyau-extensions, massivement adopté par les éditeurs de solutions open source. En quoi consiste ce modèle ? C'est à la fois un modèle d'architecture, un modèle économique et un modèle d'écosystème.

Un modèle d'architecture
En termes d'architecture logicielle, il s'agit simplement d'identifier un programme noyau offrant un premier niveau de services, et de mettre en place des points d'attache permettant d'y intégrer des extensions, qui apporteront des fonctionnalités supplémentaires, ou adapteront des fonctionnalités d'origine. Plus ces points de branchement d'extensions sont nombreux, plus le programme offre de possibilités d'extensions.

Au niveau technique, ce modèle a de nombreux bénéfices. Il permet en particulier de ne pas faire grossir inutilement le programme. On sait que version après version, sous la pression de la concurrence, les programmes intègrent de plus en plus de fonctionnalités, pas toutes nécessaires, qui les font grossir jusqu'à l'obésité. Cet embonpoint pèse sur les coûts de développement et de maintenance, voire même sur les performances, et peut nuire aussi à la facilité d'utilisation. Comme pour les systèmes d'exploitation, la solution est dans la flexibilité, et le modèle noyau-extensions permet à chacun d'installer les extensions correspondant à son besoin, sans pour autant alourdir le programme pour tous. Firefox est un des précurseurs du modèle, et un excellent exemple de l'équilibre que permet un noyau léger, associé à la richesse fonctionnelle des extensions.

Sur le plan technique toujours, le modèle noyau-extensions a un autre avantage important: il permet de modifier des fonctionnalités sans modifier du code source du noyau. Modifier le code source d'un programme pour l'adapter à son besoin est une opération délicate, qui peut déstabiliser le produit, mais surtout, qui sera à réintégrer manuellement aux versions suivantes du produit. Le modèle noyau-extensions offre la même flexibilité que la modification de code, mais dans une approche plus structurée, et traitant mieux les problèmes de montée de versions, puisque le plus souvent, les extensions restent compatibles avec une nouvelle version du produit.

Un modèle d'écosystème
Mais le modèle noyau-extensions joue un rôle fondamental également dans la bonne cohabitation entre l'éditeur d'un produit et son écosystème.

Les licences Open Source permettent à chacun de modifier le code source d'un programme. Mais on sait bien que ce n'est pas toujours une bonne idée, et en particulier c'est une chose à éviter s'il s'agit uniquement d'adapter un produit à son seul besoin. La seule bonne manière de modifier le code d'un produit Open Source est de s'impliquer dans la communauté, ce qui suppose d'une part d'avoir l'expertise requise pour être accepté comme commiter, et d'autre part que les commiters tiers soient bienvenus.

Le modèle noyau-extensions lève cette barrière, il permet à chacun d'enrichir un produit en écrivant ses propres extensions, sans modifier le code d'origine. Selon les cas, ces extensions peuvent ajouter une petite fonctionnalité en se branchant sur une API, mais elles peuvent aussi redéfinir entièrement une classe, et donc une fonctionnalité existante.

Pour les éditeurs Open Source, le modèle noyau-extensions a donc un bénéfice important: il permet de tracer une frontière entre le domaine de l'éditeur et le domaine de la communauté. Le noyau, c'est l'éditeur, les extensions, c'est le terrain de la communauté et des intégrateurs. L'éditeur s'engage sur la stabilité du noyau, avec des équipes compactes et structurées, tandis que différents acteurs de l'écosystème enrichissent le produit par des extensions.

La frontière existe aussi en termes de propriété intellectuelle. Lorsque des tiers contribuent directement à son programme, l'éditeur s'assure en général que chaque contributeur lui cède la propriété de ses travaux en signant un contributor licence agreement, car il ne veut pas que la propriété du programme soit parcellisée, ce qui rendrait difficile un changement de licence. Mais cette disposition juridique complique la contribution, tandis que la contribution au moyen d'extensions n'a pas cette contrainte.

Un modèle économique : la place de marché
Un des aspects les plus intéressants du modèle est la naissance de véritables bourses d'échange, des référentiels permettant de rechercher et de télécharger des extensions. Les éditeurs ont bien compris l'importance des extensions, et stimulent l'offre en mettant en place ces plates-formes d'échange, avec classement thématique, outils de recherche, mais aussi dans certains cas, des commentaires d'utilisateurs, voire des notations. Ils permettent souvent de classer les extensions par niveau de popularité, selon le nombre de téléchargements. Community managers, developper days, tutoriaux, promotion des meilleures extensions... nombreuses sont les actions stimulant le modèle.

Les extensions sont d'origines diverses, toutes ne sont pas de qualité irréprochable, et c'est le savoir-faire de l'intégrateur que de sélectionner les meilleures extensions, en scrutant les forums mais aussi en menant de véritables audits.

Il existe quelques variantes de ces plates-formes d'échange: dans certains cas, les extensions sont toutes gratuites, pour d'autres produits le gratuit cohabite avec le payant. De même certains éditeurs restent dans un rôle de facilitateur, tandis que d'autres mettent en place une certification qualité des extensions. Enfin pour certains, les extensions font partie du business model, l'éditeur prenant une commission sur chaque vente, à la manière de l'Appstore.

Un atout concurrentiel
Dans une logique ancienne, un éditeur pourrait voir les extensions comme une petite part de valeur ajoutée qui lui échappe, qu'il pourrait revendiquer. Mais les éditeurs modernes ont bien compris que, au contraire, chaque extension, gratuite ou payante, l'enrichit en enrichissant son produit. Si son produit peut être enrichi par des centaines de programmeurs dans le monde sans qu'il n'ait rien à payer, il ne peut être que gagnant. Une sorte de variante du crowdsourcing, qui décuple la capacité de développement autour du produit.

Pour les utilisateurs, bien sûr, la quantité d'extensions disponibles est aussi l'assurance de trouver une réponse à un besoin particulier, prête à l'emploi, sans le moindre développement. Donc un facteur d'économie et de flexibilité. Mais, le nombre d'extensions est aussi devenu une mesure de la dynamique d'un produit, de sa popularité, de sa part de marché.

Et le propriétaire ?
En principe, ce modèle noyau-extensions n'est pas réservé aux produits Open Source, ni au plan technique, ni au plan des licences.  Le libre accès aux sources du produit facilite malgré tout la mise en place du modèle, mais ce n'est pas une condition nécessaire, et rien n'interdit à un éditeur propriétaire de mettre en place un tel schéma d'extensibilité. Pourtant ils sont peu nombreux à l'offrir, et lorsqu'ils le font, c'est à une échelle très différente. En fait, quelques éditeurs propriétaires sont également parvenus à embarquer des offres de tiers environnant leur produit, et peuvent aussi revendiquer une sorte d'écosystème. Mais généralement il ne s'agit pas de petites extensions, plutôt de développements d'envergure, et bien sûr, jamais gratuits. Ainsi il y a 25 extensions d'origine tierce annoncées sur le site de SAP, contre plusieurs milliers pour les solutions Open Source les plus actives.

Pourquoi ? Sans doutes en partie parce que l'éditeur revendique toute la création de valeur possible autour de son produit. Mais, la principale explication est plutôt du côté des clients et utilisateurs de ces produits. En effet, une grande majorité des extensions Open Source ne proviennent pas de l'investissement d'un éditeur tiers, mais d'un développement initialement réalisé pour un déploiement particulier, puis rendu générique et mis à disposition de tous. Or, le client d'une solution propriétaire n'est pas dans un logique de partage, il n'imagine pas qu'un développement fait pour lui, qu'il a chèrement payé, puisse être utilisé gratuitement par d'autres. Il s'attendrait à en tirer un bénéfice économique, mais comme son métier n'est pas l'édition de logiciel, ce serait trop compliqué, de sorte qu'il préfère simplement garder son petit développement pour lui.

A l'inverse, en tant qu'intégrateur de solution Open Source, nous constatons couramment que nos clients sont très ouverts à l'idée de partager leurs développements. Il y a même un véritable effet boule de neige: plus l'on a trouvé d'extensions utiles fournies par d'autres, plus on est disposé à en reverser.

Quelques exemples
Magento, une solution d'e-commerce Open Source très en vogue, compte plus de 2400 extensions, environ un tiers sont gratuites, les autres ont un prix souvent de l'ordre de 100 dollars. La place de marché Magento-Connect présente un système de commentaires (reviews), pas de notation, ni de certifications, mais un classement par nombre de téléchargements.

Environ 50% des extensions sont des jeux de templates, permettant de mettre en place une charte graphique prédéfinie, les autres portent sur des ajouts ou modifications de fonctionnalités. Un déploiement typique de Magento peut n'utiliser que très peu d'extensions, par exemple une pour la localisation, une pour l'optimisation du référencement, et une pour la logistique. Pour Magento, les extensions contribuent à la dynamique du produit, mais non au modèle économique. Pour Prestashop, autre solution d'e-commerce Open Source, la vente d'extensions est une source de revenus, l'éditeur prélevant 30% du prix de vente des extensions, à la manière de Apple.

Dans le monde de la gestion de contenus, Drupal est un parfait exemple du modèle noyau-extensions, il se caractérise par un tout petit noyau, qui se réduit à un moteur de blog, et qui n'est pratiquement jamais déployé seul. La gestion de contenus structurés, par exemple, qui est native dans beaucoup de CMS, est implémentée par le module CCK, pratiquement toujours déployé. Drupal compte de l'ordre de 6000 extensions, toutes gratuites. Il n'y a pas de certification, ni d'évaluation, ni même de reviews par la communauté, mais le classement par défaut est celui du nombre de downloads, qui reflète la popularité.

Dans le domaine de l'ERP, l'extensibilité est bien plus importante encore que dans le contexte du e-commerce ou de la gestion de contenu, car la diversité du besoin est immense. Ici, il ne suffit pas d'ajouter une petite fonctionnalité, il est véritablement question de redéfinir des classes métier, qu'il s'agisse de produits, de clients ou de factures, pour les adapter à son besoin. Ainsi le produit OpenERP compte près de 700 modules d'extension, dont 200 proviennent de l'éditeur, 400 de partenaires intégrateurs, et une centaine sont d'origine communautaire. Elles sont toutes Open Source, mais certaines relèvent d'un programme dit de "shared funding", qui vise à amortir leur développement sur les premiers déploiements.

Conclusion
Comme on l'a vu, le modèle noyau-extensions, parfois aussi appelé "hub-and-spoke" (moyeu et rayons) est bien l'arme fatale des solutions Open Source. Il joue surtout un rôle essentiel en permettant de combiner la logique centralisée de l'éditeur avec le foisonnement darwinien du développement communautaire. Les éditeurs modernes l'ont parfaitement compris, et autant pour des raisons techniques qu'économiques, ils ont pratiquement tous adopté ce modèle, qui réconcilie parfaitement l'Open Source dit commercial, avec la démarche communautaire, apportant aux clients et utilisateurs les bénéfices combinés de l'un et de l'autre.

Autour du même sujet