Il n'y a pas de définition unique du succès dans les projets open source.
Tout le monde est dans l'open source ces jours-ci. Microsoft vient de publier son logiciel 3D Movie Maker sous une licence open source. Spotify a une multitude de projets qu'il a publiés et auxquels il contribue, et vient d'annoncer un fonds pour soutenir les mainteneurs de projets. Il y a même du code de moteur de jeu du Moyen Âge (1998) en open source.
Open source :couverture à lire absolument
Avec ces projets, et des millions d'autres disponibles, c'est une bonne question à se poser... pourquoi ? Ou plutôt, pourquoi la grande majorité de ces projets importent-ils, et pour qui ? La plupart des projets, après tout, ne seront jamais Kubernetes.
Après plus de deux décennies dans l'open source, cependant, je commence à réaliser que ce n'est pas la bonne question.
L'exemple du pétard
Prenez Firecracker, un projet de micro-virtualisation open source lancé par AWS en 2018. Firecracker a été presque universellement salué comme une technologie cool… puis a pratiquement disparu de la vue du public. J'ai écrit sur certains premiers succès de la communauté, mais même cela (Weave Ignite pour améliorer la facilité d'utilisation de Firecracker, entre autres) est venu d'un partenaire AWS proche. Pour donner à Firecracker plus de poids communautaire, j'ai suggéré qu'AWS suive Google et ouvre la gouvernance autour de Firecracker, pas seulement son code.
AWS n'a pas écouté mais, pas pour la première fois, mon opinion ne semblait pas avoir d'importance. (C'est une façon polie de dire que je me suis peut-être trompé.)
Avance rapide jusqu'en 2022, et Firecracker s'utilise tranquillement dans de nombreux endroits sympas. Je dis « silencieusement » parce que, eh bien, pourquoi quelqu'un crierait-il son infrastructure sur les toits ? Mais quand j'ai demandé, certains utilisateurs intéressants sont apparus, comme Stripe, Fly.io, System Initiative et plus encore. Bien sûr, il est toujours vrai que la plupart des contributeurs de Firecracker sont employés par AWS.
Mais même si Firecracker serait resté une seule communauté (AWS), cela en aurait sans doute valu la peine. En fait, c'est essentiellement ce que j'ai soutenu pendant que je travaillais pour AWS, indiquant qu'il y avait des raisons claires axées sur le client pour ouvrir Firecracker, indépendamment de l'implication de la communauté. L'open source garantissait que Firecracker fonctionnerait bien avec la communauté Linux et permettait des "gains de produits composés" plus serrés pour les clients.
Des millions de pétards
Maintenant, jouez cet exemple de Firecracker multiplié par les plus de cent millions de référentiels GitHub (et autres open source). Il ne s'agit pas d'être le prochain Kubernetes. Pour chaque projet open source, il s'agit de répondre aux besoins du développeur individuel, d'une entreprise ou d'une communauté plus large.
Parfois, ces besoins peuvent être importants. Lors d'une conversation que j'ai eue avec Matt Klein, responsable de l'ingénierie chez Lyft et fondateur d'Envoy, il a souligné que « pour la plupart des gens qui open source quelque chose, c'est en fait un net négatif » parce que « s'ils n'investissent pas dedans, s'ils ne le font pas faire toutes ces choses [comme les relations publiques, le marketing et l'embauche], ils vont juste jeter quelque chose par-dessus le mur. Pour Klein, une implication significative à l'échelle de l'industrie dans Envoy a aidé à faire en sorte que le projet vaille l'investissement qu'il (et, par extension, Lyft) avait fait.
Mais on peut dire que tout le monde n'a pas besoin d'obtenir ce genre de retour. Dans le cas de Firecracker, l'open source du code et le simple fait de faire collaborer les clients auraient suffi, comme je l'ai pensé. Pour Google, en revanche, qui essayait sans doute de faire progresser une réalité multicloud via Kubernetes, il fallait aller grand. Chaque projet aura des besoins différents et des mesures de succès différentes.
Vous n'êtes donc pas le prochain Kubernetes ? C'est très bien. Vous n'êtes pas non plus le prochain Firecracker ? Aussi très bien. Pour les développeurs open source, la clé est de comprendre ce qu'un projet sain signifie pour vos besoins particuliers, et de ne pas se laisser distraire par les définitions du succès des autres.
Divulgation :je travaille pour MongoDB mais les opinions exprimées ici sont les miennes .
Lien source