Comment Microsoft a tué AppGet

Comment Microsoft a tué AppGet

La semaine dernière, Microsoft a lancé un gestionnaire de paquets WinGet dans le cadre des annonces lors de la conférence Build 2020. Beaucoup ont considéré cela comme une nouvelle preuve du rapprochement de Microsoft avec le mouvement Open Source. Mais pas le développeur canadien Keivan Beigi, l'auteur du gestionnaire de paquets libre AppGet. Il essaie maintenant de comprendre ce qui s'est passé au cours des 12 derniers mois, période durant laquelle il a discuté avec des représentants de Microsoft.

Quoi qu'il en soit, Keivan met fin au développement d'AppGet. Les services clients et serveurs passent en mode maintenance immédiatement jusqu'au 1er août 2020, après quoi ils seront définitivement fermés.

Dans son blog, l'auteur fournit la chronologie des événements. Tout a commencé il y a un an (3 juillet 2019), lorsque qu'il a reçu ce courriel d'Andrew, le responsable de l'équipe de développement chez Microsoft :

Keivan,

Je dirige l'équipe de développement du Windows App Model et, en particulier, l'équipe de déploiement d'applications. Je voulais simplement vous envoyer un petit mot pour vous remercier d'avoir créé appget — c'est un excellent ajout à l'écosystème Windows qui rend la vie des développeurs Windows beaucoup plus facile. Nous serons probablement à Vancouver dans les prochaines semaines pour rencontrer d'autres entreprises, mais si vous avez du temps, nous aimerions vous rencontrer, vous et votre équipe, pour obtenir des retours sur la façon de rendre votre vie plus facile dans le développement d'appget.

Keivan était excité : son projet de loisir avait attiré l'attention de Microsoft ! Il a répondu au courriel — et deux mois plus tard, après un échange de courriels, il s'est rendu à une réunion au bureau de Microsoft à Vancouver. Andrew et un autre responsable du développement de la même équipe de produits étaient présents au rendez-vous. Keivan dit qu'il a passé un excellent moment — ils ont parlé des idées sous-jacentes à AppGet, de ce qui n'est pas très bien fait dans les gestionnaires de paquets actuels sous Windows et de ce qu'il prévoit dans les futures versions d'AppGet. Le développeur a eu l'impression que Microsoft voulait aider le projet : ils ont eux-mêmes demandé ce qu'ils pouvaient faire pour lui. Il a mentionné que ce serait bien d'obtenir un peu de crédits sur Azure, de la documentation sur le nouveau format de paquets MSIX, et qu'il serait bon de corriger les problèmes avec les liens de téléchargement individuels.

Une semaine plus tard, Andrew a envoyé un nouveau courriel, dans lequel il a en fait invité Andrew à rejoindre Microsoft : « Nous voulons apporter des changements importants à la distribution des logiciels sur Windows, et il y a une excellente opportunité d'aider à définir l'apparence de Windows et du système de distribution des applications dans Azure/Microsoft 365. À cet égard, avez-vous envisagé de consacrer plus de temps à appget, potentiellement chez Microsoft ? »

Kayvan a d'abord hésité un peu — il ne voulait pas rejoindre Microsoft pour travailler sur le Windows Store, le moteur MSI et d'autres systèmes de déploiement d'applications. Mais ils l'ont assuré qu'il passerait tout son temps uniquement sur AppGet. Après environ un mois de correspondance par courriel, ils ont conclu que l'accord ressemblerait beaucoup à un acqui-hire — Microsoft embauche le développeur avec son programme, et ils décident de le renommer ou de l'appeler Microsoft AppGet.

Kayvan mentionne qu'il n'a pas complètement compris quel serait son rôle chez Microsoft pendant tout le processus. Quelles seraient ses responsabilités ? À qui devrait-il rendre des comptes ? Qui sera placé sous sa responsabilité ? Il a essayé de clarifier certaines de ces réponses pendant ces négociations lentes, mais n'a jamais obtenu de réponse claire.

Après encore quelques mois de négociations très lentes par courriel, on lui a dit que le processus d'embauche via BizDev prendrait beaucoup de temps. Une alternative pour accélérer le processus serait de simplement l'embaucher avec un « bonus », après quoi il commencerait à travailler sur le transfert de la base de code. Il n'avait aucune objection, donc ils ont planifié quelques réunions/entretiens à Redmond.

Le processus a avancé. Le 5 décembre 2019, Kayvan a pris un vol pour Seattle — au siège de Microsoft — et a passé toute la journée là-bas, à passer des entretiens avec différentes personnes et à négocier avec Andrew. Le soir, il a pris un taxi pour l'aéroport — et est retourné à Vancouver.

On lui a dit d'attendre un appel du département des ressources humaines. Mais ensuite, pendant six mois, Kayvan n'a rien entendu de Microsoft. Jusqu'à la mi-mai 2020, quand un ancien collègue d'Andrew a annoncé la sortie du programme WinGet le lendemain :

Salut Kayvan, j'espère que toi et ta famille allez bien — il semble que la Colombie-Britannique gère mieux le Covid par rapport aux États-Unis.

Je suis vraiment désolé que le poste de chef de projet n'ait pas fonctionné. Je voudrais prendre le temps de dire à quel point nous apprécions ta contribution et tes idées. Nous avons développé un gestionnaire de paquets pour Windows, et le premier aperçu en direct aura lieu demain lors de Build 2020. Nous mentionnerons également appget dans notre blog, car nous pensons qu'il y a de la place pour divers gestionnaires de paquets dans Windows. Notre gestionnaire de paquets est aussi basé sur GitHub, mais, bien sûr, avec notre propre mise en œuvre, et ainsi de suite. Il sera également open source, donc, bien sûr, nous serons ravis de toute contribution de ta part.

Kayvan n'était pas trop surpris. À ce moment-là, il était déjà clair qu'il ne serait pas invité à travailler chez Microsoft, ce qui ne l'a pas contrarié, car il doutait de vouloir travailler pour une si grande entreprise.

Mais la véritable surprise l'attendait le lendemain, lorsqu'il a vu dépôt GitHub: «Quand j'ai montré le dépôt à ma femme, la première chose qu'elle a dite a été : 'Ils l'ont appelé WinGet ? Tu es sérieux ??' Je n'ai même pas eu besoin de lui expliquer comment fonctionnent les principales mécaniques, la terminologie, le format et la structure du manifeste, même la structure des dossiers du dépôt de paquets est inspirée d'AppGet.»

«Suis-je déçu que Microsoft, une entreprise valant 1,4 billion de dollars, ait enfin trouvé le courage de sortir un gestionnaire de paquets digne pour son produit phare ? Non, ils auraient dû le faire il y a des années. Ils ne devraient pas avoir abîmé le Windows Store autant qu'ils l'ont fait, écrit Kayvan. En réalité, peu importe combien j'ai essayé de promouvoir AppGet, il ne grandira jamais aussi vite que la solution de Microsoft. J'ai créé AppGet non pas pour devenir riche, célèbre ou obtenir un emploi chez Microsoft. J'ai créé AppGet parce que je pensais que nous, utilisateurs de Windows, méritions aussi une expérience de gestion d'applications de qualité. Ce qui m'inquiète, c'est comment tout cela a été fait. Des communications lentes et horribles. À la fin, un silence radio complet. Mais ce qui m'a le plus touché, c'est cette annonce. AppGet, qui est objectivement la source de la plupart des idées pour WinGet, n'a été mentionné que comme un autre gestionnaire de paquets qui existe simplement par accident dans ce monde.. En même temps, d'autres gestionnaires de paquets, avec lesquels WinGet a très peu en commun, ont été mentionnés et expliqués de manière beaucoup plus approfondie.

Kaveh Beigy n'est pas contrarié. Il dit qu'il n'y a pas de bien sans mal. Au moins, WinGet est construit sur une base solide et a le potentiel de réussir. Et les utilisateurs de Windows pourraient enfin avoir un gestionnaire de paquets digne de ce nom. Pour lui, cette histoire a été une expérience précieuse : « On vit un siècle, on apprend un siècle ».

Il explique que copier du code n'est pas un problème, c'est l'essence même de l'Open Source. Et il ne parle pas de copier le concept général des gestionnaires de paquets/applications. Mais si l'on regarde des projets similaires sur OS X, Homebrew, Chocolaty, Scoop, ninite, etc., chacun a ses propres caractéristiques. Cependant, WinGet fonctionne presque de la même manière qu'AppGet : « Vous voulez savoir comment fonctionne Microsoft WinGet ? Allez y jeter un œil et lisez l'article que j'ai écrit il y a deux ans sur le fonctionnement d'AppGet.», écrit-il.

Ce qui a seulement déçu Kaveh, c'est que son travail n'est mentionné nulle part.

Pour référence. « Embrace, extend and extinguish » (« Étreindre, étendre et éteindre ») est une phrase qui, comme l'a établi le ministère de la Justice américain,a été utilisée par Microsoft pour décrire une stratégie d'infiltration dans l'industrie des logiciels utilisant des normes largement répandues. Cette stratégie impliquait d'étendre ces normes et d'exploiter ces différences pour obtenir un avantage sur les concurrents.

Dans le cas d'AppGet, il ne peut pas être dit que cette stratégie a été utilisée dans sa forme pure, mais certains éléments peuvent être examinés. Les partisans du logiciel libre considèrent cela comme une manière d'agir moralement inacceptable et restent méfiants vis-à-vis de l'initiative de Microsoft d'intégrer une sous-système Linux dans le système d'exploitation Windows (WSL). Ils disent que Microsoft, par essence, n'a pas changé et ne changera jamais.

Comment Microsoft a tué AppGet


Source : habr.com

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster