Pour attester de sa bonne foi vis-à-vis de l’open source, ce dont AWS a réellement besoin, c’est d’un projet phare, sous-entendu open source. Cette suggestion, récemment soumise par un ami via un message direct sur Twitter, exposait en substance différents projets emblématiques de concurrents : « Où est l’Android d’AWS, son Kubernetes, son Tensorflow, son VS Code ? ». A l’exception de vscode qui est un projet de Microsoft - à ne pas confondre avec Visual Studio Code qui est bâti sur vscode mais qui n’est pas lui-même open source - les autres projets viennent de Google. Si l’argument est familier, il n’est pas convaincant. Après tout, AWS a Firecracker et d’autres projets open source. Mais là n’est pas vraiment la question.

Ce qui me gêne, c’est la suggestion implicite que les entreprises contribuent à l’open source par altruisme, qu’elles se sont construit des réputations contributrices positives apportant au monde la paix, l’amour et du code open source. Cela donne l’occasion de messages spirituels sur Twitter mais ce n'est pas la vraie histoire. Car si les développeurs peuvent apporter leur contribution à un projet libre par pur amour du code, ce n’est pas le cas des entreprises. Jamais. C’est pourquoi il est utile de se demander pourquoi une entreprise a, ou n’a pas, partagé ou contribué à du code.

L’open source demande énormément de travail

Vous avez peut-être travaillé pour des entreprises ayant des ressources illimitées. Pas moi. Même les organisations extrêmement riches ont toujours des ressources limitées. Rapprochez maintenant cela de la réalité de l’open source qui demande énormément de travail. A quels niveaux ? Matt Klein, développeur logiciel senior chez Lyft et fondateur d'Envoy, un projet qui a rencontré le succès, dit très clairement que cela représente « une fichue quantité de travail ». Il ne s’agit pas seulement du code, mais de toutes les autres choses (marketing, développement de l’activité, etc.) qui vont de pair avec la réalisation d’un projet qui débouche sur une réussite. Le pire, c’est qu’il n’y a aucun moyen de savoir à l’avance si tout ce travail sera payant : « Les bénéfices ne sont pas très clairs. Ce n’est pas gagné d’avance. Vous ne savez pas si vous allez gagner, et si vous ne gagnez pas, c’est une perte. »

Même si vous êtes un développeur non affilié qui créez du code open source sur votre temps libre, les besoins en temps ne cessent d’augmenter, comme l’explique Luis Villa, co-fondateur de Tidelift. « Les développeurs servent clairement leurs propres intérêts en acquérant des compétences de base en programmation et en relations humaines. Il est moins sûr qu’ils servent leurs propres intérêts en devenant des experts sur des sujets qui, dans leur travail de tous les jours, sont probablement délégués à des experts, comme les questions juridiques, les achats et la sécurité. » Pourtant, le mainteneur d’un projet open source a de plus en plus besoin de penser à la sécurité de bout en bout de son projet, à la licence des fichiers, et plus encore. Cela représente vraiment une somme importante de travail. C’est pourquoi Lyft évalue maintenant s’il faut ouvrir un code source en fonction du succès possible de l'initiative. Il faut pouvoir attirer suffisamment d’intérêt à l’extérieur pour que ça vaille la peine de s’embarquer dans l’aventure. « Je ne suis pas un puriste de l’open source », reconnaît Matt Klein. « Je suis un capitaliste ». Il n’est pas le seul. 

Le pourquoi de l’open source

Nous pouvons louer Facebook et Google pour leurs contributions à des logiciels d'intelligence artificielle open source tels que PyTorch et TensorFlow, respectivement, mais ne nous leurrons pas en imaginant que ces entreprises ont publié ce code par pure bienveillance. Précédemment, j'ai évoqué le cas des entreprises de cloud computing qui utilisent l'open source comme rampe d'accès. Récemment, Alex Engler, membre de la Brookings Institution, a repris cette idée, suggérant que « pour Google et Facebook, la mise en open source de leurs outils de deep learning (TensorFlow et PyTorch, respectivement), peut [avoir l'effet de] les enraciner davantage dans des positions déjà bien solides ». Une demi-décennie après la publication du code, ces sociétés font toujours la majeure partie du développement (ce qui est tout aussi vrai pour AWS et ses projets Firecracker et CDK et Microsoft avec vscode, pour que vous ne pensiez que je montre du doigt Google et Facebook.)

Pourquoi est-ce important ? Parce que l’open source donne à ces deux entreprises un levier stratégique clé à actionner, pointe Alex Engler. « En faisant de leurs projets les outils les plus couramment utilisés dans l’industrie et dans le monde académique, Google et Facebook profitent de la recherche publique qui est menée avec ces outils et, en outre, ils bénéficient d’un canal de data scientists et de spécialistes en apprentissage machine entraînés avec leurs systèmes. Dans un secteur où s’opère une farouche concurrence autour des talents en intelligence artificielle, TensorFlow et PyTorch aident aussi Google et Facebook à renforcer leur réputation faisant d’eux les chefs de file avec lesquels travailler sur les questions IA les plus en pointe ». Je ne suis pas en train de dire que ces entreprises ont tort d’agir ainsi. Je dis simplement que les entreprises n’apportent pas leur contribution au code par charité. Les ressources ont toujours des limites Si une entreprise dépense de l’argent et des ressources pour contribuer à un code, c’est parce qu’elles ont fait leurs calculs et qu’elles pensent qu’elles vont récupérer un retour sur leur investissement.

Deux exemples d’open source capitalistes 

Prenons des exemples. Microsoft, en premier lieu. C’est le plus grand contributeur open source au monde lorsqu’on le mesure en termes d’employés contribuant activement à GitHub. (Oui, je sais, c’est une façon imparfaite de le mesurer. Si vous avez de meilleures idées, cela m’intéresse). Pourquoi le fait-il ? Il y a quelques années, j’ai soutenu assez souvent que « l’open source est ce que font les outsiders pour gagner ». En dépit du poids qu’il avait sur le poste de travail et dans les datacenters d’entreprise, Microsoft avait « une erreur d’arrondi » dans le cloud. L’un des moyens que l’éditeur de Redmond a trouvé pour gagner l’amour des développeurs et s’offrir une place à la table du cloud a été de se métamorphoser pour passer du statut de paria à celui de héro de l’open source. Cela lui a pris des années, mais cela lui rapporte des dividendes en termes de croissance de parts de marché pour Azure.

Prenons maintenant l’exemple de Google. Au-delà de ses projets de grande envergure comme Kubernetes (une salve d’ouverture dans la guerre du multicloud, qui est devenu un point d’entrée concurrentiel pour Google) ou Android (qui a aidé à débloquer le verrou d’Apple sur le marché des smartphones), Google a également été prompt à nouer des partenariats avec des entreprises open source. Mais ce travail, ainsi que l’a dit en 2019 le directeur open source de Google Chris DiBona, ne résulte pas d’une « sorte d’accord magique généreux ». C’était une façon « de donner aux clients ce qu’ils voulaient ». A ce moment-là, cela s’est également avéré être un moyen pour positionner efficacement Google face à son concurrent AWS.

Quid d'AWS ?

Et qu’en est-il d’AWS ? Amazon Web Services a sans doute eu moins besoin d’ouvrir son code. Pourquoi ? En tant que leader du marché cloud, tout ce qui pourrait potentiellement aider ses concurrents à le rattraper n’obtiendrait probablement pas d’approbation au sein de l’entreprise, à moins qu’il n’y ait une valeur stratégique primordiale à le faire. Examinons sous cet angle le cas de Firecracker, un nouveau type de technologie de virtualisation utilisée pour un service serverless comme Lambda. Lorsqu’il a été annoncé, les représentants de l’entreprise ont indiqué : « Alors que nos clients adoptaient de plus en plus le serverless, nous nous sommes aperçu que les technologies de virtualisation existantes n'étaient pas développées pour optimiser la nature événementielle et parfois éphémère de ce type de charges de travail. Nous avons perçu le besoin de développer une technologie de virtualisation spécifiquement conçue pour les traitements serverless ».

Je ne faisais pas partie de l'équipe qui a sorti Firecracker, je n’ai donc pas de connaissance interne sur le raisonnement qui a été fait. Mais ces deux phrases suggèrent que l’entreprise espère que plus de Firecracker équivaut à davantage d’adoption du serverless ce qui, vraisemblablement, augmentera l’avance d’AWS sur ce marché. Infâme ? Absolument pas. Mais chez AWS, comme chez Lyft, Microsoft, Google et dans toutes les autres entreprises, on ne verse pas de code dans l’open source à moins qu’il n’y ait une raison business irréfutable. Peut-être que mon ami a raison. Peut-être qu’AWS a besoin de mettre en open source un grand produit phare. Mais s’il le fait, ce ne sera pas parce que AWS veut améliorer sa réputation avec des inconnus sur Twitter (ou des auteurs comme moi). Comme pour Google et les autres, il le fera pour augmenter encore l’adoption de ses produits. C’est ainsi que fonctionne le business (open source).