Dans une interview, Stephen O'Grady, analyste de Redmonk, a estimé que « trop d'entreprises du secteur de l'open source se plaignaient encore du comportement adopté par Microsoft dans le passé ». En effet, l’idée selon laquelle « celui qui a développé le produit était le seul à pouvoir en tirer profit », soutenue un temps par la firme de Redmond, était « une vue à court terme ». Le point de vue de Stephen O'Grady fait écho à la déclaration récente d’Adam Jacob, co-fondateur de Chef (désormais System Initiative), dans laquelle il a affirmé que la concurrence dans les logiciels libres « élargissait l’offre au sommet de l'entonnoir ». Si l’on comprend bien ce que veulent dire Stephen O'Grady et Adam Jacob, le véritable choix est plutôt de savoir s'il vaut mieux posséder la totalité d'une petite tarte, ou de profiter de la part d’une tarte beaucoup plus grande, dont la valeur peut-être bien plus importante. Comme le fait aussi remarquer Stephen O'Grady à propos du comportement antérieur de Microsoft, et qui est tout aussi important, « on peut finir par perdre le marché en essayant de tout posséder ».

Les erreurs passées de Microsoft

Aujourd'hui, Microsoft est une entreprise très différente de ce qu'elle était dans les années 1990 et 2000. Au début de ma carrière, j’ai consacré une grande partie de mon temps à me battre contre la machine Microsoft. Á l’époque, il était facile de ne pas aimer le géant de Redmond : avec son portefeuille de brevets, l’entreprise menaçait l'open source et elle faisait généralement tout ce qu'elle pouvait pour entraver sa propagation. En 2010, en tant que COO de Canonical, j’avais suggéré à Microsoft de prendre l'open source au sérieux. La firme semblait bloquée sur Windows et Office, et elle paraissait incapable de réfléchir sérieusement à son prochain milliard de dollars de chiffre d'affaires. En 2015, il était clair que Microsoft avait retrouvé l’envie de développer des produits, en grande partie (vous l'avez deviné) du fait d’une sensibilisation significative et sincère à l'open source. Aujourd'hui, je travaille pour un concurrent direct de Microsoft, mais j'aime la façon dont l'entreprise a adopté l'open source.

Même si Microsoft a pris les bonnes décisions par rapport à l'open source, en renonçant notamment à ce besoin de contrôle, l’entreprise s'est formée dans d'autres domaines où elle ne pouvait pas adopter une approche communautaire. Comme le souligne M. O'Grady, que ce soit Mono ou.NET, « Microsoft était bloquée sur l’idée que, parce qu’elle avait écrit tel ou tel code, elle devait être la seule à percevoir des revenus pour cela ». Même si ce point de vue semble raisonnable, M. O'Grady estime que cette attitude « ne lui a pas rendu service à l'époque ». Il poursuit : « C'était en 2004, 2005, 2006, quelque part dans cette période, et j'ai suggéré à Microsoft, en privé, que la meilleure chose à faire serait d’affranchir le Projet Mono - un projet open source qui permettait aux applications .NET de fonctionner sous Linux - de tout brevet… D’un seul coup, Microsoft aurait pu disposer d’une implémentation sur des plates-formes autres que Microsoft. C'est pour cette raison que l’entreprise a était malmenée à l'époque. On lui disait : « c’est super que ça marche bien sur Windows, mais j'ai quelques charges de travail que je veux faire tourner sous Linux ! » Ou encore : « Je peux faire tourner Java sur les deux plates-formes, mais je ne peux exécuter vos trucs que sur votre plate-forme. Ce n’est pas ce qui m’arrange le plus ».

« Sauf qu’à l'époque, Microsoft n’en démordait pas. L’entreprise s’accrochait à l’idée qu’elle ne ferait jamais ça ‘parce qu’elle avait écrit le logiciel’ ». Son idéologie ne lui permettait pas de voir ce qui se passait, et je pense que l’on peut retrouver beaucoup de similitudes avec ce qui se passe actuellement ». Aujourd'hui, Microsoft a adopté Mono et livré son propre noyau .NET Core en open source. Ce successeur de .NET Framework permet aux applications basées sur .NET de fonctionner facilement sous Linux. En 2020, Microsoft semble réaliser qu'il vaut mieux élargir les marchés que les restreindre et les contrôler. Tout ce que Microsoft refusait en 2010. Comme le souligne M. O'Grady, aujourd’hui aussi, certains éditeurs de logiciels open source n'ont pas tiré les leçons des erreurs passées de Microsoft.

Valider et développer le marché

« Je comprends ce sentiment viscéral, selon lequel, parce qu’on a développé tel ou tel portion de code, on ne veut pas que quelqu'un d'autre s’en empare et en tire profit. Mais franchement, c'est tout à fait le genre d’attitude qui a bloqué Microsoft pendant des années », fait encore remarquer M. O'Grady. Et c’est cette même attitude qui freine les entreprises open source aujourd'hui. En effet, je pense tout d'abord que cela détourne leur attention de ce qui est le plus important pour eux : leurs clients. Il n'est pas difficile de voir que la prospérité des entreprises qui commercialisent des logiciels open source augmente en même temps que leurs activités dans le cloud. Ce qui n’est pas le cas des entreprises qui pratiquent une politique de licences, comme souligné auparavant. Cette industrie a perdu beaucoup de temps avec ce genre de pratiques.

Vous vous souvenez de l'Open Core ? C'était un précurseur des différents systèmes de licences (Commons Clause, Server Side Public License, etc.) qui cherchaient à rendre un projet open source un peu propriétaire dans l'espoir de ramasser de l'argent. Malheureusement, on peut se demander, comme le fait Stephen O'Grady, « quelles sont les implications à long terme de ce type approches ? » De façon générale, la réponse est sans appel. Comme il l’explique, « dans la plupart des cas, cela se traduit par des problèmes d'adoption, d'utilisation, mais aussi des difficultés pour atteindre l'ubiquité, nécessaire à de nombreux modèles d’affaire basés sur des logiciels open source ». La solution serait plutôt d'adopter le cloud, car c'est ainsi que les clients veulent consommer votre base de données, votre système d'exploitation, etc. Mais que se passe-t-il si un mastodonte s’empare de votre projet open source et crée un service concurrent dans le cloud ?

Pas si mauvais que ça

Non, en effet, ce n’est pas si mauvais que ça… Le plus gros problème pour une start-up n'est pas de collecter de l'argent. Le vrai enjeu, bien plus important, est de se faire remarquer, d'attirer des utilisateurs. « Dans une certaine mesure, la dissémination d'un produit concurrent par l'un de ces fournisseurs de cloud n'est rien d'autre qu’une validation du marché », explique encore M. O'Grady. Prenons par exemple le marché des bases de données. DB-Engines répertorie actuellement 359 bases de données. Difficile de se démarquer dans cette foule. « Je peux choisir entre celles qui sont plus petites, qui ne sont pas très utilisées, et celles qui sont soutenues par MongoDB, Amazon [DocumentDB] et Microsoft [CosmosDB]. La décision est assez facile à prendre si l’on regarde le produit qui a clairement le plus d'attrait et qui a été validé par le marché ».

Mais, que se passe-t-il si les concurrents valident le marché et captent aussi des clients ? De l’avis d’Adam Jacob, « il ne faut pas se dire qu’un rival prend votre logiciel et essaie d’en développer un autre pour vous concurrencer, car en réalité, il contribue à élargir le sommet de l’entonnoir. Étant donné l’importance de l’impact, le nombre d'opportunités que cela créé pour vous est plus important que ce que vous perdez à la sortie de l’entonnoir ». Écrire et exploiter un logiciel sont deux choses très différentes, et peut-être que certains éditeurs de logiciels libres se disent que « c'est trop difficile », et ils ont raison. Mais, comme l’a déclaré en conclusion M. O'Grady, « vous n'avez pas vraiment le choix, car d'une manière ou d'une autre, les clients auront ce qu'ils veulent, et si vous ne le leur donnez pas, ils iront le chercher ailleurs ».

Les enseignements de Redis Labs

La bonne nouvelle, c'est que beaucoup préfèrent s’adresser à l’entreprise qui connaît le code sur le bout des doigts. Redis Labs en est un bon exemple. Quand le fondateur de Redis, Salvatore Sanfilippo, a décidé de passer à d'autres projets, Redis Labs a dû faire un choix : verrouiller le code de Redis ou le livrer en open source. C’est cette dernière solution qu’a choisie l’entreprise, en élargissant la structure de gouvernance du projet. De nombreux fournisseurs proposent aujourd’hui une série de services gérés pour Redis (depuis Redis Labs à Aiven, en passant par Instaclustr, DigitalOcean et Microsoft, etc…). Les contributions au projet sont également de plus en plus rapides.

Redis Labs semble d’accord avec l’approche de Stephen O'Grady et Adam Jacobs, celle de la tarte plus grande, sur laquelle elle a moins de contrôle, mais dont elle tire tout de même des revenus impressionnants. Oui, l’éditeur propose toujours des logiciels sous licence propriétaire, mais de manière générale il semble prendre une voie plus axée vers l’open source. Et, comme le fait remarquer M. O'Grady, il n'y a pas de modèle unique pour réussir dans l'open source. Par exemple, Redis Labs peut prendre une voie différente de celle d'Instaclustr. Mais globalement, la bonne approche consiste à accroître le marché global, même au détriment du contrôle, plutôt que d'essayer de thésauriser un marché relativement étroit. Cette dernière approche coûte beaucoup plus cher à développer, elle a plus de chances d'échouer et elle a montré ses limites, surtout si l’on prend en compte les erreurs passées de Microsoft dans ce domaine.