Qu’est-ce qu’un noyau ouvert ? | Opensource.com

Qu’est-ce qu’un noyau ouvert ? Un projet est-il open core, ou est-ce un business open core ? C’est discutable. Comme l’open source, certains le considèrent comme un modèle de développement, d’autres le considèrent comme un modèle d’affaires. En tant que chef de produit, je l’envisage davantage dans un contexte de création de valeur et de capture de valeur.

Avec l’open source, une équipe d’ingénieurs peut capturer plus de valeur qu’elle n’en apporte. Un ingénieur participant à un projet open source peut contribuer pour 1 $ de code, tout en récupérant 10 $, 20 $, 30 $ ou plus. Cette valeur se mesure à la fois dans la marque personnelle, ainsi que dans la capacité à diriger et à influencer le projet dans une direction qui profite à leur employeur.

Avec un noyau ouvert, au moins une partie du code est propriétaire. Avec un code propriétaire, une entreprise embauche des ingénieurs, résout les problèmes commerciaux et facture ce logiciel. Pour la partie propriétaire de la base de code, il n’y a pas d’ingénierie basée sur la communauté, il n’y a donc pas de processus par lequel un membre de la communauté peut tirer profit de sa participation. Avec le code propriétaire, un dollar investi dans l’ingénierie est un dollar retourné dans le code. Contrairement à l’open source, un processus de développement propriétaire ne peut pas rapporter plus de valeur que ce que l’équipe d’ingénierie n’apporte (voir aussi : Pourquoi Red Hat investit dans CRI-O et Podman).

Ce manque de profit de la communauté est vraiment important lors de l’analyse du noyau ouvert. Il n’y a pas de communauté pour cette partie du code, donc il n’y a pas de participation communautaire, pas de profit communautaire. S’il n’y a pas de communauté, il n’y a aucun potentiel pour un membre de la communauté d’obtenir les avantages standard de l’open source (marque personnelle, influence, droit d’utilisation, apprentissage, etc.).

Il n’y a pas de valeur différentielle créée avec l’open core, donc de 18 façons de différencier les produits open source des fournisseurs en amont, je le décris comme une méthodologie pour capturer la valeur. L’open source communautaire concerne la création de valeur, pas la capture de valeur. Il s’agit d’une tension fondamentale entre l’open source et l’open core.

Code à noyau ouvert contre code de colle

Tout d’abord, examinons ce que les gens considèrent généralement comme open source. Comme décrit sur Wikipédia, « le modèle open-core consiste principalement à proposer une version « de base » ou à fonctionnalités limitées d’un produit logiciel en tant que logiciel libre et open source, tout en proposant des versions « commerciales » ou des modules complémentaires en tant que logiciel propriétaire. » Le dessin ci-dessous montre ce modèle graphiquement.

Un exemple de ce modèle est SugarCRM, qui avait un logiciel de base open source ainsi qu’un tas de plugins, dont beaucoup étaient propriétaires. Un autre exemple de ceci est le plan d’origine de Microsoft pour la fonctionnalité de rechargement à chaud dans .Net (qui a depuis été inversé).

Un autre modèle connexe est ce que j’appellerai code de colle. Le code de colle ne fournit pas directement une valeur commerciale au client. Au lieu de cela, il accroche un tas de projets ensemble. Remarquez que dans cet exemple, je démontre trois projets open source, un service d’API basé sur les données et du code de colle qui maintient le tout ensemble. Le code Glue peut être open source ou propriétaire, mais ce n’est pas ce à quoi les gens pensent généralement quand ils parlent d’open core.

Un exemple de code de collage open source est Red Hat Satellite Server. Il est composé de plusieurs projets open source en amont tels que Foreman, Candlepin, Pulp et Katello, ainsi que d’une connexion à un service de données pour les mises à jour (ainsi que connexions avec des outils comme Red Hat Insights). Dans le cas du serveur Satellite, tout le code de la colle est open source, mais on peut facilement imaginer comment d’autres sociétés pourraient faire le choix d’utiliser un code propriétaire pour cette fonctionnalité.

Lorsque le noyau ouvert entre en conflit avec les objectifs de la communauté

Le problème classique avec le noyau ouvert est lorsque la communauté en amont veut implémenter une fonctionnalité qui se trouve dans l’un des boulons propriétaires. L’entreprise ou le produit qui utilise le modèle open core est incité à empêcher que cela ne se produise dans le projet open source sur lequel repose le code propriétaire. Cela crée de sérieux problèmes à la fois pour la communauté en amont et pour les clients.

Les clients potentiels seront incités à participer à la communauté pour mettre en œuvre les fonctionnalités propriétaires qui sont perçues comme manquantes. Les membres de la communauté qui essaient d’implémenter ces fonctionnalités seront choqués ou agacés lorsque leurs demandes d’extraction sont difficiles à être acceptées ou rejetées d’emblée.

Je n’ai jamais vu de solution sérieuse à ce problème. Dans cette vidéo, Comment bien faire le noyau ouvert : 6 recommandations concrètes, Jono Bacon recommande d’être franc avec les membres de la communauté. Il recommande de leur dire que les demandes d’extraction qui concurrencent les fonctionnalités exclusives du produit seront rejetées. Bien que ce soit mieux que de ne pas être direct, ce n’est pas une solution évolutive. Le projet en amont et le produit en aval avec des fonctionnalités exclusives sont des paysages en constante évolution. Souvent, les contributeurs de la communauté ne font même pas attention au produit en aval et n’ont aucune idée des fonctionnalités qui sont implémentées en aval, ou pire, sur la feuille de route pour être implémentées en tant que fonctionnalités propriétaires. La communauté en amont est rarement impliquée émotionnellement dans les problèmes commerciaux résolus par les produits en aval et peut facilement être confuse lorsque leurs demandes d’extraction sont rejetées.

Même si la communauté est prête à accepter les zones interdites (exemple : Fonctionnalités GitLab par niveau payant), cela en fait une forte probabilité que le projet open source soit une entreprise à fournisseur unique (exemple : Les contributions de GitLab sont principalement des employés de GitLab). Il est hautement improbable que des concurrents participent, et cela limitera intrinsèquement la création de valeur de la communauté. L’activité de base ouverte pourrait toujours générer de la valeur grâce au leadership éclairé, à l’adoption de la technologie et à la fidélisation de la clientèle, mais on peut soutenir qu’elle ne créera jamais vraiment plus de valeur de code qu’elle n’en investit.

En dehors de ces problèmes, si un projet en amont adhère vraiment à la gouvernance ouverte, il n’y a en fait rien que le cœur de métier ouvert puisse faire pour empêcher la mise en œuvre de fonctionnalités propriétaires. Le code propriétaire intra-projet (au sein d’un même projet) ne fonctionne tout simplement pas.

Quand le noyau ouvert pourrait fonctionner

Le code de colle est un endroit où le code à noyau ouvert ou propriétaire peut fonctionner. Je ne prône pas l’open core, et je pense souvent que c’est inefficace, mais je veux être honnête avec mon analyse. Il existe en effet des frontières naturelles entre les projets open source. Pour en revenir à mon open source en tant que thèse sur la chaîne d’approvisionnement (voir aussi : L’art délicat de la gestion de produits avec l’Open Source), une injecteur de carburant est un injecteur de carburant ; ce n’est pas un alternateur. Ces points de démarcation naturels constituent de bonnes zones de différenciation du produit en aval du projet en amont (voir également : 18 façons de différencier les produits logiciels open source de leurs projets en amont).

Un exemple classique de code de colle propriétaire est l’original Réseau Red Hat (RHN), publié en l’an 2000. RHN était essentiellement une offre SaaS qui fournissait des mises à jour pour Red Hat Linux machines, et c’était avant Red Hat Enterprise Linux était même une chose. Pour le contexte, lorsque RHN est sorti, le terme open core n’était même pas encore inventé (inventé en 2008), par coïncidence la même année que la projet Spacewalk en amont a été libéré. À l’époque, tout le monde apprenait encore les compétences de base pour bien faire de l’open source.

Rétrospectivement, je ne pense pas que ce soit une coïncidence que RHN ait existé à la jonction du point de démarcation naturel entre une distribution Linux en amont et une offre payante. Cela correspond naturellement au modèle mental de différenciation d’un produit par rapport au fournisseur en amont. Il pourrait être tentant de conclure – “Tu vois !?!? La plus grande entreprise open source au monde s’est différenciée avec du code propriétaire ! L’open core est la raison pour laquelle Red Hat a survécu et prospéré” – mais je ferais attention à ne pas confondre corrélation avec causalité. Red Hat a finalement ouvert RHN sous le nom de Spacewalk et n’a jamais touché ses revenus.

Pivotant légèrement, on pourrait également faire valoir que les fournisseurs de cloud suivent souvent ce modèle aujourd’hui. Il est bien connu dans l’industrie que la plupart des grands fournisseurs de cloud ont leurs propres forks du noyau Linux. Ces forks ont des extensions propriétaires qui rendent Linux utilisable dans leurs environnements. Ces fonctionnalités ne résolvent pas directement le problème commercial d’un client, mais résolvent plutôt les problèmes du fournisseur de cloud. Ils sont essentiellement du code de colle.

Les fournisseurs de cloud ont une motivation légèrement différente pour ne pas obtenir ces changements en amont. Pour eux, porter un fork est souvent moins cher et/ou plus facile (bien que pas facile) que de contribuer ces fonctionnalités en amont, en particulier lorsque les changements ne sont souvent pas souhaités par la communauté du noyau Linux. Les fournisseurs de cloud choisissent souvent la meilleure mauvaise idée parmi un tas de mauvaises idées.

Le code de colle à noyau ouvert peut être appelé code propriétaire inter-projet (entre plusieurs projets). Cela pourrait fonctionner, mais sans doute, ce type de code est déjà difficile à implémenter et n’a pas besoin des “protections” perçues d’une licence propriétaire. Autrement dit, les contributeurs open source ne sont pas nécessairement incités à travailler et à maintenir le code de la colle. C’est un endroit naturel où un fournisseur peut se différencier. Souvent, le code de colle est complexe et nécessite des intégrations spécifiques entre des versions spécifiques de projets en amont pour des exigences de cycle de vie spécifiques. Toutes ces exigences spécifiques font du code de la colle un endroit idéal pour qu’un produit se différencie des projets en amont sans avoir besoin d’une licence propriétaire. La vitesse (vitesse et direction) des intégrations d’entreprise est assez différente de la vitesse nécessaire à la collaboration entre plusieurs projets en amont. Cette inadéquation de vitesse entre les besoins de la communauté en amont et les besoins des clients en aval est un endroit parfait pour se différencier sans avoir besoin d’un noyau ouvert.

Conclusion

Le noyau ouvert peut-il fonctionner ? Est-ce mieux que l’open source ? Tout le monde doit-il l’utiliser ? Il semble évident qu’Open core peut fonctionner, mais seulement dans des situations très spécifiques avec des types de logiciels très spécifiques (ex. glue code). Il semble moins évident qu’il y ait un argument selon lequel l’open core est en fait meilleur pour créer de la valeur. Par conséquent, je ne recommande pas le noyau ouvert pour la plupart des entreprises. De plus, je pense que les protections perçues qu’il offre sont en fait inutiles.

Souvent, les vendeurs trouvent des endroits naturels pour se concurrencer. Par exemple, SUSE exécute le Service de création OpenSUSE, qui est basé sur un code source complètement ouvert. Même si Red Hat pouvait télécharger le code source et configurer un service de build concurrent, ils ne l’ont pas fait. En fait, le projet Podman en amont, fortement sponsorisé par Red Hat, utilise le Service de construction OpenSUSE. Bien que SUSE puisse facilement rendre ce code propriétaire, ils n’en ont pas besoin. La configuration, l’exécution et la maintenance d’un service concurrent représentent beaucoup de travail et n’apportent pas nécessairement beaucoup de valeur aux clients Red Hat.

Je pense toujours qu’Open Core est un pas dans la bonne direction à partir d’un code entièrement propriétaire (exemple : GitLab est un noyau ouvert, GitHub est un code source fermé), mais je ne vois pas de raison impérieuse de le promouvoir comme une meilleure alternative à l’open source complètement. En fait, je pense que c’est extrêmement difficile bien faire de l’open core et probablement impossible de créer une valeur réellement différenciée avec lui (voir aussi : La renaissance de l’open source et de la source Fauxpen menée par la communauté est mauvaise pour les affaires).

Cette thèse sur l’open core a été développée en travaillant avec et en apprenant de centaines de personnes passionnées par l’Open Source, notamment des ingénieurs, des chefs de produit, des responsables marketing, des commerciaux et certains des plus grands avocats de ce domaine. Pour publier de nouvelles fonctionnalités et capacités dans Red Hat Enterprise Linux et OpenShift, comme le lancement de Red Hat Universal Base Image, j’ai travaillé en étroite collaboration avec de nombreuses équipes différentes chez Red Hat. J’ai absorbé plus de 25 ans de connaissances institutionnelles, au cours de mes 10+ années ici. Maintenant, j’essaie de formaliser cela un peu dans le travail public comme L’art délicat de la gestion de produits avec l’Open Source et des articles de suivi comme celui-ci.

Ce travail a contribué à ma récente promotion au poste de Senior Principal Product Manager de RHEL pour serveur, sans doute la plus grande entreprise open source au monde. Même avec cette expérience, je suis constamment à l’écoute, à l’apprentissage et à la recherche de la vérité. J’aimerais discuter davantage de ce sujet dans les commentaires ou sur Twitter (@fatherlinux).