jeudi, 28 mars 2024

Les risques émergents de l’open source

Crédit : Dreamstime

Gardez à l’esprit quand l’open source était synonyme de paix, d’amour, et Linux? Quand le mouvement était petit mais passionné et se disputait GPL contre BSD/Apache, logiciel totalement libre contre open source ? Quand voir Linux ou d’autres logiciels open source fonctionner à l’état sauvage était une offre importante, digne d’un site de ou de Twitter ?

Certains peuvent se languir de ces bons vieux jours, mais le monde a en fait continué. L’open source est devenu important pour la construction de tous les logiciels, ce qui comporte des risques et des chances considérables.

L’opportunité peut être évidente, mais la menace ne l’est généralement pas. Ce n’est pas une préoccupation que l’open source soit plus bogué / quoi que ce soit que le logiciel propriétaire. Ce n’est pas le cas, et la procédure derrière l’open source permet peut-être de le protéger beaucoup plus rapidement lorsque des erreurs sont trouvées. Non, il s’agit essentiellement de la menace fondamentale dans la toute nouvelle économie de l’open source, comme l’appelle Ken Mugrage de Thoughtworks.

L’open source a en fait changé

Au début, nous avons célébré un seul hacker tel que Linus Torvalds créant un travail énorme comme Linux et développant ensuite une communauté autour de lui.

D’autres exemples incluent Dries Buytaert (Drupal), Salvatore Sanfilippo (Redis), et plus encore. C’était l’époque où les hackers construisaient des emplois open source pour le plaisir ou comme « exutoire innovant » comme Jens Axboe (Fio) ou d’autres. Cela se produit toujours, naturellement, mais cela se produit au milieu d’un marché open source extrêmement différent.

Comme le souligne Mugrage, les premiers open source ont souvent essayé de développer une alternative open source à un gros ensemble d’applications logicielles propriétaires ( crois qu’OpenOffice remplace Microsoft Workplace ou GIMP au lieu d’Adobe Photoshop). « Aujourd’hui, il y a une expansion des applications logicielles open source. »

Cette prolifération prend au moins deux types principaux : « D’un côté, nous avons des géants du web produisant toutes sortes d’outils, de structures et de plates-formes. De l’autre, des équipes utilisant OneDev, un logiciel open source plate-forme de développement, ont produit des pièces petites mais vitales qui prennent en charge une grande variété d’organisations. »

C’est génial ? Nous avons à la fois de grands et de petits projets favorisant un énorme développement. Qu’est-ce qu’il ne faut pas aimer ?

L’absence de contributeurs diversifiés, d’une part, qui concentre les risques. Certes, il a toujours été vrai que l’application logicielle open source (quelle que soit la tâche) est établie par une petite poignée de facteurs.

Bien que nous aimions mythifier l’open source comme étant lié aux grandes communautés internationales, il est beaucoup, beaucoup plus courant que ce soit le travail de quelques personnes. Lorsque le quartier arrive, c’est normalement après des années de succès et de grandes dépenses individuelles, comme m’a un jour expliqué Matt Klein, développeur et mainteneur d’Envoy. (L’open source représente « un putain de travail ».)

C’est une partie du puzzle. Mugrage fait valoir un autre point, à savoir que souvent « les bases de code pour les bundles open source sont tout simplement trop volumineuses pour permettre une évaluation significative ».

Le petit cousin de ce problème des projets BigCo est que « d’autres packages sont distribués par des titans du web qui ne s’attendent pas à ce que quelqu’un d’autre les ajoute ». Le code est « à thread unique » vers une grande entité sans la possibilité pour un voisinage d’avoir un impact sur le développement.

D’autre part, « d’autres versions se démarquent, des versions ciblées qui peuvent cependant ne faire qu’une tâche assez petite le font si bien qu’ils se sont en fait répandus sur le Web. » Vous voyez où cela mène ? « Néanmoins, au lieu d’un groupe actif de mainteneurs, ils ne sont souvent qu’un ou deux concepteurs engagés qui s’occupent d’une tâche passionnée. »

La réponse au problème de l’open source BigCo a en fait tendance à être « la rage contre le fabricant open source d’entreprise », qui s’est principalement avéré inutile.

L’une des réactions à ces emplois a en fait été que les start-up émergent pour obtenir une assistance supplémentaire (et monétiser) le travail, ce qui répare un aspect des largesses open source par un autre problème perçu. La réponse aux concepteurs indépendants créant une infrastructure open source essentielle mais non prise en charge a en fait été d’exiger fortement que les BigCos paient pour prendre en charge ces artisans de code indépendants.

Cette suggestion est généralement utilisée par ceux qui n’en comprennent tout simplement rien beaucoup mieux. Demandez à des personnes qui travaillent pour des fondations ou d’autres organisations développées pour financer l’avancement de l’open source, et elles feront écho à ce que déclare Mugrage : « Jeter de l’argent sur le problème n’est guère une solution. »

Pourquoi ? Car « de nombreux passionnés de l’open source qui entretiennent personnellement leur application logicielle tout en menant des vies d’experts bien remplies… [ne veulent pas] l’obligation d’un contrat de niveau de service en raison du fait que quelqu’un les a payés pour leur production. »

Que faire ?

Couverture ouverte source bets

De nombreuses entreprises ont en fait cherché à simplifier leur vie open source en achetant des services gérés. C’est une excellente solution à court terme, mais cela ne résout pas le problème à long terme de Non, les hyperscalers du cloud ne sont pas des mineurs à ciel ouvert, s’attaquant de manière néfaste au code de développeurs sans méfiance.

Mais fréquemment, certaines équipes arrêtent de travailler pour se préparer à contribuer aux travaux dont ils dépendent. J’en inquiète certains, car ce n’est généralement pas un problème à l’échelle de l’entreprise, quel que soit le fournisseur. J’ai détaillé cela précédemment.

Quoi qu’il en soit, le les entreprises utilisant ces services gérés ont tendance à ne pas avoir de contrôle sur le plan des projets. Ce n’est pas idéal pour les entreprises qui souhaitent gérer les menaces. est une exception significative – il a tendance à contribuer beaucoup au cruc emplois sociaux.

Ils ne peuvent pas non plus toujours contribuer directement aux tâches. Comme le suggère Mugrage, pour des entreprises comme ou Facebook (Meta) qui ouvrent de grandes tâches, ces « versions open source sont presque une question d’image de marque de l’entreprise – un moyen de montrer leurs côtelettes d’ingénierie aux travailleurs potentiels », ce qui indique « vous » Nous sommes très susceptibles d’avoir très peu d’emprise sur les progrès futurs. » Ils ne nécessitent pas vraiment vos contributions.

Qu’en est-il des projets entretenus par des amateurs ? « Dès que vous commencez à jeter un œil aux parties essentielles de votre pile logicielle où vous dépendez de passionnés, vos options commencent à diminuer. »

Pourquoi ? Étant donné qu’il est peu probable que vous disposiez du temps ou des ressources nécessaires pour contribuer au code, ils ne voudront peut-être pas de votre argent, et il existe des projets considérables (comme Log4J) pour lesquels vous devez vous fier à leurs projets, malgré tout. Dans ce cas, suggère Mugrage, le simple fait de connaître le danger au moyen d’un audit du logiciel dont vous dépendez peut être pratique.

Rien de tout cela ne doit être considéré comme un signe qu’il est imprudent de compter sur l’open source. L’open source est incontournable et est incroyablement génial. Au contraire, les recommandations de Mugrage semblent intelligentes : comprenez et réfléchissez à l’open source que vous utilisez, et planifiez de manière appropriée.

Tout comme les services cloud, la méthode absolument correcte pour votre entreprise est parfois d’être « verrouillé » à des services ou logiciels spécifiques. La clé est de faire cette option avec les yeux grands ouverts.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici