Un développeur Microsoft appelle la direction à gérer le problème de .Net Hot Reload

Les membres de la communauté open source étaient récemment furieux contre Microsoft pour avoir apparemment supprimé intentionnellement une fonctionnalité de la plate-forme de développement logiciel open source .Net 6 (que Microsoft gère) afin que les développeurs professionnels utilisent à la place Visual Studio 2022, Microsoft assez cher mais très EDI puissant.

Il s'avère que les développeurs de Microsoft étaient également en colère, et Le revirement de Microsoft sur sa décision ne les a pas apaisés, beaucoup craignant la prochaine occasion où Microsoft place ses intérêts financiers à court terme sur leur engagement avec la communauté open source.

Cela s'est traduit par la publication de une lettre anonyme à la direction de Microsoft dans lequel l'auteur accuse directement l'entreprise de mentir pour protéger la direction.

Ils notent que Microsoft a intentionnellement tenté de cacher la suppression de Hot Reload en précipitant le PR avant que les développeurs de .Net 6 ne puissent commenter et que l'excuse de Microsoft selon laquelle ils ne pouvaient pas se concentrer sur Hot Reload pour .Net 6 et VS 2022 sonnait creux quand il n'y avait pas indication que le travail n'a pas pu être achevé de manière satisfaisante pour les deux.

Ils ont exprimé leur inquiétude quant au fait que Microsoft fera de nouveaux efforts pour paralyser .Net 6 dans le but de pousser VS 2022, malgré le fait que les outils open source soient très populaires au sein même de Microsoft.

L'auteur a demandé une enquête transparente sur la façon dont Hot Reload a été retiré et sur les changements apportés à la direction de Microsoft afin que de telles décisions irréfléchies ne puissent plus être prises.

Malgré le ton quelque peu strident qui a fait croire à beaucoup que la note n'est pas réelle, un certain nombre de MVP de Microsoft se sont manifestés et ont confirmé que la lettre avait bien été écrite par un employé de Microsoft de la division DivDev.

Lire la lettre en entier ci-dessous :

À la direction de la division des développeurs Microsoft,

Ceux d'entre nous qui travaillent dans la division des développeurs Microsoft (DevDiv) aimeraient répondre à la récente controverse entourant le retrait et le rétablissement de la fonctionnalité « dotnet watch » de dotnet 6. Bien que nous soyons reconnaissants que des têtes plus froides aient prévalu et « dotnet watch » a été préservé, nous ne sommes pas convaincus que cela ne se reproduira pas, bien au contraire.

Pour montrer ce point, nous examinerons le récent article de blog de Scott Hunter (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Sur la base de tout ce que nous savons de la situation et du fonctionnement de la division des développeurs, peu de ce que Scott a écrit semble vrai et contredit ce qui s'est passé. Pour être clair, ce n'est pas une attaque contre Scott Hunter; et au lieu de cela, cela montre jusqu'où d'autres sont prêts à aller pour protéger la gestion.

"En tant qu'équipe, nous nous engageons à ce que .NET soit une plate-forme ouverte et à faire notre développement en plein air. Le fait même que nous ayons décidé d'adopter une posture ouverte par défaut dès le départ pour développer la fonctionnalité Hot Reload en témoigne.

Rien sur la pull request n'était ouvert. Nous l'avons mentionné dans un article de blog (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) et avons précipité de manière opaque le PR pour éviter commentaires. Comment pouvons-nous dire que nous sommes transparents alors que c'est si clairement le contraire ? C'est comme si nous savions tous collectivement que c'était mal, mais que nous devions l'accepter de toute façon.

"La grande majorité des développeurs .NET utilisent Visual Studio, et nous voulons nous assurer que VS offre la meilleure expérience pour .NET 6."

Même si cela est vrai, cela signifie-t-il que nous ne nous soucions pas des non-utilisateurs de Visual Studio ? Comment tirer cette fonctionnalité si tard dans le développement permettrait-il à Visual Studio d'avoir la meilleure expérience pour le rechargement à chaud ? C'est insultant pour ceux qui n'utilisent pas toujours Visual Studio pour leur développement dotnet, et cela dit que nous ne comprenons pas nos clients ou même nos employés qui utilisent ce que nous construisons.

Nous utilisons CLI et nous utilisons VS Code. Arrêtez de prétendre le contraire.

"Nous avons commis une erreur en exécutant ce plan dans la manière dont il a été exécuté. Dans notre effort de portée, nous avons fini par supprimer par inadvertance le code source au lieu de simplement ne pas invoquer ce chemin de code.

Pour être clair, blâmer l'ingénieur pour cette "erreur" est lâche. Le problème était de supprimer la fonctionnalité, pas la façon dont ils l'ont réalisée. Sommes-nous en train de dire que si seulement nous l'avions "désactivé" au lieu de le supprimer, nous n'aurions pas annulé le changement ? Ce code aurait-il été activement travaillé ou laissé pourrir ?

"La piste devenant courte pour la version .NET 6 et Visual Studio 2022, nous avons choisi de nous concentrer d'abord sur l'apport de Hot Reload à VS2022."

Pour montrer que « Quality Control » n'était pas le cas avec « dotnet watch », nous allons le comparer avec un autre produit que nous avons retardé : MAUI.

MAUI est en mauvais état. Il était clair pour RC1 que la qualité n'allait pas être suffisamment élevée au moment de la livraison de dotnet 6 ; il y avait trop de choses à régler et pas assez de temps pour le faire. L'équipe MAUI et ses partenaires ont porté ces problèmes à la direction, ce qui a repoussé le produit au début de l'année prochaine.

Il n'y avait et il n'y a toujours aucune indication que "dotnet watch" était au même endroit. L'examen des problèmes de GitHub ni du backlog de l'équipe dotnet montre que la qualité n'était pas au rendez-vous. Au contraire, ça marchait très bien. Celles-ci auraient été évoquées beaucoup plus tôt dans notre cycle de publication s'il y avait eu de réels problèmes de qualité, pas trois semaines avant l'expédition.

"Comme c'est le cas pour de nombreuses entreprises, nous apprenons à équilibrer les besoins de la communauté OSS et à être un sponsor d'entreprise pour .NET."

Si nous lisons entre les lignes, cette affirmation est vraie. Nous sommes en conflit avec ce que nous mettons dans dotnet, Visual Studio et Visual Studio Code. Garder Hot Reload comme une "valeur ajoutée" pour Visual Studio garde ceux qui sont verrouillés dans le produit payant et moins de raisons de passer à VS Code. D'une manière froide et calculée, cela a un sens total, et c'est aussi un non-sens absolu.

Et si les équipes travaillant sur Hot Reload pour Visual Studio intégraient « dotnet watch » dans leurs produits ? Et si la direction retirait ces fonctionnalités des semaines avant la sortie générale ? Comment cela améliorerait-il Visual Studio de quelque manière que ce soit ? Allons-nous continuer à supprimer des parties de CLI parce que nous craignons de perdre des revenus de Visual Studio ?

La façon dont nous construisons le meilleur Visual Studio est d'avoir le meilleur temps d'exécution de la planète. Lorsque l'équipe Visual Studio ajoute des fonctionnalités à la base de dotnet, nous disposons d'une base cohérente sur laquelle chacun peut travailler et contribuer. Nous pouvons créer le meilleur IDE en collaborant à l'exécution, sans aggraver arbitrairement nos produits open source.

Et après? Allons-nous faire d'Omnisharp un produit à source fermée ? Afin que nous puissions nous assurer qu'il ne peut pas obtenir de nouvelles fonctionnalités qui enlèvent la « valeur » de Visual Studio ? Pour que nous ne donnions pas de fonctionnalités à Rider ? En quoi cela nous aide-t-il ? Ces décisions de leadership garantissent que Visual Studio sera toujours de deuxième classe par rapport à tout le reste du marché. Des mouvements comme ceux-ci nous nuisent non seulement avec les clients, mais aussi avec la façon dont nous construisons des produits en interne. Ils ne nous font pas seulement du mal avec la "communauté OSS", mais tout le monde dans la division des développeurs et Microsoft.

Si nous voulons être véritablement transparents à ce sujet, nous devons apporter ces modifications pour y remédier :

Nous avons besoin d'une chronologie complète, publiée publiquement, de la façon dont cela s'est produit et des personnes directement responsables de la manière dont cela a conduit à cela.
Nous ne devrions plus jamais précipiter un PR à travers. Il était clair dès le départ que la suppression du code était une mauvaise action, et si nous voulons vraiment des commentaires de la communauté, nous devons être prêts à écouter non pas après mais avant.
Si ces décisions ont été prises unilatéralement par les dirigeants, nous devons empêcher que cela ne se reproduise. Il y avait un conflit d'intérêt apparent entre les « besoins » de VS et ceux de dotnet. Il doit y avoir des freins et contrepoids pour empêcher toute personne, quelle que soit sa hiérarchie, de prendre des décisions comme celle-ci sans un véritable retour d'information de l'intérieur et de l'extérieur de la division.

Notre objectif ici n'est pas d'insulter une personne en particulier dans la direction qui aurait pu prendre cette décision. Au lieu de cela, il s'agit de résoudre le problème principal : personne ne devrait avoir autant de pouvoir pour avoir un impact direct sur un produit comme dotnet si proche de sa sortie. Quiconque dirige la division des développeurs pourrait faire les mêmes actions, ce que nous devons empêcher. Avoir des directives claires pour protéger ces produits qui constituent la base de tout ce qu'est Visual Studio fera non seulement de nous les meilleurs de sa catégorie en tant que gestionnaires de logiciels Open Source, mais nous aidera également à créer le meilleur IDE possible.

Merci Graeme pour le conseil.