Der Microsoft-Entwickler beklagt das Management wegen der Behandlung des .Net Hot Reload-Problems

Mitglieder der Open-Source-Community waren kürzlich wütend auf Microsoft, weil es anscheinend absichtlich eine Funktion von der Open-Source-Softwareentwicklungsplattform .Net 6 (die von Microsoft verwaltet wird) entfernt hat, damit professionelle Entwickler stattdessen Visual Studio 2022 verwenden, Microsofts recht teures, aber sehr teures leistungsstarke IDE.

Es stellte sich heraus, dass Entwickler innerhalb von Microsoft gleichermaßen wütend waren und Microsofts Umkehrung ihrer Entscheidung hat sie nicht besänftigt, und viele befürchten das nächste Mal, dass Microsoft seine kurzfristigen finanziellen Interessen über ihr Engagement in der Open-Source-Community stellt.

Dies hat zur Veröffentlichung von geführt ein anonymer Brief an das Microsoft-Management in dem der Autor das Unternehmen direkt beschuldigt, gelogen zu haben, um das Management zu schützen.

Sie stellen fest, dass Microsoft absichtlich versucht hat, die Entfernung von Hot Reload zu verbergen, indem es die PR übereilt hat, bevor .Net 6-Entwickler kommentieren konnten, und dass Microsofts Entschuldigung, dass sie sich nicht auf Hot Reload für .Net 6 und VS 2022 konzentrieren konnten, hohl klang, als es keine gab Hinweis darauf, dass die Arbeit für beide nicht zufriedenstellend abgeschlossen werden konnte.

Sie äußerten sich besorgt darüber, dass Microsoft weitere Anstrengungen unternehmen wird, um .Net 6 lahmzulegen, um VS 2022 voranzutreiben, obwohl Open-Source-Tools bei Microsoft selbst sehr beliebt sind.

Der Autor bat um eine transparente Untersuchung darüber, wie Hot Reload zurückgezogen wurde, und um Änderungen im Management von Microsoft, damit solche vorschnellen Entscheidungen nicht noch einmal getroffen werden können.

Trotz des etwas schrillen Tons, der viele zu der Annahme veranlasst hat, dass die Notiz nicht echt ist, haben sich eine Reihe von Microsoft MVPs gemeldet und bestätigt, dass der Brief tatsächlich von einem Microsoft-Mitarbeiter in der DivDev-Abteilung geschrieben wurde.

Lesen Sie den folgenden Brief vollständig:

An die Führung der Microsoft Developer Division,

Diejenigen von uns, die in der Microsoft Developer Division (DevDiv) arbeiten, möchten auf die jüngste Kontroverse um das Zurückziehen und Wiedereinführen der „dotnet watch“-Funktion von dotnet 6 reagieren. Wir sind zwar dankbar, dass kühlere Köpfe sich durchgesetzt haben und „dotnet watch“ erhalten blieb, sind wir nicht zuversichtlich, dass dies nicht noch einmal passieren wird – ganz im Gegenteil.

Um diesen Punkt zu zeigen, schauen wir uns den letzten Blogbeitrag von Scott Hunter an (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Basierend auf allem, was wir über die Situation und die Arbeitsweise der Developer Division wissen, scheint wenig von dem, was Scott geschrieben hat, wahr zu sein und widerspricht dem, was passiert ist. Um es klarzustellen, dies ist kein Angriff auf Scott Hunter; Stattdessen zeigt es, wie weit andere bereit sind zu gehen, um das Management zu schützen.

„Als Team setzen wir uns dafür ein, dass .NET eine offene Plattform ist und dass wir unsere Entwicklung offen durchführen. Allein die Tatsache, dass wir uns bei der Entwicklung des Hot Reload-Features von Anfang an für eine offene Haltung entschieden haben, ist ein Beweis dafür.“

An der Pull-Anfrage war nichts offen. Wir haben es in einem Blogbeitrag (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) erwähnt und die PR undurchsichtig überstürzt, um es zu vermeiden Bemerkungen. Wie können wir sagen, dass wir transparent sind, wenn dies so klar das Gegenteil ist? Es ist, als ob wir alle kollektiv wüssten, dass dies falsch ist, aber trotzdem damit einverstanden sein müssten.

„Die überwiegende Mehrheit der .NET-Entwickler verwendet Visual Studio, und wir möchten sicherstellen, dass VS das beste Erlebnis für .NET 6 bietet.“

Selbst wenn dies zutrifft, bedeutet dies, dass wir uns nicht um Benutzer von Visual Studio kümmern? Wie würde das Entfernen dieses Features so spät in der Entwicklung dazu führen, dass Visual Studio die beste Erfahrung für Hot Reload bietet? Es ist beleidigend für diejenigen, die Visual Studio nicht immer für ihre Dotnet-Entwicklung verwenden, und es besagt, dass wir unsere Kunden oder sogar Mitarbeiter nicht verstehen, die das verwenden, was wir bauen.

Wir verwenden CLI und wir verwenden VS Code. Hör auf, etwas anderes vorzutäuschen.

„Wir haben einen Fehler gemacht, als wir diesen Plan so ausgeführt haben, wie er ausgeführt wurde. Bei unseren Bemühungen, den Geltungsbereich zu ermitteln, haben wir versehentlich den Quellcode gelöscht, anstatt diesen Codepfad einfach nicht aufzurufen.“

Um es klar zu sagen, den Ingenieur für diesen „Fehler“ verantwortlich zu machen, ist feige. Das Problem bestand darin, das Feature zu entfernen, nicht, wie sie es ausführten. Wollen wir damit sagen, dass wir die Änderung nicht rückgängig gemacht hätten, wenn wir sie nur „ausgeschaltet“ hätten, anstatt sie zu entfernen? Wäre dieser Code aktiv bearbeitet oder verrottet worden?

„Da die Landebahn für die Veröffentlichung von .NET 6 und Visual Studio 2022 knapp wird, haben wir uns entschieden, uns darauf zu konzentrieren, Hot Reload zuerst auf VS2022 zu bringen.“

Um zu zeigen, dass „Qualitätskontrolle“ bei „dotnet watch“ nicht der Fall war, vergleichen wir es mit einem anderen Produkt, das wir verzögert haben: MAUI.

MAUI ist in grober Verfassung. RC1 war klar, dass die Qualität zum Zeitpunkt der Auslieferung von dotnet 6 nicht hoch genug sein würde; Es gab zu viel zu reparieren und nicht genug Zeit dafür. Das MAUI-Team und seine Partner brachten diese Probleme an die Spitze, wodurch das Produkt auf Anfang nächsten Jahres verschoben wurde.

Es gab und gibt keinen Hinweis darauf, dass „dotnet watch“ am gleichen Ort war. Das Durchgehen der GitHub-Probleme oder des Rückstands des dotnet-Teams zeigt Bedenken, dass die Qualität nicht vorhanden war. Im Gegenteil, es lief gut. Diese wären viel früher in unserem Veröffentlichungszyklus zur Sprache gebracht worden, wenn es echte Qualitätsbedenken gegeben hätte, nicht drei Wochen vor dem Versand.

„Wie bei vielen Unternehmen lernen wir, die Bedürfnisse der OSS-Community in Einklang zu bringen und ein Unternehmenssponsor für .NET zu sein.“

Wenn wir zwischen den Zeilen lesen, ist diese Aussage wahr. Wir stehen in Konflikt mit dem, was wir in dotnet, Visual Studio und Visual Studio Code einfügen. Hot Reload als „Mehrwert“ für Visual Studio beizubehalten, hält diese an das kostenpflichtige Produkt gebunden und weniger Grund, zu VS Code zu springen. Kalt und kalkuliert macht das total Sinn, und es ist auch absoluter Nonsens.

Was wäre, wenn Teams, die an Hot Reload für Visual Studio arbeiten, „dotnet watch“ in ihre Produkte integrieren würden? Was wäre, wenn die Führung diese Funktionen Wochen vor der allgemeinen Veröffentlichung zurückziehen würde? Wie würde das Visual Studio in irgendeiner Weise verbessern? Werden wir weiterhin Teile von CLI entfernen, weil wir befürchten, dass wir Einnahmen aus Visual Studio verlieren?

Wir bauen das beste Visual Studio, indem wir die beste Laufzeit der Welt haben. Wenn das Visual Studio-Team Features zur Grundlage von dotnet hinzufügt, haben wir eine konsistente Basis, an der alle arbeiten und Beiträge leisten können. Wir können die beste IDE bauen, indem wir zur Laufzeit zusammenarbeiten, ohne unsere Open-Source-Produkte willkürlich zu verschlechtern.

Was kommt als nächstes? Werden wir Omnisharp zu einem Closed-Source-Produkt machen? Damit wir sicherstellen können, dass es keine neuen Features bekommt, die den „Wert“ von Visual Studio schmälern? Damit wir keine Features an Rider verschenken? Wie hilft uns das überhaupt? Diese Entscheidungen der Führung stellen sicher, dass Visual Studio im Vergleich zu allem anderen auf dem Markt immer zweitklassig sein wird. Schritte wie diese schaden uns nicht nur bei den Kunden, sondern auch bei der internen Entwicklung von Produkten. Sie schaden nicht nur uns mit der „OSS-Community“, sondern allen in der Developer Division und Microsoft.

Wenn wir diesbezüglich wirklich transparent sein wollen, sollten wir diese Änderungen vornehmen, um dies richtig zu machen:

Wir brauchen eine vollständige, öffentlich veröffentlichte Chronik darüber, wie dies geschah und wer direkt dafür verantwortlich ist, wie es dazu geführt hat.
Wir sollten nie wieder eine PR überstürzen. Es war von Anfang an klar, dass das Entfernen des Codes der falsche Weg war, und wenn wir wirklich Feedback von der Community wollen, müssen wir bereit sein, nicht danach, sondern vorher zuzuhören.
Wenn diese Entscheidungen einseitig von den Führungskräften getroffen wurden, müssen wir verhindern, dass dies jemals wieder passiert. Es gab einen offensichtlichen Interessenkonflikt zwischen den „Bedürfnissen“ von VS und denen von dotnet. Es muss Kontrollmechanismen geben, um zu verhindern, dass Personen, egal wie hoch sie sind, solche Entscheidungen ohne echtes Feedback von innerhalb und außerhalb der Abteilung treffen.

Unser Ziel ist hier nicht, eine bestimmte Person in der Führung zu beleidigen, die diese Entscheidung getroffen haben könnte. Stattdessen soll das Kernproblem behoben werden: Niemand sollte so viel Macht haben, ein Produkt wie dotnet so kurz vor der Veröffentlichung direkt zu beeinflussen. Jeder, der die Developer Division leitet, könnte die gleichen Aktionen ausführen, was wir verhindern müssen. Klare Richtlinien zum Schutz dieser Produkte zu haben, die die Grundlage von allem bilden, was Visual Studio ist, wird uns nicht nur als Verwalter von Open-Source-Software zum Klassenbesten machen, sondern uns auch dabei helfen, die bestmögliche IDE zu entwickeln.

Danke Greme für den Tipp.