[7]
Titre : Logiciel libre et innovation ouverte : un modèle de développement néguentropique
Intervenant : Thierry Carrez - OpenStack
Lieu : Académie d'été de philosophie - Épineuil-le-Fleuriel
Date : Août 2015
Durée : 1 h 01 min 25
Visualiser la conférence [7]
Licence de la transcription : Verbatim [8]
Transcription
Bonjour à tous. Bienvenue. J'ai la lourde tâche de faire la dernière présentation. Ça va être un peu moins technique que celle de Christian. On va parler de collaboration, on va parler de logiciel libre, une assez longue digression sur le cloud computing. Ça devrait bien se passer, je pense.
En exergue de cette discussion, j'ai ce proverbe africain qui résume pour moi la valeur de la collaboration, de la coopération, proverbe qui dit : « Si vous voulez aller vite, vous cheminez seul. Si vous voulez aller loin, vous cheminez ensemble ». Je pense qu'il y a aussi une intéressante réflexion sur la vitesse, puisque, en gros, pour une vision à long terme, il faut cheminer ensemble et non pas seul. Contrairement aux précédents intervenants, y compris mon illustre prédécesseur, je ne cite pas de philosophes, parce que je ne suis pas un philosophe ; je suis un ingénieur et je ne suis même pas un philosophe-ingénieur. C'est très décevant. J'habite Épineuil, donc Bernard m'a un petit peu invité en voisin pour parler de ce sur quoi je travaille. Dans les quatre jours qui ont précédé, on m'a demandé souvent : « Qu'est-ce que tu fais ? » et j’explique : « Il va falloir une heure pour expliquer ». Là voilà, l'heure pour expliquer.
Pour moi c'est une expérience sociologique d'organisation, qui a maintenant cinq ans, sur laquelle un retour d’expérience est maintenant possible. On manque beaucoup de solutions pratiques, néguentropiques, on manque de scénarios alternatifs, on manque d’organologie pratique, comme le disait Bernard, ou de traductions en économie des principes sur lesquels on a eu cette réflexion toute cette semaine, et, à mon avis, ce projet est un bon exemple pratique, existant, fonctionnant dans le monde actuel, pas forcément comme un des plans sur la comète sur la blockchain 2.0. Donc on va un petit peu parler de détails.
Qu'est-ce que je fais actuellement ? C'est assez difficile à expliquer parce que cela mobilise un certain nombre de concepts qui sont étrangers à la plupart des gens, et c'est pour ça qu'il faut une heure pour expliquer. Je coordonne le développement mondial, en logiciels libres et en innovation ouverte, d'un ensemble de logiciels, permettant de fournir une infrastructure de type cloud computing. Donc ça fait beaucoup de concepts.
Public : Vous pouvez le redire ?
Thierry Carrez : Ouais. Donc je coordonne le développement mondial, en logiciels libres et en innovation ouverte, d'un ensemble de logiciels, permettant de fournir une infrastructure de type cloud computing. Je dois le lire sinon je n'y arrive pas. Donc beaucoup de concepts étranges, et pour expliquer vraiment le détail du projet, je vais d'abord expliquer ce que j'entends par infrastructure de cloud computing, et ce que j'entends par logiciel libre et innovation ouverte. Comme ça vous aurez le thème et la manière de faire, et ensuite on parlera du projet.
Tout d'abord qu'est-ce que j'entends par cloud computing ? Pour le grand public, le cloud computing ça va être le stockage en ligne, on va dire. Pour cet auditoire c'est plutôt le big data, l'arme du capitalisme computationnel. Mais pour moi, stockage en ligne tout comme big data, sont deux conséquences, deux conséquences parmi d'autres du cloud computing qui est une technologie. Et pour expliquer ça, je vais d'abord un petit peu replacer cette idée dans un contexte technologique, un contexte de marché, ce qui se passe actuellement dans le domaine de l’informatique, mais aussi, en général, sur l'évolution des technologies.
Une nouvelle fois, je ne suis pas un philosophe, je cite des ingénieurs. Marc Andreessen est un ingénieur informatique, créateur de Netscape dans les années 90, qui est devenu depuis venture capitalist à succès de la Silicon Valley, très influent, qui a fondé Andreessen Horowitz, qui est une grosse firme de venture capital de la Silicon Valley. Il a déclaré en 2011 que le logiciel mangeait le monde. Quand vous entendez « le logiciel mange le monde », vous pensez sans doute à Google, qui est une société purement informatique, machine à générer des protentions automatiques, dont l'impact sur nos vies quotidiennes a été le plus significatif. Tout le monde recherche sur Google et donc, par extension, le contrôle et le pouvoir qui en dérive, est le plus inquiétant. Mais quand Andreessen parle de dévorer le monde, il ne pense pas vraiment à Google. Il pense plutôt à Amazon. Donc Amazon, qui est une société principalement logicielle, qui a révolutionné une industrie en place, celle de la distribution de biens et de services, sans posséder un seul magasin. Qui n'a pas acheté quelque chose sur Amazon ? Levez la main. Ah ce n'est pas mal. Vous êtes bien !
Public : Inaudible.
Thierry Carrez : C'est assez pratique, hein ! Moi-même, je consomme beaucoup d'Amazon. Mais ce n'est pas le seul exemple d'industrie de logiciels qui a mangé le monde. Donc Uber et Lyft, qui sont les deux plus grosses applications de partage de transport dans le monde, ont fait chuter de 65 % le nombre de voyages en taxi dans la ville de San Francisco depuis le moment où ils se sont installés. Donc ils ont, effectivement, complètement annihilé une industrie en place, qui est en place depuis très longtemps.
Airbnb, qui est donc une société de listing de bed and breakfast ou de chambres que vous pouvez partager chez vous, va loger chaque nuit de cet été 800 000 personnes. Pour se donner une idée, Accor, le groupe Accor qui est le gros fournisseur de chambres d’hôtel, c'est 450 000 chambres d’hôtel. Même en supposant qu'ils les remplissent toutes, toutes les nuits, ils n'arriveront pas au niveau de Airbnb, qui donc arrive à ces niveaux-là sans posséder un seul hôtel, juste avec du logiciel.
Netflix, c'est 50 % des 15 ans 35 ans aux États-Unis qui sont abonnés. Il y a toute une génération exposée à Netflix plus qu'à toute autre solution. Et derrière tous ces concepts, derrière toutes ces entreprises, il y a l'idée que le logiciel n'est plus une spécialité. Ce n'est plus, on va dire, quelque chose que certaines personnes dans l'entreprise font, c'est vraiment une fonction organique de l'entreprise. De la même manière qu'au début du 20e les entreprises, les usines, avaient un service électrique pour fabriquer de l'électricité. Eh bien nous, dans le 20e siècle, on a eu des services informatiques pour fabriquer de l'informatique, en quelque sorte.
Et dans ces entreprises, il n'y a pas de service informatique. Ce sont des entreprises qui respirent l'informatique dans l'ensemble des fonctions de l'entreprise. Et ce qui rend possible cela, c'est l'évolution de la technologie informatique. Donc toute technologie suit cette courbe de maturité qui a été formulée par Simon Wardley, qui est un analyste de l'innovation. En gros, elle devient de plus en plus définie, de plus en plus certaine, et, dans l'autre sens, de plus en plus diffusée. Toute technologie va évoluée dans cette courbe, toujours vers plus de définition et plus de diffusion, mais plus ou moins rapidement. Elle peut rester bloquée pendant des dizaines d'années à un certain stade, etc., mais ça va toujours dans le même sens.
Elle commence comme innovation, comme quelque chose qui va être des prototypes, de la recherche, des versions fabriquées de bric et de broc et, à partir du moment où elle a atteint un certain niveau de certitude, on va passer dans une phase de productisation, qui est une phase de différenciation, et une phase de diffusion. Donc typiquement, on va avoir beaucoup de versions différentes de cette technologie-là qui seront accessibles, pour essayer d'atteindre le plus grand nombre.
Et puis, à un moment, on arrive à une commodité, on arrive à un niveau de définition de la technologie qui est tel que les gens n'arrivent plus à se différencier sur le produit, et le produit devient standard, il devient universel, il devient consommé à la demande, il devient payé à l'usage. Et c'est la fin de cette technologie-là. Et une fois qu'elle est devenue une commodité, elle va nourrir une nouvelle vague d’innovations, elle va être tellement utilisée en tant que commodité qu'elle va nourrir de nouvelles vagues d'innovations et de nouvelles technologies.
Si on prend des exemples, l’électricité est tout au bout de cette chaîne. Quand vous branchez quelque chose sur une prise électrique, vous savez que vous allez obtenir du 220 volts, qui ne va pas être vraiment différent s'il est produit par EDF, par GDF, ou je ne sais qui. C'est une fonction qui est universelle, à la demande, payée à la demande, et présente partout, sur laquelle on peut compter, comme l'eau du robinet, dans nos pays.
La voiture, elle, est plutôt au milieu de cette courbe. Elle a du mal à avancer vers une commodité puisqu’elle joue sur des réflexes humains qui sont le plaisir de conduire, ma voiture est plus belle que la tienne, etc. Pour l'instant elle a du mal, elle cale dans cette phase de productisation, on continue à faire des voitures différentes. Pourquoi ? On ne sait pas très bien. Il y a un moment où ça va devenir une commodité, un moment où les voitures automatisées vont se balader dans les villes, et puis vous rentrerez dedans, vous lui direz : « Je veux aller là », elle ira là-bas. Et Google a déjà, si vous passez souvent en Silicon Valley comme je le fais, vous allez croiser des voitures qui n'ont pas de conducteur et qui sont des espèces de petites bulles dans lesquelles vous pouvez rentrer et lui dire où vous voulez aller. C'est assez flippant !
Le voyage spatial est en train de sortir de l'innovation. On a des sociétés comme SpaceX qui sont en train d'industrialiser, un petit peu, le lancement de satellites, le voyage spatial, avec des fusées réutilisables, avec des fusées qui se reposent sur leur socle. Transformer quelque chose qui était purement de la science-fiction, de la recherche, en quelque chose d'industriel et de réalisable. Donc on est au tout début de la phase de produits pour le voyage spatial.
L'informatique, elle est là. Elle en est à la fin de la phase des produits. Elle est dans l'entrée de la phase de la commoditisation. Quand je dis l'informatique, ce sont des serveurs, des serveurs virtuels, des unités de traitement, de l'espace de stockage. Et on est en train de rentrer dans cette phase où elle devient une commodité. C’est-à-dire que les gens la consomment, de manière un petit peu indifférenciée, universellement accessible, consommée à la demande, payée à l'usage. Et c'est ça le cloud computing. Le cloud computing c'est cette transition entre cette phase de produit, cette industrie de produit, vers une industrie de services et de commodités, pour l'informatique. Donc c'est l'évolution naturelle de la technologie informatique, en quelque sorte. Ce n'est pas bon ou ce n'est pas mauvais en soi. Le problème avec le cloud computing aujourd'hui, ce n'est pas la technologie vraiment. En tout cas, c’est ce que je postule ici. C'est que c'est assez difficile à mettre en œuvre, c'est assez compliqué, ça demande de gros investissements. Généralement, il va falloir que vous construisiez des datacenters. Au lieu d'avoir chacun votre petite salle serveurs dans votre petite entreprise, et que le truc n'est pas très bien réfrigéré, et puis l'informaticien local qui rame un peu pour que ça tourne tous les jours, eh bien vous allez louer de la ressource informatique, à la demande, au moment où vous en aurez besoin, à quelqu'un. Ou alors vous allez avoir un service dans l’entreprise, mais qui sera purement dédié pour fournir ça pour le reste de l’entreprise, fournir de la ressource brute pour le reste de l’entreprise.
Donc, comme ça demande de gros investissements, là on voit ici une image d'un datacenter de Facebook, ce pouvoir est aujourd’hui, le pouvoir du cloud computing, cette nouvelle évolution de l’industrie informatique, est centralisé entre les mains de quelques puissants. Donc on a de très gros clouds privés qui servent les intérêts de Google et de Facebook. Christian parlait de containers tout à l'heure. Chaque semaine Google lance deux milliards de containers sur ses datacenters, c'est-à-dire va relancer des espèces d'unités de traitement, en continu, sur une informatique qui est un petit peu dématérialisée. Ils sont très en avance dans ces domaines-là. Et donc, finalement, tout l'aspect négatif du cloud computing pour cet auditoire, c'est le fait que cette technologie-là est utilisée exclusivement, aujourd’hui, pour produire des rétentions tertiaires, pour produire ces profils marketing qui vont servir uniquement les intérêts de Google et de Facebook au lieu de, potentiellement, pouvoir être utilisée, utiliser cette même technologie pour faire des choses plus intéressantes.
Alors il y a des clouds privés. Comme je vous le disais, Google, Facebook ont leurs propres datacenters. Il y a aussi ce qu'on appelle des clouds publics, qui sont construits pour permettre de louer de la ressource, permettre à d’autres de louer de la ressource. Les startups en Silicon Valley, en général aujourd'hui, n'achètent plus de serveurs, plus jamais. Elles louent de la ressource à un cloud public qui leur fournit, qui a installé le datacenter pour elles, si vous voulez. Elles consomment à la demande. Si ça marche bien elles en consomment plus, si ça marche moins bien elles consomment moins, etc. Mais ces clouds publics, qui sont donc une manière de donner l'accès à cette technologie au plus grand nombre, il y a aujourd'hui un quasi monopole dans le domaine, dans lequel on retrouve nos amis d'Amazon. Vous ne connaissez peut-être pas Amazon Web Services, mais c'est 8 % du chiffre d'affaires d'Amazon, c'est la seule division profitable d'Amazon. Il faut savoir qu'Amazon ne fait pas de profits. Une raison pour laquelle ce n'est pas cher, ils captent, ils captent. C’est une boîte qui ne fait pas de profits. La seule division qui fait des profits c'est celle-là. Ils ont un ensemble qui est dix fois plus gros que leur quatorze concurrents suivants. Christian disait Microsoft, IBM, Google, etc. Amazon est dix fois plus gros que tous les autres combinés en termes de nombre de serveurs installés. Donc aujourd'hui, en fait, si vous demandez à une start-up de Silicon Valley qu'est-ce qu'ils utilisent pour leur informatique, ils vont répondre Amazon Web Services, dans 99 % des cas.
Aujourd’hui on se retrouve avec cette évolution technologique qui est asservie par les puissants dans quelques plates-formes fermées, ou par un monopole de la fourniture, de la ressource pour les autres. Mais pour moi le cloud computing est vraiment un pharmacon, c'est-à-dire qu'il peut être aussi utilisé pour guérir le problème. On voit le mal, aujourd'hui, cette technologie qui est utilisée uniquement par les puissants, mais, en fait, on peut utiliser cette même technologie pour résoudre le problème.
La solution c'est de démocratiser cette technologie, en la rendant accessible au plus grand nombre, d'avoir plein de tout petits clouds locaux, interopérables, de territorialiser le cloud computing. Et c'est le but du projet sur lequel je travaille, et le moyen d'y arriver, c'est le logiciel libre et l'innovation ouverte. Donc, on va donc maintenant passer à la deuxième partie, le logiciel libre.
Je suppose que dans cette assemblée il y a pas mal de gens qui savent déjà ce que c'est, mais je vais retracer ça un petit peu de manière pratique.
Le logiciel c'est un ensemble de code, d’instructions. À partir des années 70 est apparu le concept de logiciel propriétaire. Il faut savoir que ça n’existait pas avant. Avant, on échangeait le code qui était exécuté par les machines. À partir des années 70, on a diffusé une forme compilée, prête à être exécutée, où on ne diffuse plus les instructions elles-mêmes, mais le programme sous une forme qui est prête à être exécutée. On garde le code source comme un secret de fabrication, en quelque sorte, comme une étape intermédiaire. Et on restreint énormément comment ce logiciel a le droit d’être utilisé. C'est-à-dire on va dire : « Eh bien, il faut payer pour l'utiliser, il faut payer une licence ». Ou bien, il faut accepter cette longue liste de conditions, que vous cliquez sans même les lire parce que c’est trop long. Il faut les lire, c'est assez édifiant !
En réaction à ce mouvement du logiciel propriétaire est apparu le logiciel libre, ou open source, je reviendrai sur la distinction dans quelques minutes. Le logiciel libre c'est un ensemble de licences très standardisées, ça reste des licences, ce n'est pas un espace de non-droit. Au contraire, à la limite, c’est un espace qui est beaucoup plus précis, légalement, que ne l'est le logiciel propriétaire. Donc un ensemble de licences standardisées, mais qui ont un certain nombre d’éléments en commun. Donc publication du code source, autorisation de la modification, la redistribution, et, en général, absence de restrictions sur la manière de l'utiliser. Vous ne pouvez pas dire : « Vous n'avez pas le droit de l'utiliser si vous êtes, je ne sais pas, Daesh ou je ne sais quoi ». C'est quelque chose qu'on ne peut pas retrouver dans une licence de logiciel libre.
Cette approche qui consiste donc à donner l'accès au code source, à redonner l'accès au code source, a un certain nombre d'avantages pour les utilisateurs. Il y a des limitations de coûts : c'est souvent gratuit, pas toujours, mais c'est souvent gratuit du fait que le code source étant diffusé, eh bien les capacités de vendre le code source sont assez limitées. Quand je parle de coût, c'est aussi un coût légal. Il faut savoir que pour les grandes entreprises, c'est coûteux d'acheter du logiciel propriétaire, parce qu'ils doivent évaluer la licence du logiciel propriétaire, ces grandes choses que nous on clique sans même les lire. Ils ont des services légaux qui passent leur temps à essayer de décortiquer si c'est quelque chose que leur entreprise peut accepter ou pas. Généralement il y a marqué « quoi qu'il vous arrive en utilisant le logiciel, ce n'est pas ma faute, etc. » Et, pour une entreprise, c'est très coûteux la consommation de logiciels propriétaires.
Il y a une capacité à auto diagnostiquer et à corriger soi-même. Ça, je pense que c'est le gros point qui font que les entreprises, aujourd'hui, adoptent massivement le logiciel libre. C'est cette capacité à « on a des équipes techniques chez nous, eh bien elles peuvent commencer à regarder à l'intérieur du problème, et, potentiellement, proposer un correctif », ce qui est totalement impossible avec le logiciel propriétaire, où la seule alternative est d’essayer d'appeler Microsoft pour dire que votre logiciel ne fonctionne plus. Ça c'est pareil, c'est un truc à essayer : essayez d'avoir Microsoft au téléphone !
La qualité et la sécurité. La qualité parce que, le code source étant publié, eh bien on va avoir tendance à écrire un code source beaucoup plus clair, on va avoir tendance à avoir beaucoup plus de gens qui regardent le code aussi donc, en termes de sécurité, on va avoir beaucoup plus d'analyses de sécurité qui sont faites sur le logiciel libre que sur le logiciel propriétaire, et donc, paradoxalement, ça va conduire à plus de sécurité sur le long terme.
Et enfin, l’absence de lock-in, qui est la possibilité, finalement, si vous n’aimez plus le fournisseur de votre logiciel libre, eh bien vous pouvez toujours prendre le code, continuer à le maintenir vous-même. Vous n'avez pas cette option avec le logiciel propriétaire.
Donc ça, ce sont les avantages pour les utilisateurs, les gens qui vont, comme moi ici, installer Linux sur leur portable.
Pour les développeurs, pour les sociétés qui font du code aujourd'hui, pourquoi faire du logiciel libre ? Pourquoi ne pas garder le code source pour soi, essayer d'avoir une stratégie de monétisation qui va être de le revendre ? Il y a quatre raisons.
Il y a la raison un petit peu officielle, c'est pour être un bon citoyen : j'utilise du logiciel libre, il faut bien que je redonne au mouvement. Voilà. Pratique ! Ça a convaincu une certaine frange de l'industrie, mais, pour aller au-delà, il faut d'autres raisons.
Deuxième raison, c'est l'injection de l’innovation. Ce sont généralement les entreprises qui sont en avance dans la courbe de l'innovation qui vont pousser du logiciel libre parce que, pour elles, plus ça va vite, mieux c'est, parce qu'elles sont en avance sur les autres, si vous voulez. Donc, pour ces entreprises-là, donner, en quelque sorte, ce qu'elles développent, développer ce qu'elles fabriquent, en logiciel libre, est une manière d'accélérer l'innovation dans ce domaine-là, sur lequel elles sont en avance sur les autres.
Il y a l'augmentation de la qualité. Si quelqu'un est en train de coder dans une entreprise en sachant que le code qu'il écrit va, peut-être, être vu par plusieurs millions de personnes le mois prochain, on a tendance à documenter son code, on a tendance à écrire plus proprement. Et un code écrit plus proprement, ou avec des tests, ça a beaucoup plus de qualité.
Et enfin, le recrutement. Il y a une très grosse tension sur le marché du développeur, un petit peu partout dans le monde, et donc, finalement, c'est aussi une vitrine technologique, en quelque sorte : « Regardez tous ces problèmes intéressants sur lesquels on travaille, regardez le code qu'on produit. Vous qui aimez bien le logiciel libre, venez donc chez nous, regardez, on en fait. » Et ça devient, à la limite, le plus important des quatre, aujourd'hui.
Ces quatre raisons, je ne les ai pas sorties de ma tête, c'est, en fait, Facebook qui les a données dans une conférence à laquelle j'ai assistée le mois dernier à Portland. Facebook dit : « Nous, on développe en open source, et voila pourquoi ». Et le recrutement n'est clairement pas le dernier, puisque pour Facebook, recruter ! Ce n'est quand même pas génial Facebook ! Facebook, comme ça, travailler pour de la pub, chez les affreux ! Par contre « ah ! Ils travaillent sur un problème très intéressant. Ce code-là qu'ils ont publié me semble très intéressant ! » Travailler chez Facebook !
Donc un petit historique de l'évolution du logiciel libre. Il est né dans les années 70 sous l'impulsion de Richard Stallman, en réaction à l'apparition, dans ces années-là, du logiciel propriétaire, comme je l'ai déjà dit. Il avait défini quatre libertés fondamentales : liberté d'exécuter le programme, liberté d'en étudier le fonctionnement, liberté de redistribuer des copies, liberté de distribuer des versions modifiées. Donc ça, ça a très bien marché dans les années 70. Mais cette définition qui est purement orientée sur les libertés, en quelque sorte, du consommateur du produit, n'était pas un langage qui parlait vraiment, on va dire, à l’entreprise informatique standard. Et donc, il y a une autre formulation qui est arrivée, qui est la formulation de l'open source, vers la fin des années 90, qui insiste plus sur la publication du code, sur la licence, que sur la liberté fondamentale, en quelque sorte. Et c'est une lecture qui est, en gros, de la même chose, c'est une autre manière de présenter les choses, mais ça a été beaucoup plus facilement accepté par l'entreprise que cette chose où on dit : « Voila tout ce que vous allez avoir le droit de faire ». Cette approche-là décrit techniquement ce que ça veut dire, mais ne rentre pas dans le détail des libertés. Ce sont les mêmes licences qui sont utilisées dans les deux cas, en gros.
En résultat de cette démocratisation, et aussi de ce moment dans l'innovation technique, ça a été massivement adopté par l’industrie : le logiciel libre a été massivement adopté par l'industrie au cours des dix dernières années, en particulier sous la forme de la licence Apache 2.0, qui apparaît à gauche sur cette petite scénette, qui permet de redistribuer des versions modifiées, sans en publier le code source. L’entreprise peut prendre un logiciel libre, s'appuyer sur un logiciel libre, le customiser, et vendre cette version-là en code propriétaire. Donc c'est une licence très permissive.
Si on regarde un petit peu comment ces choses-là sont produites : le logiciel propriétaire c'est comme ça, c'est fermé. Les gens qui le produisent sont tous des employés de la société qui produit le logiciel propriétaire, et c'est comme ça.
L'open source, on arrive plus à un schéma comme ça : c'est perméable, donc on peut contribuer. Et on va avoir des contributions à la marge, plus ou moins de contributions sur ses côtés, en fonction du degré d’ouverture du projet, en fonction de plusieurs aspects. On se retrouve avec plein d'entreprises comme ça, créées autour d'un projet open source. On les voit, à chaque fois, au cœur. Vous voyez il y a le cœur violet, il y a le cœur bleu, il y a le cœur vert, on voit qu'il y a quand même une espèce d'entreprise, derrière, qui s'est construite pour piloter le projet open source et qui agrège, un petit peu, ces contributions extérieures.
Donc il y a des aspects positifs à ce modèle-là. On est sur un modèle contributif ; on est toujours sur du code qu'on peut regarder ; on est toujours sur une extension du savoir-faire, d'avoir que l'utilisateur du logiciel puisse aussi être le producteur du logiciel. On n'est pas sur des systèmes bloqués. On produit de la connaissance ; on ne produit pas un système bloqué, un produit fini. Mais ce modèle-là a des aspects négatifs.
Déjà, il y a duplication d'effort, puisqu'il y a plusieurs entreprises qui, chaque fois, pilotent un logiciel libre en particulier, eh bien il peut y avoir de la concurrence. La duplication d'effort c'est typiquement entropique. Le logiciel propriétaire a énormément de duplication d'effort. Le logiciel libre a un petit moins de duplication d'effort, mais il y a toujours de la duplication d'effort. Ici, s'il y a bien quelque chose qui est bête dans un monde où, je dirais, toutes les ressources devraient être consommées pour produire une innovation distinctive, eh bien on continue à avoir des entreprises qui, les unes à côté des autres, essayent d'inventer la même chose. Ce qui est assez bête !
C'est aussi difficile de construire une communauté avec ce modèle-là puisqu'il y a toujours, on le voit bien, un cœur dans lequel on ne peut pas vraiment rentrer. Il y a toujours une entreprise qui bénéficie plus de votre travail que vous, ce que vous retirez de la contribution que vous y mettez. Donc il y a une difficulté pour obtenir des contributions stratégiques. Vous n'allez pas avoir des contributeurs qui vont vraiment participer complètement, dans votre projet. Et puis, on voit que c'est un modèle qui est très centré sur l’entreprise. Donc il y a la tentation de se servir de la version open source comme d'un produit d'appel pour vendre une version étendue, un petit peu plus évoluée. Et puis, à partir du moment où c'est à la mode, c'est à la mode aujourd'hui, il y a aussi le besoin de dire qu'on est open source, même si on ne l'est pas. On va essayer de mettre des frontières autour de notre projet pour éviter que les gens contribuent vraiment au projet, mais au capital risque on va leur dire : « Oui, nous on est open source, bien sûr ». C'est une espèce de label, maintenant, on appelle ça le open-washing. On lave plus blanc !
La réponse à tous ces problèmes de l'open source , c'est ce qu'on appelle l'innovation ouverte, l'open innovation. Comment ça fonctionne ? On a un projet open source, on le place sous le contrôle d'une fondation à but non lucratif, qui crée une espèce de terrain de jeu neutre pour toutes les entreprises qui vont contribuer au projet. Ça ne favorise personne ; il n'y a pas une entreprise, au centre, qui va tirer les marrons du feu. On est vraiment sur essayer de faire en sorte que personne n'ait un avantage. On n'interagit avec le projet que via sa contribution. Ça sépare le développement, la partie technique, de la stratégie de monétisation de chacun des acteurs. Parce que dans le modèle précédent, il y a clairement un des acteurs qui est favorisé, qui a une stratégie de monétisation directement. Et ce modèle-là permet de séparer complètement le développement, la partie technique, les développeurs, de la stratégie de monétisation que chaque entreprise peut avoir à participer à ce jeu en commun.
Sur ce terrain de jeu, on laisse les développeurs collaborer. On n'a pas de manager. On va avoir des développeurs, des ingénieurs, qui vont participer au projet. À ce moment-là les frontières, leurs chapeaux, on appelle ça les chapeaux, le chapeau qu'ils portent, qui représente leur entreprise, très vite, disparaît. Et au final, on obtient une plus grande participation, évidemment, puisqu'il n'y a plus la personne qui bénéficie du projet et puis les dindons de la farce. On a une absence de la duplication d'effort, puisque tout le monde peut participer au même projet. Et généralement, le résultat c'est qu'on s’aperçoit que les gens s'agglutinent sur les mêmes projets, plutôt que sur des projets en parallèle.
On voit une image d'une de nos rencontres, ici. Donc ce sont des développeurs qui sont au centre du jeu, et ça c'est un des aspects, j'y reviendrai un petit peu plus tard dans la présentation. En gros, c'est à travers eux que l'entreprise peut pousser ses priorités dans le projet. L'entreprise ne peut pas dire : « Je veux qu'il y ait ça qui arrive ». Elle va être obligée de pousser des développeurs dans le projet qui vont, dans ce terrain de jeu ouvert, pousser ces objectifs-là. Le développeur se retrouve vraiment au centre du jeu, là où, avant, il était un petit peu dilué sous des strates de management. Ça les responsabilise, ça les rend plus autonomes, ça les rend, aussi, beaucoup plus productifs.
Et enfin, le dernier avantage de cette approche, c'est la promesse de la standardisation, puisqu'on est déjà sur une collaboration entre les acteurs qui sont dans ce domaine-là, et donc, finalement, quand on doit se mettre d'accord sur le standard à utiliser, eh bien c'est beaucoup plus simple si on est déjà à 90 % en train de collaborer sur la même chose.
Donc on a vu, un peu, un fleurissement de ce modèle-là : c'est l'ère des fondations, actuellement. On a beaucoup de ces fondations à but non lucratif, qui se créent autour d'un projet open source, justement parce que ça résout les problèmes qui étaient là avant, au point, d’ailleurs que maintenant il y a un peu du foundation washing, puisqu'il y a certaines fondations qui prétendent être ouvertes, mais qui ne le sont pas vraiment. Ce qu'il faut voir c'est que c'est l'option des challengers. Typiquement, il va y avoir une entreprise qui va être très en avance sur le marché, et toutes les autres entreprises de ce secteur-là, plutôt que d'essayer de faire la compétition, la course derrière et de ne jamais rattraper, vont avoir tendance à se mettre ensemble pour essayer de rattraper le ou les gros.
Le dernier aspect que je voulais dire sur l’innovation ouverte, c'est que, aujourd’hui, on n'en est plus à savoir s'il faut y participer ou pas y participer. Il n'y a plus un avantage à y participer contre tous ceux qui n'y participent pas. Aujourd'hui, c'est ceux qui jouent le jeu le mieux, qui collaborent le mieux, qui participent le mieux à cette forme d'économie, qui en tirent le plus. Donc le nouveau challenge, pour ces entreprises-là, ça devient comment bien collaborer dans ces projets-là. Ce n'est plus « est-ce qu'on doit y aller ou est-ce qu'on ne doit pas y aller », c'est « comment faire pour bien interagir avec cette forme-là ? » Donc il y a un petit peu un domaine d'expertise qui se développe. On recrute beaucoup, tous les gens qui ont un petit baigné là-dedans depuis quelques années pour, en quelque sorte, traduire pour l'entreprise « mais comment je joue à ce jeu-là ? » Ça a l'air assez compliqué.
C'étaient les deux premières digressions : le cloud computing, qui est donc le sujet du logiciel sur lequel on travaille, et le mode de production qui est donc l'innovation ouverte.
Le projet sur lequel je travaille s'appelle OpenStack1. C'est donc une fondation à but non lucratif. Le projet a été établi en 2010, la fondation un petit plus tard, et donc on est sur ce modèle d'innovation ouverte. Le but, je répète ce que j'ai un petit peu déjà dit, c'est de créer un ensemble de logiciels, que n'importe qui pourra mettre en œuvre, pour présenter sa propre ressource informatique comme une commodité, et donc bénéficier de l'évolution de l'informatique qu'on appelle le cloud computing. En gros ça vous permet d'acheter des serveurs, et d'installer ce logiciel-là au-dessus, et de présenter votre ressource informatique au reste des gens qui vont la consommer, au reste des services de l’entreprise, au reste du monde, comme des ressources directement adressables, avec les technologies du cloud computing.
Le projet a été créé avec un certain nombre de principes qu'on appelle les quatre open.
Donc open source, c'est évident, mais ça veut aussi dire qu'on ne fera jamais d'open core, qu'il n'y aura pas de version avancée qui sera payante ou quoi que ce soit, tout est en open source.
Open design, qui est le principe sur lequel j'ai le plus insisté, moi, à la création du projet : c'est le fait que le design du projet, la fabrication, la manière dont on fait l’architecture du projet, n'est pas décidé par un groupe de personnes qu'on ne voit jamais, dans une tour d'ivoire. On a, tous les six mois, une réunion où on a ces discussions sur toutes les choses qu'on a envie d'attaquer sur les six prochains mois. Et on a des discussions comme sur cette image ici un petit peu décalée, où c'est à bâtons rompus, c'est un peu comme ici, mais sans le micro, où on va se mettre d'accord. Et là, les gens sont tous d'entreprises d'horizons différents, d'organismes différents. Ça peut être des utilisateurs de logiciels, ça peut être des boîtes qui vont vendre du service sur le logiciel, ça peut être des gens curieux. Et tous ceux qui sont intéressés par le sujet discuté vont se rejoindre dans ces salles, et on va essayer de faire avancer le schmilblick.
Il y a ce qu'on appelle l'open development. C'est le fait que toutes les étapes du développement sont visibles sur Internet, sont publiées. Donc vous voyez différentes choses, là c'est bien trop petit pour que vous puissiez voir quoi que ce soit, mais il y a la liste des fonctionnalités sur lesquelles on est en train de travailler, sur la gauche. Sur la droite, le système de revue de code, qui, lui, est aussi totalement public. N'importe qui peut venir, regarder un changement qui est proposé et dire : « Ça ce n'est pas bon, tu devrais faire comme ça, etc. » Et tout en bas à gauche, c'est notre système d'intégration continue qui, lui aussi, est complètement public, donc on peut voir les patchs qui sont en train de rentrer dans le code.
Cette transparence, ça conduit à faire en sorte que les gens puissent très facilement rentrer dans le projet. C'est-à-dire qu'il n'y a pas de frontière. À un moment, ils peuvent déjà regarder comment ça fonctionne à l'intérieur et se familiariser avec tout le procédé sans avoir besoin de signer quoi que ce soit.
Le dernier aspect, c'est communauté ouverte. C'est le fait que l'ensemble de nos discussions, l'ensemble de nos réunions, l'ensemble de nos interactions, sont publiées sur Internet, ouvertes. Alors ça fait flipper un certain nombre de gens, surtout dans certaines cultures, mais une fois qu'on est habitué, c'est assez gratifiant. L'avantage c'est que l'ensemble des discussions est documenté. On essaie de faire en sorte qu'il n'y ait pas d'appels téléphoniques où les gens se mettent d'accord dans un coin, parce que ça exclut forcément tous ceux qui n'ont pas pu appeler au bon moment. La terre étant ronde, malheureusement il y en a qui dorment pendant que d'autres sont debout, et donc c'est extrêmement important qu'on ait ces discussions sur des canaux publics, sur lesquels on génère des logs : les gens qui ont loupé le meeting de la semaine dernière parce qu'ils étaient en vacances, peuvent regarder ce qui s'est dit.
Voilà donc les quatre principes.
En termes d'organisation dans le développement, eh bien on a un certain nombre de développeurs qui écrivent les changements proposés au code. On a des gens qui se spécialisent un petit peu dans la revue de code, qu'on appelle les reviewers. La revue de code, ce sont les gens qui regardent si ce qui a été écrit a l'air d’être bien écrit, qui disent : « Ouais, c'est bon ou ce n'est pas bon ». Et quand ces gens-là sont d'accord, quand on a, en gros, deux des reviewers qui disent : « C'est bon, ça a l'air d’être correct », on va pousser le changement proposé sur une batterie de tests automatisés ; et si ça passe ces tests automatisés, ça rentre dans le système. On fait ça sur un certain nombre de projets en parallèle.
En termes de leadership, c’est là que ça devient intéressant : n'importe quel contributeur au projet, il suffit d'écrire un changement pour le projet, va participer à l'élection du leader technique du projet qui s'appelle le PTL [Project Team Leader, NdT]. C'est un modèle où on va élire nos propres leaders techniques avec, comme droit de vote, en quelque sorte, la contribution.
Cette personne est à même de prendre une décision, quand une décision doit être prise. Il peut arriver qu'il y ait un conflit de deux factions qui s'affrontent sur une décision. Il faut avoir, en tout cas c'est mon opinion, avoir quelqu'un qui puisse, en dernier recours, faire en sorte qu'une décision soit prise. Ce dont on s’aperçoit, ça c'est assez intéressant, c'est que quasiment jamais ces leaders techniques ont besoin de prendre ces décisions-là. Juste le fait qu'ils existent, le fait que quelqu'un va prendre la décision si les gens ne se mettent pas d’accord entre eux, les gens se mettent d'accord, en fait. On a, en quelque sorte, une évolution assez intéressante où le leader technique n'est plus vraiment un leader technique, c'est plus une espèce de soupape de sécurité, et il se spécialise plus dans un rôle d'ambassadeur, maintenant, le leader ; d'ailleurs on ne dit plus leader technique, on dit leader d'équipe. Il va faire en sorte que le projet communique bien avec les autres projets, plutôt que de prendre les décisions pour tout le monde. Donc on n'est pas dans un système de dictature, on est plutôt un système de valve de sécurité.
Et enfin tous les contributeurs, quels qu'ils soient, élisent un groupe, dont je fais partie, qui est le comité technique, qui est en charge, je dirais, de l'identité du projet, en quelque sorte. Vérifier d'accepter de nouveau projets, de faire en sorte qu'on garde cette culture avec ses quatre open, etc.
Donc voilà un petit peu comment c'est construit. Ça marche plutôt bien. Là on voit une liste des sponsors de notre sommet qu'on a fait à Hong-Kong en 2013. Si vous regardez un petit peu les noms, ça a attiré la plupart des challengers, des gens qui étaient un petit peu en retard sur le cloud computing. Vous remarquerez qu'Amazon n'y est pas, pour une bonne raison, c'est qu'en gros, cette communauté va se battre contre Amazon. Amazon c'est l'objectif : casser le monopole d'Amazon dans le cloud public. Donc voilà on a IBM, on a HP, on a Intel, on a même Google maintenant, on ne sait pas très bien pourquoi.
En termes de nombre de développeurs, on a développé une communauté virtuelle et globale de développeurs. Sur la dernière release qu'on a faite, qui sont les six mois avant avril 2015, on a eu à peu près 2000 développeurs qui ont contribué. Pour donner une idée, c'est assez massif, il y a peu d'entreprises dans le monde qui ont 2000 développeurs qui travaillent sur un projet, et c'est dans le monde entier, et c'est uniquement connecté virtuellement par e-mails, par IRC et autres outils.
En termes de nombre d'entreprises, nombre d'organisations qui contribuent, on voit qu'on est aussi en constante augmentation, et c'est 160. On est arrivé, sur le dernier cycle de release, à avoir 160 organismes différents qui contribuent aussi au système. Quand on parle de collaboration ouverte, ce n'est pas juste pour dire « oui, on peut collaborer ». C'est que, en fait, cette collaboration arrive, c'est-à-dire qu'on a vraiment 160 organismes qui contribuent à la même technologie, plutôt que de contribuer à leur propre version de cette technologie-là.
En termes d'activité, alors là ça devient plus technique, on va avoir la courbe bleue qui est le nombre de changements créés, le nombre de changements proposés, et la courbe verte qui est le nombre de changements, en quelque sorte, acceptés. Il y a beaucoup plus de changements proposés, parce qu'on va faire plusieurs versions d'un changement avant qu'il soit accepté, et ça, c'est le nombre de changements qu'on accepte par semaine. Donc si vous regardez, on est, en gros, à 6000 changements proposés par semaine, et à 1000, 1500 changements, inclus dans le logiciel, par semaine. Ce qui en fait le projet de développement open source le plus actif, y compris devant le kernel Linux qui est le plus connu, je dirais, des projets open source. Donc c'est un système d'organisation qui fonctionne bien.
En termes d'adoption, on voit ici les adopteurs en cloud privé, c'est-à-dire ceux qui ont déployé, pour leurs propres besoins, un cloud, déployé, en gros, OpenStack sur des ressources, des serveurs de base, des disques durs qu'ils avaient, pour faire consommer les autres. On s'aperçoit qu'il y a plusieurs grands noms là-dedans, chose assez inquiétante, comme Yahoo qui est un marketeur patenté ; Disney, qui cherche à nous vider le cerveau ; la NSA, aussi, qui est un utilisateur, ils ne nous ont pas trop dit pourquoi, mais on suppose que ce n'est pas pour faire les gentils. Mais à côté de ça on a aussi, et c'est là que c'est un pharmakon, on a aussi Wikipédia. On va aussi utiliser cette même technologie pour aider Wikipédia à servir toutes ces requêtes qu'ils reçoivent du monde entier, pour leurs définitions qui sont de meilleures en meilleures, je dirais, personnellement. En termes de production d’informations, on est sur une information qui est de meilleure en meilleure. Le CERN, qui recherche les secrets de l'univers, est un de nos plus gros utilisateurs.
Donc on est un peu sur un standard de fait. En gros, si vous n’êtes pas Google, Facebook, Microsoft, voilà, eh bien à peu près tous les autres qui ont voulu avoir accès à cette technologie-là, s'appuient sur notre logiciel.
Sur le cloud public, qui est, je dirais, le vrai enjeu pour moi, le problème c'est qu'Amazon a beaucoup d'avance. Amazon est une entreprise qui va très vite, qui fait une très grosse guerre des prix. Ils sont habitués à casser les prix et de ne pas avoir de profits, donc, forcément, pour tous les autres c'est un petit peu difficile de se lancer, mais on quelques petites choses, on va en avoir de plus en plus, on espère. Il y a quelques belles histoires dans cette liste. Kili c'est une entreprise au Kenya. En fait, au Kenya, ils ont une scène de startups très actives, et donc ils ont besoin, pour alimenter les besoins de ces startups, de ces ressources informatiques, sans avoir besoin d'investir dans des serveurs. Problème c'est qu'Amazon c'est assez loin pour eux. Le Kenya, ils n'ont pas des super tuyaux qui sortent du Kenya, et donc, pour consommer Amazon Web Sevices, ça ne marche pas bien. Et donc il y a une petite entreprise qui a dit : « Eh bien ce n'est pas grave, on va faire Amazon Web Services pour le Kenya », et qui a commencé à déployer OpenStack sur des ressources qu'ils avaient achetées. Et ça marche très bien, on est très contents. Pour moi, c'est la success story. Je pourrais m'arrêter là. Si Kili existe, c'est pour ça que je me suis lancé là-dedans !
Cloud&Heat, c'est une autre histoire assez amusante. C'est allemand, ce sont des gens qui déploient des serveurs. Ils ont fait une sorte de datacenter distribué, mais dans les chaudières d'écoquartiers en Allemagne. Et donc ils se servent de la chaleur des serveurs, de l’entropie des serveurs, pour chauffer le bâtiment. Et donc, en fait, ils fournissent en quelque sorte de la ressource, mais ils réutilisent aussi la chaleur.
Finalement, c'est ça un petit peu l'objectif. C’est de dire « non Amazon n'a pas fini de définir le cloud computing. Il y a plein de choses qu'on peut faire, on peut l'installer dans les endroits où Amazon n'ira pas. On peut inventer de nouvelles utilisations qui sont plus intelligentes pour fournir ça. Et tout en donnant l'opportunité à plus que les très gros, Google ou Facebook, d’utiliser ces technologies-là. »
En termes de conséquences inattendues, il y a plusieurs choses que, personnellement, moi je n'avais pas prévues quand on s'est lancé là-dedans, les propriétés émergentes du système. Tout d’abord, il y a l'avènement du développeur-roi. Le fait qu'on ait placé le développeur au centre du système, que le développeur soit, je dirais, la passerelle entre les besoins de l’industrie et le code qui est produit — et puis le succès du projet, parce qu’il ne faut pas se cacher, tous les projets n'ont pas autant de succès — ça a créé une très grosse tension sur le marché du « développeur OpenStack ». Et résultat, les gens ont commencé à pouvoir, un petit peu, dicter leurs conditions à leurs employeurs, puisqu'il y a une telle tension sur le marché que, s'ils ne sont pas contents des conditions d'emploi que leur fournit leur employeur, il est extrêmement facile de continuer à travailler sur exactement le même projet, avec exactement les mêmes collègues, depuis un autre nid, en quelque sorte. Et donc on a énormément de gens — alors il faut voir que ce n'est pas exclusivement salarial, ce sont des gens qui étaient déjà correctement payés où ils étaient, mais ça va être plus sur les conditions de travail — donc énormément de gens qui vont travailler depuis chez eux, y compris moi-même. On va pouvoir, si on a envie de travailler depuis chez soi ou habiter dans une certaine partie du monde, dire : « Moi, si vous voulez m'avoir, ce sera là, et ce ne sera pas autrement ». Et il y en aura toujours un qui prendra. Donc cette tension sur le marché a créé, en quelque sorte, une capacité pour les gens qui interviennent sur ce projet, de sauter d'entreprise en entreprise, en continuant à travailler sur le même projet. Il y en a qui ont déjà changé cinq fois, je crois, en cinq ans. Moi je n'ai pas vraiment changé, parce que j'étais dans la fondation, qui est au cœur du système, qui pilote un petit peu le système. Mais tous ceux qui sont chez un employeur en particulier, eh bien ils sont passés de Rakspace à HP, là ils viennent de passer à IBM. Ça va dans tous les sens. Mais, comme ils disent : « Ça y est, j'ai changé de boulot ; je te revoie la semaine prochaine. » C'est assez amusant !
L'autre conséquence, très inattendue pour moi, c'est la contagion au-delà du code. C'est un système qui est très technique, qui est très orienté développeur, qui est très fait pour générer du code. Et en fait, sans doute comme un effet de bord du fait que le développeur, qu'on ait créé cette espèce de tension sur le marché du développeur, que le développeur soit au cœur du système, ça a poussé d'autres fonctions, qui sont typiquement non contributives dans les entreprises, à se comporter de la même manière. C'est-à-dire qu'on va avoir les gens qui font du marketing qui, typiquement, est une fonction qui est dans chaque entreprise, qui ont dit : « Ah, ça a l’air sympa la manière dont vous faites votre truc-là. Ce qu'on aimerait bien c'est que tous les départements de marketing de toutes les boîtes qui travaillent autour d'Openstack, qu'on se rencontre, qu'on commence à produire en commun, parce que sinon, c'est bête, on fait tous la même chose, autant qu'on partage ce qu'on peut partager. » On voit ça dans le marketing, on voit ça dans le product management. On voit plein de gens qui existent, qui sont très importants dans leurs entreprises, qui sont complètement perdus dans ce nouveau système. Ils voient les développeurs qui sont les nouveaux rois, et eux c'étaient les middle managers. Toute cette ancienne structure dans les entreprises a besoin de s'adapter. Et donc on a beaucoup de demandes, des gens qui font de l'UX [User eXperience, NdT], des études d’utilisabilité des logiciels, par exemple ; c'est une fonction, tous les outils ne sont pas partagés, ils doivent tout inventer. Mais c'est une autre conséquence sur laquelle je suis assez content, c'est qu'en fait on a rendu le modèle suffisamment attractif pour que d'autres fonctions, qui n'ont jamais envisagé de faire ça comme ça, se disent : «Ah ! Ça serait quand même bien qu'on essaye. » C'est peut-être la deuxième conséquence inattendue.
Alors ça ne s'est pas passé, forcément, comme une lettre à la poste, toute cette histoire, il y a un certain nombre de challenges sur lesquels je vais brièvement passer.
Challenge passé, c’était surtout autour de la collaboration, comment on fait pour faire collaborer tous ces gens. Notamment l'absence de direction, l'absence, je dirais de grand maître penseur, de Steve Jobs, qui va dire : « C'est comme ça et ce n'est pas autrement ». On n'a pas vraiment ça, autant dire. Les personnes qui arrivent à avoir le plus d'influence, ce sont les gens qui ont le plus contribué, qui ont prouvé leur valeur aux autres. Les autres ont développé un certain respect pour eux, et on va pouvoir utiliser ce respect comme une manière de les convaincre de faire des choses. C'est comme une monnaie. Moi, j'ai accumulé pas mal de ce crédit de respect au départ. J'en ai pas mal consommé pour essayer de corriger des choses que je trouvais qui n’allaient pas dans le bon sens. Maintenant il faut que je reconstruise mon capital, puisque les nouveaux qui sont là ne me connaissent pas forcément. Donc c'est vraiment basé sur le respect et sur le fait que si cette personne-là, que je respecte, dit telle chose, je pense qu'elle doit avoir raison. On est sur un système où on n'est pas basé sur une nomination, quelqu'un qui est nommé pour avoir la science infuse, mais plus sur un système de contribution qui donne au respect.
Donc, sur cette absence de direction, il faut accepter que ça fait partie intégrante du système. Il faut accepter qu'on va avoir les contributeurs les plus importants qui vont construire cet ensemble d'influence sur les autres et qui vont pouvoir, ensuite, s'en servir pour influencer dans la bonne direction. Mais ça va beaucoup moins vite, pour reprendre le proverbe africain, ça va beaucoup moins vite que si vous alliez tout seul. Et donc, souvent, on a cette tension entre « je sais comment je dois le faire, etc., mais le faire passer par votre usine à saucisses, là, je vais en avoir pour des années. Je préfère le faire dans mon coin. » C'est un des challenges qu'on a rencontrés, surtout au début. Je dirais que maintenant, le long terme a fini par gagner sur le court terme, notamment quand on a commencé à se débarrasser des startups. Il y avait une grosse scène de startups, au départ, sur le projet, comme tout truc un peu chaud, le cloud. Il y avait beaucoup d'argent qui circulait, il y a eu beaucoup de boîtes qui ont été créées, et ces boites-là avaient besoin de monétiser, de vendre quelque chose à leurs investisseurs au bout d'un moment. Et, une fois que cette sale engeance a été nettoyée du système, ils ont tous fait faillite, ils ont tous été rachetés par les gens qu'on a vu sur la liste des sponsors, les IBM et autres. Résultat, maintenant on est plus sur des boîtes qui pensent sur le long terme, plutôt que sur l'ultra court terme.
Le deuxième challenge passé sur la collaboration, ce sont les tâches ingrates. Il y a des tâches ingrates à faire, et comment on les fait dans un système où chacun choisit ce sur quoi il travaille ? On a investi beaucoup sur l'automatisation de ces tâches ingrates. Donc la plupart des tâches ingrates ce sont des tâches bêtes et on a, un petit peu, investi agressivement dans l'automatisation des tâches bêtes, pour éviter d'avoir des gens qui doivent les faire. Tout ce qui est tests, par exemple, c'est automatisé, parce que les tests c'est ennuyeux. C'est comme ça qu'on a résolu ce problème-là.
Le dernier problème c'est la tragédie des communs, le fait que les entreprises peuvent ne pas vouloir contribuer aux choses que tout le monde veut, car elles attendent que quelqu’un d'autre le fasse. C'est un grand classique de ce type d'organisation et, en fait, on a résolu ce problème-là essentiellement en développant, justement via ce cœur de développeurs qui est basé sur le projet, et non pas dans une entreprise en particulier. On a créé, en quelque sorte, presque une conscience du système où ces développeurs qui sont au cœur du projet, qui bénéficient de cette espèce de marché dans lequel ils peuvent, en tout cas, inverser le rapport de force avec leur employeur. Ces personnes-là ont intérêt à ce que le projet survive et donc vont convaincre leur employeur d'investir dans ces fonctions critiques, qui sont centrales, et qui bénéficient à tous plutôt que de ne bénéficier que à la personne.
Donc ça, je dirais ce sont des challenges qu'on a rencontrés sur les cinq premières années et qu'on a, je dirais aujourd'hui, assez sous contrôle.
Les challenges actuels sont différents. Les challenges actuels sont liés à la croissance du projet, sur le nombre de personnes. Ça prend des proportions très importantes, et il y a un certain nombre des principes, sur lesquels on a basé le projet, qui commencent à être perdus. C'est-à-dire que, aujourd'hui, il y a énormément de gens qui sont rentrés dans le projet, qui n'ont pas la culture commune qu’avaient les gens qui étaient sur le projet au départ. On s'aperçoit qu'on a trop supposé que les gens allaient intégrer cette culture naturellement. Les premières années ça c'est très bien passé, les gens intégraient facilement la culture, etc. Mais, à partir d'un certain nombre, en fait, on commence à toucher à des cultures, certaines zones du monde, certaines entreprises, ou certains développeurs dans certaines entreprises, qui n'ont pas cette culture-là, et on n'avait pas documenté la culture. On n'avait pas décrit ce que c’était que de se comporter comme quelqu'un de bien dans OpenStack. Donc un gros travail à faire, que j'ai commencé depuis quelques mois, sur la documentation de cette culture commune, parce qu'on ne peut pas supposer qu'elle va se diffuser naturellement aux nouveaux entrants.
L'autre challenge, c'est de grossir les relations de confiance. En fait on s'aperçoit que, au final, dans le système, ce sont des humains, et on a un certain nombre de choses qui s’appuient sur la confiance, dans ce système, notamment le système des revues de code. Je vous le disais, il faut qu'ils soient deux à être d’accord. Il y a un groupe, et il faut qu'ils soient deux à être d'accord, au moins deux à être d'accord, pour que le code rentre. Enfin, en gros, il faut qu'ils soient deux à être d'accord et qu'il n'y ait personne d'autre qui dise : « Non, jamais de la vie ! » Et en fait, ces gens-là font partie d'un groupe. Un groupe qui va avoir quinze personnes, à peu près, et ces quinze personnes, ça fonctionne jusqu'à quinze parce qu'elles arrivent à se faire confiance l'une l'autre. Elles se connaissent suffisamment, elles partagent suffisamment en commun, elles savent qu'elles peuvent faire confiance à Machin parce que Machin va appliquer les mêmes règles qu'il aurait appliquées. Or, comme le code devient plus gros, on a besoin d'aller au-delà de ces groupes de quinze personnes, et on n'y arrive pas. On n'y arrive pas parce que les gens ne se font plus confiance. Donc finalement, il y a un nombre, sans doute un nombre de Dunbar2, quelque part ici, qui est la limite du groupe qu'on peut avoir pour faire ces revues de code. On s'aperçoit que c'est autour de quinze personnes. Donc, en gros, il faut qu'on arrive à couper en petits morceaux notre code pour que les groupes de gens qui doivent se faire confiance soient toujours moins de quinze. Et ce n'est pas forcément très facile pour les gens qui aujourd'hui contrôlent ces grands ensembles de code de leur dire : « Non, mais maintenant vous allez devoir contrôler une plus petite partie du code ». Il y a une espèce de caste qui s'est un petit peu installée.
Voilà, c'est ce type de challenges qu'on a aujourd'hui, qui sont, je dirais, des bons challenges à avoir. Il vaut mieux avoir des problèmes parce qu'on grossit trop vite que des problèmes parce qu'on ne grossit pas, mais ça demande une adaptation.
En conclusion, pour moi ça a toujours été une expérience sociologique. Quand on a construit ce projet, moi je voulais voir si ça pouvait marcher. Donc on a dit : « Ah, si on faisait quelque chose où, en gros, les développeurs, c'est la contribution qui détermine la valeur. On n'a pas de managers, on n'a pas de gens qui n'apportent pas leur pierre à l'édifice dans le système », et voir si ça pouvait marcher.
Je pense qu'on arrive à un bon exemple de production contributive à grande échelle, sur un secteur qui est très concurrentiel, très innovateur, parce qu'on arrive à une organisation non hiérarchique. Comme je l'ai expliqué, le leader technique du projet, aujourd'hui, est plus un ambassadeur, un porte-parole, qu’un décideur. On est sur un système où la contribution est l'unique monnaie, puisque, en fait, la valeur qu'on a dans le projet est uniquement mesurée par sa contribution. On est sur un modèle où on abolit les frontières corporatives, complètement. Pour moi, c'est toujours surprenant quand on fait ces réunions dans le Design Summit, ces réunions où on met tous ces développeurs dans cette salle et où, soudainement, ils ne représentent plus leur entreprise. Ils sont là pour travailler sur le projet. Il y a quelque chose qui se passe à ce moment-là. Ils arrivent à se détacher complètement et à se dire « non, en fait, je suis plus avec toi que je ne suis avec mon patron ».
Et il y a toujours cette unification entre le producteur et le consommateur qui revient, qui est le fait que les utilisateurs du système on les voit, maintenant, contribuer, venir, faire du retour d'expérience, nous dire comment ils utilisent le logiciel. Parfois, même quand ils ne sont pas développeurs, ils vont venir pour nous expliquer les problèmes qu'ils ont. Donc on a intégré tous les opérateurs du système dans le design, pour pouvoir, vraiment, avoir cette boucle complète où personne n'est le producteur, personne n'est le consommateur, on participe tous au même système.
Est-ce pour autant un exemple pratique de néguentropie ? Là, j'ouvre un petit peu la question. Je pense qu'il y a dans les objectifs du projet, dans le concept de combat du monopole, du même, dans cette production de différences, dans cette espèce de possibilité qu'on a d’essayer de multiplier ces clouds, de créer des options différentes, je pense qu'on combat l'avènement de cette espèce de futur unique. Mais ça, je dirais, c'est plus sur le thème du projet, les objectifs du projet. Dans la mécanique du projet, la mécanique de l'innovation ouverte, il y a fondamentalement, à la base, la réduction de la duplication d'effort. La duplication d'effort est génératrice de déchets, de ressources perdues, et donc d'entropie. Et je pense qu'on est sur un mécanisme qui, fondamentalement, réduit l'entropie dans un domaine qui est l'innovation, qui est un domaine où, je dirais habituellement on a ces parallèles, ces x duplications, x entreprises qui travaillent exactement sur le même sujet. Il y en a neuf qui vont perdre, il y a une qui va gagner, et elles auraient pu toutes contribuer, produire la même chose avec beaucoup moins de ressources.
Mais je pense qu'il y a surtout la création d'un espace de collaboration, de coopération ouverte, au-delà des frontières artificielles, je dirais, de l'industrie. Élaboration d'un contenant, comme le disait quelqu'un lundi soir, d'un établissement thérapeutique, comme tu disais Bernard, où on reconstruit du collectif, on reconstruit une collaboration là où, je dirais, les habitudes de l'industrie étaient d’être chacun dans son coin. On favorise des échanges. Comme je le disais, quand on met ces développeurs ensemble, tout d'un coup il y a quelque chose qui se passe, qui ne se passerait jamais ailleurs. Et donc on favorise les bifurcations néguentropiques dont parlait Paul-Émile. Voilà, ça conclut mon propos. Je vous remercie de votre attention.
Applaudissements
- 1. OpenStack [9]
- 2. Nombre de Dunbar [10]