Version classiqueVersion mobile
OpenEdition Books

Sur quoi reposent nos infrastructures numériques ?

 | 
Nadia Eghbal

Soutenir les infrastructures numériques

Des modèles économiques pour les infrastructures numériques

Texte intégral

1Certains aspects des infrastructures numériques peuvent fonctionner dans un contexte concurrentiel. Les bases de données et les services d’hébergement, par exemple, sont souvent des affaires profitables, bien financées, parce qu’elles peuvent faire payer l’accès. Tout comme l’accès à l’eau ou à l’électricité, l’accès à un serveur ou à une base de données peut être mesuré, facturé, et fermé si les honoraires ne sont pas réglés.

2Heroku (mentionné au début de cet ouvrage1) et Amazon Web Services sont deux exemples notables de plateformes qui vendent des services d’infrastructure numérique à des développeurs logiciels contre une redevance (à noter qu’aucun des deux n’est un projet open source). Des projets open source similaires, à ce niveau d’infrastructure, tels que OpenStack (une plateforme concurrente d’Amazon Web Services) ou MySQL (une base de données), ont trouvé leurs assises dans des entreprises. OpenStack est financé par un consortium d’entreprises, et MySQL a été racheté par Oracle.

3C'est en partie l'absence de « bruit » qui rend ces services financièrement attractifs. Pour un seul logiciel, un développeur utilise parfois 20 bibliothèques distinctes, avec chacune des fonctions différentes, mais il n’a besoin que d’une seule base de données. En conséquence, les projets à succès ont plus de chances d’obtenir l’attention et le soin dont ils ont besoin.

  • 2 Merci à Sam Gerstenzang d'avoir fait le point sur cette différence. Voir son Tweet, daté du 13/01/ (...)

4Il existe une autre façon utile de cerner les infrastructures que l’on peut facturer : s’il y a un risque immédiat de défaillance, alors il y a probablement un modèle économique. En d’autres termes, un serveur peut subir des interruptions de service inattendues, tout comme l’électricité peut sauter à l’improviste, mais un langage de programmation ne « casse » ni n’a de telles périodes d’indisponibilité, parce qu’il s’agit d’un système d’information2.

5Pour ce genre de projets open source, le modèle économique a tendance à se focaliser sur la recherche de services ou d’assistance facturables. Cela fonctionne pour les projets qui bénéficient d’un usage significatif par les entreprises, en particulier quand il s’agit d’un problème techniquement complexe, ou lorsqu’une entreprise a besoin qu’une fonction soit développée.

Récompenses

6À petite échelle, des personnes ou des entreprises promettent parfois des « récompenses » d’ordre pécuniaire lorsque certains objectifs de développement ont été atteints.

7Par exemple, IBM demande régulièrement de nouvelles fonctionnalités pour divers projets par le biais d’un site web appelé Bountysource3, offrant jusqu’à 5 000 dollars par tâche. Bountysource est une plateforme populaire pour trouver et proposer des récompenses ; elle compte plus de 26 000 membres.

8Les récompenses aident à régler les problèmes précédemment mentionnés en faisant un don pour un projet précis. Comme les récompenses sont clairement liées à un résultat, l’argent va être utilisé. En revanche, les récompenses peuvent avoir des effets pervers pour l’incitation à contribuer à un projet.

9Les récompenses peuvent dicter quel travail sera ou ne sera pas effectué, et parfois ce travail n’est pas en phase avec les priorités d’un projet. Il peut aussi introduire du bruit dans le système : par exemple, une entreprise peut offrir une forte récompense pour une fonctionnalité que les propriétaires du projet ne considèrent pas comme importante.

10Du côté des contributeurs, des personnes extérieures sans connaissance sur un projet peuvent y participer seulement pour obtenir la récompense, puis le quitter. Ou bien elles peuvent bâcler le travail requis, parce qu’elles essaient d’obtenir des récompenses. Enfin, les récompenses peuvent être une façon appropriée de financer de nouvelles fonctionnalités ou des problèmes importants, mais sont moins pratiques lorsqu’il s’agit de financer des opérations continues, comme le service client ou la maintenance.

11Jeff Atwood, le créateur de Stack Overflow, a remarqué les problèmes suivants avec les programmes de récompenses, en particulier en ce qui concerne la sécurité4 :

L’un des effets pervers de cette tendance à attribuer des récompenses pour les rapports de bugs est que cela n’attire pas seulement de véritables programmeurs intéressés par la sécurité, mais aussi toutes les personnes intéressées par l’argent facile. Nous avons reçu trop de rapports de bugs de sécurité « sérieux » qui n’avaient qu’une importance très faible. Et nous devons les traiter, parce qu’ils sont « sérieux », n’est-ce pas ? Malheureusement, beaucoup d’entre eux ne représentent qu’un gaspillage de temps… Ce genre d’incitation me semble vraiment néfaste. Même si je sais que la sécurité est extrêmement importante, je suis de plus en plus inquiet face à ces interactions parce qu’elles me demandent beaucoup de travail et que le retour sur investissement est très faible.

Services

12À une plus vaste échelle, un des exemples bien connus et le plus souvent cités de modèle économique open source, c’est Red Hat, l’entreprise dont nous avons déjà parlé, qui propose une assistance, des sessions de formation et autres services à des entreprises qui utilisent Linux. Red Hat a été fondée en 1993, il s’agit d’une entreprise cotée en bourse avec un chiffre d’affaires déclaré de 2 milliards de dollars par an.

13Bien que Red Hat ait connu un succès fantastique d’un point de vue financier, nombreux sont ceux qui soulignent qu’il s’agit d’une anomalie sans lendemain. Red Hat a bénéficié de l’avantage du premier arrivé dans son domaine technologique. Matt Asay, un journaliste spécialisé en open source, a remarqué que Red Hat utilise un ensemble unique de licences et brevets pour protéger ses parts de marché. Asay, qui auparavant était un fervent défenseur des entreprises open source, est maintenant persuadé que certaines licences propriétaires sont nécessaires pour faire sérieusement des affaires5. Matthew Aslet du 451 Group, un organisme de recherche, a découvert lui aussi que la plupart des entreprises open source qui réussissent utilisent en fait indifféremment un type de licence commerciale6.

14Docker, déjà mentionné plus haut7, est un projet open source qui aide les applications à fonctionner efficacement. C’est l’exemple le plus récent d’entreprise qui s’inspire de ce modèle. Docker a levé 180 millions de dollars en capital-risque auprès d’investisseurs, avec une valorisation d’un milliard de dollars de la part d’investisseurs privés8. Comme sa part de marché s’est accrue, Docker a commencé à proposer des services d’assistance au niveau des entreprises. Or sans revenus solides, Docker pourrait n’être qu’un exemple de plus de capital-risque qui fait un investissement dans une entreprise d’infrastructure leader sur son marché, mais qui réalise des pertes.

  • 9 À l'origine, un hoodie est un sweat-shirt à capuche. Voir le site Hoodie (hood.ie).

15À petite échelle, beaucoup de développeurs proposent des services de consultant pour pouvoir financer leur travail. Hoodie9 est un framework poids plume qui repose sur Node et qui a réussi dans les services de consultant.

  • 10 Voir le site Neighbourhood.ie/, littéralement « les voisins de Hoodie ».
  • 11 Source : entretien téléphonique avec Jan Lehnardt, le PDG de Neighbourhoodie.

16Hoodie lui-même est un projet open source. Plusieurs mainteneurs gagnent leur vie grâce à la boutique de l’entreprise, Neighbourhoodie, qui propose des services de développement logiciel10. Bien que Neighbourhoodie se spécialise dans le framework de Hoodie, ce dernier est encore un projet plutôt jeune, de sorte que certaines parties de son travail proviennent de projets qui ne sont pas liés à Hoodie11. Dans le cas de Hoodie, le modèle de services choisi est censé payer le salaire de plusieurs mainteneurs, plutôt que de viser une stratégie d’entreprise à l’échelle de Red Hat.

17Le conseil est une option viable pour les développeurs indépendants, si suffisamment d'utilisateurs du projet sont d’accord et ont l'argent nécessaire pour payer de l’aide supplémentaire. Mais à petite échelle, cela peut aussi les empêcher d’améliorer le projet lui-même, puisque les deux personnes au plus qui le maintiennent passent désormais leur temps à développer leur affaire et à fournir des services qui peuvent ou non être en accord avec les besoins du projet en termes de maintenance.

18Aspirer à une activité de consultant peut aussi entrer en contradiction avec l’objectif de rendre le produit facile à utiliser et à appréhender, ce qui est bien dans l’esprit de l’open source. Twisted, la bibliothèque Python déjà citée12, a mentionné un témoignage plein d’humour de l’un de ses utilisateurs, une entreprise nommée Mailman13 : « Les gars, vous avez un gros problème, parce que c’était vraiment trop facile ! Comment vous comptez vous faire un paquet d’argent juste avec du conseil ? »

19En fin de compte, le « modèle économique » pour un projet open source n’est pas très différent du simple travail indépendant.

Licences payantes

20Certains développeurs ont l’impression que mettre les projets sous licence serait une solution au moins partielle aux problèmes de financement de l’open source. Si les projets open source sont fortement utilisés, pourquoi ne pas les facturer ? Ces « licences payantes » ne sont techniquement pas des licences open source, selon la définition de l’Open Source Initiative14. Il s’agit plutôt d’initiatives qui tentent d’apporter un équilibre entre le besoin très concret de travail rémunéré et le désir de rendre le code accessible au public. Ce type de code peut être appelé « à source visible » ou « à source disponible ». Fair Source, par exemple, se décrit lui-même comme « (offrant) certains des avantages de l’open source tout en préservant la possibilité de faire payer pour le logiciel ».

21La licence Fair Source15 fut créée en novembre 2015 par une entreprise appelée Sourcegraph pour répondre au besoin de licence payante. Les termes de la licence ont été rédigés par Heather Meeker, une juriste qui a également travaillé dans l’équipe principale de la Mozilla Public License v2.0. Avec la licence Fair Source, on peut librement consulter, télécharger, exécuter et modifier le code, jusqu’à un certain nombre d’utilisateurs par organisation. Une fois cette limite dépassée, l’organisation doit payer un forfait de licence, dont le montant est déterminé par l’éditeur. En d’autres termes, le code Fair Source est gratuit pour un usage personnel et pour les PME, mais fournit une base légale pour facturer les cas de plus gros usages commerciaux.

22L’annonce par Sourcegraph de la création de la licence Fair Source, qu’ils utilisent maintenant eux-mêmes, a provoqué un débat animé sur la monétisation de l’open source. (Il est à noter qu’un mouvement similaire autour du shareware, logiciel propriétaire gratuit, avait émergé avec un certain succès populaire dans les années 1980.)

23Mike Perham, l’un des mainteneurs de Sidekiq, un outil populaire pour le développement en Ruby, a aussi récemment suggéré aux contributeurs et contributrices open source d’utiliser une « licence duale » pour monétiser leur travail, faisant payer aux entreprises l’accès à une licence MIT permissive plutôt qu’une licence AGPL plus restrictive qui impose l’attribution. Sa théorie est qu’en faisant d’AGPL la licence par défaut, « les entreprises vont payer pour l’éviter ».

24Pour justifier cette idée, Perham a rappelé à son public16 :

  • 17 Ça vaut le coup de noter que Mike a raison à propos du code hébergé sur GitHub sans licence spécif (...)

Souvenez-vous : logiciel open source ne signifie pas logiciel gratuit. Ce n’est pas parce que l’on peut consulter la source sur GitHub que tout le monde peut l’utiliser et en faire n’importe quoi17. Il n’y a aucune raison pour laquelle vous ne pourriez pas donner l’accès à votre code mais aussi faire payer pour son utilisation. Tant que vous possédez le code, vous avez le droit d’y attribuer la licence que vous voulez.

[…] la réalité, c’est que la plupart des petits projets open source dépendent d’une seule personne qui fait 95 % du travail. Si c’est votre cas, soyez reconnaissants envers les personnes qui vous aident gratuitement, mais ne vous sentez pas coupable de garder 100 % du revenu.

25Faire payer les entreprises offre une autre possibilité aux développeurs et développeuses qui souhaitent poursuivre leur travail, en particulier s’il n’y a qu’une ou deux personnes pour maintenir un projet actif. Cependant, tous les projets ne peuvent pas faire payer pour le travail fourni, en particulier les projets plus vieux, ou les projets d’infrastructure qui ressemblent plus à des biens publics qu’à des produits de consommation, comme les langages de programmation.

26Même si les licences payantes peuvent fonctionner pour certains scénarios, ce modèle peut aussi être considéré comme en porte-à-faux avec l’énorme valeur sociale offerte par l’open source, qui suggère que lorsque le logiciel est libre, l’innovation suit.

27L’objectif ne devrait pas être le retour à une société qui repose sur les logiciels fermés, où le progrès et la créativité sont limités, mais de soutenir de façon durable un écosystème public dans lequel le logiciel peut être créé et distribué librement.

Notes

1 Voir partie 1, chapitre 1.

2 Merci à Sam Gerstenzang d'avoir fait le point sur cette différence. Voir son Tweet, daté du 13/01/2016.

3 Voir le site de Bountysource (Bountysource.com).

4 « Given Enough Money, All Bugs Are Shallow », Coding Horror, 03/04/2015.

5 Matt Asay, « Beyond $1bn: Why Red Hat is a one off », The Register, 29/03/2011.

6 Matthew Aslett, « Open source is not a business model », The 451 Group, 13/10/2008.

7 Voir partie 2, chapitre 2.

8 Page Docker sur Crunchbase.

9 À l'origine, un hoodie est un sweat-shirt à capuche. Voir le site Hoodie (hood.ie).

10 Voir le site Neighbourhood.ie/, littéralement « les voisins de Hoodie ».

11 Source : entretien téléphonique avec Jan Lehnardt, le PDG de Neighbourhoodie.

12 Voir partie 2, chapitre 2.

13 Voir la page Success stories, sur Twistedmatrix.com.

14 Voir le site Opensource.org.

15 Voir le site fair.io.

16 Mike Perham, « How to Charge for your Open Source », site personnel Mikeperham.com, 23/11/2015.

17 Ça vaut le coup de noter que Mike a raison à propos du code hébergé sur GitHub sans licence spécifique, mais une licence open source telle que définie par l'OSI doit inclure le droit de redistribution. Cette citation souligne à quel point la définition actuelle de l’open source est floue, avec un usage habituel qui s'éloigne de la définition historique.

Acheter

Volume papier

Chargement

Unavailable