Le Monopole Open Source 
"Le Monopole Open Source" a été dans l'origine édité comme une papier seul. Il a depuis deviennent le premier dans une série de trois. Le deuxiéme papier, The Economics of Commercial Open Source, regards en plus détail aux modéles des compagnies ceux qui Red Hat Inc., JBoss et MySQL ab. Le troisiéme papier, Openstructure: A Call for Open Source Reform, présente quelques solutions à la tendance courante dans l'Open source et offre un défi à la communauté Open Source pour la réforme.
Traduction courtoisie de ITRManager.
Dans un article récent sur Geronimo Apache, j'ai écrit : « Geronimo vise à être le premier serveur d'applications Open Source certifié J2EE ». Cette affirmation a suscité de nombreuses réactions indiquant en substance que JBoss était le premier de cette catégorie. Je maintiens mon affirmation motivée par le fait que JBoss, à mon sens, ne correspond pas à la définition stricte de l'Open Source et je me permets de clarifier mon point de vue.
La définition Officielle de l'Open Source
Le terme « Open Source » correspond à une définition précise énoncée par l'OSI (Open Source Initiative), une association à but non lucratif. Selon cette définition, « un logiciel Open Source est un morceau de code qui peut être librement modifié et redistribué. Les droits de redistribution n'empêche pas une société qui le souhaiterait de le faire dans le but de gagner de l'argent. »
L'OSI certifie plusieurs licences Open Source. Une entreprise qui souhaite labelliser un produit du qualificatif Open Source doit soumettre la licence à l'approbation de l'OSI. Une fois acceptée, la licence s'ajoute à liste déjà longue de des produits Open Source et l'entreprise qui l'a proposée peut alors utiliser ce label à des fins marketing. Sun a soumis avec succès sa licence CDDL (Common Development and Distribution Licence) pour Solaris 10. La liste comprend déjà des dizaines de licences, parfois incompatibles.
Selon cette définition, JBoss peut donc prétendre au qualificatif Open Source au même titre que des produits issus de la Fondation Apache ou du projet GNU. Mais les questions à se poser sont : quels sont les produits que l'on peut réellement considérer Open Source ? La définition de l'OSI est-elle pertinente ? Pour y répondre, examinons les différents modèles existants.
Les différents modèles en lice
Si l'on se réfère au début du phénomène, l'Open Source a été constitué, autour de la nébuleuse Unix, par un groupe toujours plus important de développeurs et d'utilisateurs. Aujourd'hui, les projets Open Source abondent, il n'y a qu'à en consulter la liste sur sourceforge.net ou frehmeat.net. Dans ce que l'on peut appeler un véritable maquis, il faut distinguer deux grands modèles de développement : le modèle basé sur le bénévolat et le modèle commercial.
Dans le premier modèle, le logiciel Open Source est écrit par des bénévoles qui mettent leur temps et leurs compétences à collaborer à un projet particulier. Si des tâches particulières sont assignées à chacun de membres, les décisions sont en général prises sur la base du consensus et tous les développeurs partagent le désir de développer du logiciel de qualité. Et c'est ce modèle qui prévaut encore aujourd'hui pour la grande majorité des projets Open Source.
Les organisations à but non lucratif comme la FSF (Free Software Foundation), la fondation Apache (Apache Software Foundation) et la fondation FreeBSD sont basées sur ce modèle, tout en y ajoutant une touche personnelle et une appellation qui s'apparente à une marque. Les projets développés dans ces fondations sont en général très actifs, possèdent une large communauté d'utilisateurs et partagent le goût de la qualité et de la fiabilité. Ces diverses organisations sont spécialisées dans des domaines différents et ont des licences spécifiques.
Le modèle dit commercial est né dans un second temps, après que l'Open Source se soit constitué en un mouvement solide. Ce modèle cherche à tirer parti de la popularité du mouvement Open Source. Dans ce modèle, des entreprises commerciales proposent souvent des logiciels propriétaires en les qualifiant d'Open Source. Il y a de nombreux exemples. L'un des premiers est celui de Netscape Communications qui a ouvert le code de son navigateur en 1998 et a donné naissance à la fondation Mozilla (The Mozilla Foundation a été créée en 2003 avec le statut d'organisation à but non lucratif et avec des fonds provenant de Netscape). Un autre exemple plus récents est celui de Sun qui vient tout juste d'annoncer Solaris 10 et en proposer le code en licence Open Source CDDL.
Dans ce modèle commercial, les entreprises commerciales commencent de nouveaux projets ex nihilo. JBoss fait parti de ceux-ci. Le modèle fonctionne comme suit : l'entreprise conçoit un produit ou en sponsorise le développement ainsi que celui de la communauté ad hoc. Au-delà d'un cercle de développeurs rémunérés, la société fait appel à des développeurs bénévoles. Les décisions stratégiques sont prises par l'entreprise. Dans un certain sens, l'entreprise utilise du travail non rémunéré au prétexte de fonctionner sous le label Open Source.
Bien sûr, le produit est commercialisé en mode Open Source, tout un chacun peut le télécharger et l'utiliser à peu près comme bon lui semble. Cela signifie que la communauté bénéficie en partie de son travail. Mais le réel bénéficiaire est l'entreprise qui propose au marché un produit autour duquel elle gagne de l'argent en services : conseil, formation, support. De plus en plus, on voit même des entreprises qui créént des versions payantes de ces produits. Parmi celles-ci, on peut citer MySQL. Après avoir cédé le produit gratuitement pendant des années, le modèle économique pousse l'entreprise à en proposer une version payante. Bien sûr, il est toujours possible de le télécharger gratuitement, mais il vaut mieux dans ce cas être très attentif aux termes de la licence d'utilisation. Une des licences stipulées par MySQL impose de faire l'acquisition d'une version de MySQL pour toute utilisation de la base de données comme partie intégrante d'une application mise en œuvre dans l'entreprise.
On aurait pu penser qu'une interprétation aussi radicale de la licence GPL (GNU General Public Licence) ne serait jamais faite. Nombreux sont ceux qui pensaient que SCO était une grande entreprise dans laquelle il était prestigieux de travailler, et à laquelle acheter un produit. Même si elle a été digne de confiance pendant un certain temps, elle a eu recours à des méthodes juridiques plus que discutables pour améliorer son compte d'exploitation.
Dans un monde sous l'emprise de fusions et d'acquisition, qu'adviendrait-il si une des sociétés Open Source était achetée par HP, Ibm ou Oracle ? Si MySQL peut aller jusqu'à envisager d'imposer l'achat d'une version commerciale de sa base de données pour toute utilisation en entreprise, il n'est pas inconcevable de penser que RedHat et JBoss pourrait en faire autant. Et que doit faire une entreprise si elle souhaite fonder son infrastructure informatique autour de ces produits ?
En tant q'utilisateur de longue date de produits Open Source, c'est ce modèle commercial qui me préoccupe le plus. Je ne dénie à personne le droit de gagner de l'argent. Mais je réfute le fait d'adhérer à ce mouvement à des fins marketing ou stratégiques et finir par faire la même chose que ceux qui sont généralement considérés comme des adversaires du mouvement. C'est pourquoi j'ai un problème avec des entreprises comme JBoss ou d'autres. Ce que je souhaite aborder ici est le problème des monopoles.
La face changeante des monopoles
Les protagonistes du mouvement Open Source aiment à penser que leur mouvement est radical, révolutionnaire et capable de changer les règles. Il est vrai qu'il a certainement beaucoup changé le fonctionnement de nombreuses directions informatiques. Mais l'Open Source a-t-il réellement changé les règles de l'économie ou bien l'économie n'est-elle pas en train d'absorber, de digérer le mouvement Open Source. Ce que nous avons vu ces quelques dernières années permet de se poser réellement la question et se la poser est déjà apporter des éléments de réponse.
L'Open Source est né en réaction à la constitution des logiciels propriétaires trop chers et à évolution trop lente. Dans les années 80, une entreprise achetait un logiciel à un éditeur et se retrouvait prisonnière de cet éditeur. Le logiciel était propriétaire et fermé. Et en tant qu'utilisateur, il vous était impossible d'ouvrir la boîte noire. A l'inverse, les logiciels Open Source sont ouverts pour tout développement supplémentaire et tous types d'utilisation. Il est possible de télécharger une version d'Unix à partir d'une source, des outils de compilation à partir d'une autre et des logiciels bureautiques d'une troisième. Il est aussi possible d'apporter des modifications, d'ajouter des fonctionnalités et de redistribuer ces changements sans restrictions ou presque. Le mot magique est à l'époque : 'liberté' ; il annonçait un avenir très prometteur.
Les marxistes diront que la dialectique est nécessaire : de deux principes contradictoires naît un troisième qui les dépasse. D'un point de vue philosophique ou pratique, toutefois ce n'est pas ce à quoi on assiste. Ce qui arrive est qu'une des deux parties est essentiellement dérivée de l'autre qu'elle pervertit et absorbe. Prenons les monopoles des années 80 et 90. Totalement opposés au mouvement Open Source. Que sont-ils advenus ? Il suffit d'observer Red Hat, une des entreprises leader de l'Open Source. Il parle de solutions et construit un écosystème autour de Linux et des technologies Open Source. Bien sûr, je suis libre de choisir un autre logiciel, mais ce que souhaite Red Hat, n'est-il pas ce que souhaitait Ibm dans les années 80 ? Me pousser gentiment vers un ensemble de composants matériels et logiciels rebaptisés sous une même marque ? Un sorte de monopole qui cache son nom.
Il est vraisemblable qu'Ibm, Sun, Microsoft, JBoss et Red Hat ont plus de choses en commun que de différences. Mais il faut aller un peu plus loin dans l'analyse pour voir quelles sont ces similitudes. Un monopole des années 80 était différent de ceux d'aujourd'hui. Dans les années 80, il était possible de vendre du matériel qui supportait une seule catégorie de logiciels et ces derniers ne fonctionnaient que sur une seule catégorie de matériels. On ne parlait pas alors de monopole, mais de solutions. Mais les monopoles évoluent. Aujourd'hui, les monopoles se situent au niveau des marques et du marketing. En tant que développeur, je sais que le logiciel Open Source existe et j'ai la possibilité (et jusqu'ici la liberté) de choisir ce dont j'ai besoin. Mais bien souvent, les équipes dirigeantes des entreprises n'ont pas ces possibilités. En fait, elles voient un nombre réduit de marques qui proposent (et promettent) des plates-formes Open Source intégrées et homogènes. Et comme dans les années 80, elles choisissent une solution qui semble répondre à leurs besoins. Une fois qu'elles ont fait le choix de cette solution ou de cet écosystème, elles sont de nouveau comme prisonnières. Il ne s'agit peut-être pas formellement de monopole, mais en fait, cela en est un.
Evidemment, les premiers développeurs Open Source n'auraient jamais imaginé que leur mouvement pourrait un jour être récupéré par le modèle commercial auquel ils se sont soustrait au prix de tant d'efforts. Mais ce phénomène se passe sous nos yeux. Dans quelques années, le mouvement Open Source sera en fait concentré dans les mains de quelques grands groupes qui auront alors le monopole des infrastructures informatiques des entreprises. Ce n'est pas vraiment différent de la situation des années 80. Bien sûr, la fondation Apache et quelques autres existeront encore, mais je suis sûr que la majorité des produits qui en seront issu seront rebaptisés Open Source et commercialisés par ces quelques monopoles Open Source. Oui, Sourceforge.net continuera à développer des dizaines de milliers de projets, mais très peu d'entre eux auront un impact significatif sur les systèmes d'information.
En 1997, Eric Raymond a écrit un article aujourd'hui fameux : « La Cathédrale et le Bazar », considéré comme le texte de référence du mouvement Open Source. Ironie du sort, peu de temps après avoir écrit cet article, Eric Raymond a été sollicité par Netscape Communications pour définir les stratégie Open Source. Je suis sûr que c'est là une position enviable pour un développeur Unix que de se voir courtiser par les dirigeants d'une des entreprises les plus en vue du monde Internet de l'époque. J'ai peur que cela ait été trop flatteur. Alors qu'Eric Raymond a analysé cela comme un test grandeur nature de l'association des modèles du bazar et de la cathédrale, il s'agissait en réalité du début la récupération du modèle Open Source par le monde commercial. Et où se trouve Eric Raymond aujourd'hui ? Il est tout simplement président de l'OSI, la même organisation qui accorde le label Open Source à des entreprises comme JBoss, RedHat, Sun et d'autres. Je comprends sa motivation : il faut impérativement impliquer les entreprises commerciales dans le processus afin que la révolution de l'Open Source réussisse. Mais cela doit être plutôt vu comme le dragon qui allumerait votre four ? Il va l'allumer,certes, mais il va ensuite vous engloutir.
Le problème des produits
Dans l'univers de l'informatique, nous avons perdu l'approche pratique des choses. Nous sommes constamment dans ce que l'on pourrait appeler la recherche du « meilleur » produit. C'est un argument séduisant certes, après tout ne souhaitons-nous pas disposer tous de la meilleure base de données, de la meilleure voiture ou du meilleur prêt. Cela est encore plus attractif dans la mesure où nous pensons ainsi que nous sommes objectifs et très évolués. En fait, nous substituons la réalité de nos propres besoins à la subjectivité d'autrui déguisée en objectivité. Il n'y aucune objectivité dès lors que n'importe qui peut présenter son produit comme le meilleur. Si vous n'êtes plus en mesure de connaître vos propres besoins, comment pouvez-vous faire la part des choses ? La seule voie possible est d'utiliser des méthodes artificielles comme la popularité ou le prix d'un produit.
MySQL est-il meilleur que PostgreSQL ? Est-il autant apprécié ? Ce qui n'est pas pareil. Pour mon activité, j'ai besoin d'une base de données qui puisse faire le liaison avec le commercial, pour la vente des produits. La licence MySQL ne semble pa faire l'affaire. Donc MySQL ne répond pas à mes besoins. Je choisis donc PostGreSQL. Non, il n'est pas aussi apprécié, mais il correspond parfaitement à ce que je recherche et semble techniquement meilleur.
Alors que cela semble être un point de détail, comprendre vraiment vos besoins est la différence entre le succès et l'échec en informatique. Les décisions de base sur ce dont vous avez besoin mènent à un mode de réflexion qui juge les options en matière de technologie sur ce qui peut satisfaire vos besoins. Tout autre mode de raisonnement ne peut que vous rendre victime d'une meilleure campagne marketing.
Dans les années 90, j'étais spécialisé dans les bases de données Sybase haut de gamme. Dans toutes les entreprises ou j'ai travaillé, il fallait toujours entreprendre une opération de migration. Un client migrait de Sybase vers Informix. Un autre de Sybase vers Oracle, un troisième d'Ingres vers Sybase. En y réfléchissant un peu, est-ce que ces décisions étaient réellement prises sur la base des besoins réels ? Je suis sûr que c'était l'explication officielle... Mais, prenons par exemple, une migration dont j'ai été témoin dans une grande entreprise - passée de Sybase à Oracle. Les administrateurs de bases de données Sybase rentraient chez eux à 5 heures et revenaient le lendemain matin à 9 heures. Ils avaient des problèmes à régler bien sûr, mais vivaient une vie relativement normale. A l'inverse, les administrateurs Oracle passaient souvent leurs nuits au bureau. Et les problèmes auxquels ils étaient confrontés étaient si aigus, que cela leur prenait des jours pour les régler. Alors quelle était la meilleure solution technique ? Un administrateur de base de données vous dira que c'était Sybase. Mais cela n'avait pas beaucoup de poids parce que les équipes dirigeantes de l'entreprise utilisatrice était sous l'influence de la campagne marketing d'Oracle. Et il est possible qu'ils aient perdu de vue la chose importance : leur activité.
Les coûts font partie de la campagne marketing, que vous le croyez ou non. Il semble raisonnable de baser ses choix sur les coûts. Mais la tarification est souvent la manière de se débarrasser du problème. La majorité des conversions auxquelles j'ai assisté étaient motivées par le fait que la nouvelle solution permettrait de faire des économies substantielles. Mais ici encore, qui l'affirme ? Les responsables marketing. Sur le papier, il est possible de faire apparaître n'importe quelle solution moins chère qu'une autre. Mais si la base de données Oracle nécessite plus de ressources d'administration parce qu'elle est techniquement moins bonne, quelle est l'analyse en termes de coûts ? Ou qu'arrive-t-il quand une version d'Oracle nécessite de plus gros serveurs ? Et cela arrive tout le temps. Chaque nouvelle version nécessite de nouvelles configurations matérielles.
Le nouveau Ketchup
Selon son modèle économique, Robert Young co-fondateur de Red Hat a résolu le problème en gagnant de l'argent dans le monde Open Source. Il a compris que le succès de la majorité des produits étaient intimement lié à la notion de marque. Il prend l'analogie du Ketchup Heinz qui possède environ 80 % du marché. Il est faux de penser que Heinz fait du meilleur Ketchup que ses concurrents. Mais le fait est que cette entreprise a réussi à faire que Heinz devienne synonyme de Ketchup. Et c'est ce que RedHat a cherché à faire. Si vous pensez Linux, vous pensez immanquablement RedHat.
L'idée de marque est à la base de la stratégie du marketing, aux Etats-Unis. Il faut créer une marque et la vendre implacablement. Dépenser la moitié de votre chiffre d'affaires afin que votre marque entre dans le cerveau des consommateurs et devienne synonyme du produit que vous vendez. Et la qualité ? Est-ce que votre produit est le meilleur pour tous les utilisateurs ? Ce n'est pas votre problème et ce n'est même pas une question qui se pose. Pour s'en convaincre, il suffit de prendre la première douzaine de noms sur n'importe quel marché. Ensuite, observez les concurrents qui viennent ensuite. Il n'est pas impossible que leurs produits soient de meilleure qualité ou plus fiables.
Si le marketing de Heinz a réussi à faire en sorte que le marché choisisse son produit, pourquoi pas. C'est une question de goût et cela ne porte pas vraiment à conséquence. Mais qu'arrive-t-il si vous confiez l'informatique de votre entreprise à une marque ? Est-ce que ses actionnaires doivent vous faire confiance alors que vos décisions sont aussi facilement influencées et tiennent compte plus de la force des marques que des réels besoins de l'entreprise ? C'est ce qui se passe avec RedHat, MySQL, JBoss et d'autres, comme en leur temps avec IBM, Sun, Microsoft ou HP. Ils ont réussi à faire en sorte que leur nom soit synonyme d'Open Source. Dans ce processus, j'ai bien peur que les réels besoins des entreprises passent au deuxième plan.
L'approche en termes de marque créé les monopoles. A l'age des logiciels propriétaires, on se rappelle comment les entreprises devenaient facilement enfermées dans une pas parce que le mot magique Open Source s'est imposé que la situation a changé. Et si la révolution Open Source était censée changer tout ça, évidemment c'est un échec. En fait, on assiste à l'émergence de nouveaux noms estampillés Open Source qui créent le même enfermement technique.
La manie des versions
Mais lorsque je décris le mouvement Open Source comme victime des grandes entreprises, il a aussi sa part de responsabilité. Si un produit ne répond pas à vos besoins, il y en a bien d'autres qui sont encore pire. Dans un précédent article, un lecteur me demandait pourquoi la fondation Apache avait du réinventer la roue en développant le serveur d'applications Geronimo alors qu'un produit solide comme JonAS existait déjà ? C'est une vraie question et je l'ai posée à un des fondateurs du projet Geronimo lors de la conférence ApacheCon2003. La réponse que j'ai obtenue était liée à un problème de licence : l'équipe du projet Geronimo voulait avoir un serveur d'applications sous licence ASF. A l'époque, j'ai accepté cette réponse. Aujourd'hui, je ne suis plus très sûr de sa pertinence. Faut-il réécrire des serveurs d'applications, encore et encore ?
Ce cycle de développement incessant est particulièrement aigu dans le monde Open Source : c'est ce que j'appelle la manie des versions. J'ai collaboré à de nombreux projets Apache pendant plusieurs années. Et je n'ai jamais vu de cycle de versionning aussi frénétique.
Cette manie entraîne deux effets : l'instabilité des produits et une intégration cauchemardesque. Je me souviens de la version 4.0 de Tomcat d'Apache. Et y avait de sérieux problèmes de mémoire. Aujourd'hui, nous avons le même problème avec la version 5.5. Après m'être fait piéger plusieurs fois, j'ai arrêté une stratégie : une fois avoir mis en œuvre une version solide d'un produit Open Source, je la garde quels que soient les développements. Je considère la possibilité d'une migration pour les seules raisons de sécurité.
Conseil
Je n'ai pas souhaité écrire cet article pour mettre en garde contre le mouvement Open Source. Je ne veux même pas me risquer à faire des prédictions. Juste mettre en lumière ce qui est en train de se passer. Cela n'affectera pas le développement d'entreprises comme RedHat, JBoss ou MySQL. Alors que de plus en plus d'entreprises se convertissent à l'Open Source, ces éditeurs vont continuer à croître et d'autres émergeront.
Je me risque seulement à un conseil. Si vous êtes responsable d'une entreprise, arrêtez-vous un instant sur ce que vous dépensez en technologie. Cela en vaut-il la peine ? Imposez-vous à votre direction informatique la même rigueur qu'à vos unités de fabrication ou à vos autres directions fonctionnelles ? Est-ce que vous avez des outils logiciels que vous pourriez utiliser longtemps sans avoir à réinvestir dans un nouveau produit parce que quelqu'un de votre entreprise à joué au golf avec le responsable commercial d'un éditeur de logiciels ? Si ce n'est pas le cas, vous devriez peut-être revenir aux racines de votre activité et essayer de comprendre vos vrais besoins. Ensuite choisir les produits qui y répondent. Bien sûr, les nouvelles technologies semblent intéressantes sur le papier. Mais la moitié disparaîtront dans 18 mois. Et l'autre coûtera plus que ce que vous pouvez justifier.
Si vous êtes responsable informatique, outre le fait d'arrêter de lire des magazines spécialisés, parlez avec vos développeurs. Rencontrez les personnes du terrain, celles qui sont confrontés aux réalités. Dans toutes les entreprises où j'ai fait du conseil, elles étaient les seules à pouvait juger si un projet allait réussir ou non.
Si vous êtes un développeur, je vous encourage à regarder au-delà des sentiers battus des campagnes marketing des éditeurs. Faîtes une recherche avant de décider que RedHat, JBoss ou MySQL est le meilleur. Ils sont les plus diffusés, j'en conviens. Mais il n'y a pas de lien entre le succès et la qualité des produits ou leur niveau de réponse à vos besoins.
Par-dessus tout, prenez des décisions en fonction de vos besoins. Ne prenez pas trop vite des décisions sur la base de seules considérations marketing.
| 