Microsoftの開発者は、.Net HotReloadの問題の処理について管理を呼びかけています

オープンソースコミュニティのメンバーは最近、オープンソースの.Net 6ソフトウェア開発プラットフォーム（Microsoftが管理している）から機能を意図的に削除して、プロの開発者が代わりにMicrosoftの非常に高価であるが非常に高価なVisual Studio 2022を使用するように、Microsoftに激怒しました。強力なIDE。

マイクロソフト内の開発者も同様に怒っていたことがわかりました。 Microsoftによる決定の取り消し マイクロソフトがオープンソースコミュニティとの関わりに短期的な経済的利益をもたらす次の機会を多くの人が恐れて、彼らを悩ませていません。

これにより、 マイクロソフトの経営陣への匿名の手紙 作者は、経営者を保護するために会社が嘘をついていると直接非難します。

彼らは、Microsoftが.Net 6開発者がコメントする前にPRを急ぐことによって意図的にホットリロードの削除を隠そうとしたこと、そして.Net6とVS2022の両方のホットリロードに集中できなかったというMicrosoftの言い訳は、両方の作業を十分に完了できなかったことを示します。

彼らは、Microsoft自体の中でオープンソースツールが非常に人気があるにもかかわらず、MicrosoftがVS6をプッシュするために.Net2022を不自由にするためのさらなる努力をすることへの懸念を表明しました。

著者は、Hot Reloadがどのようにプルされ、Microsoftの管理が変更されたのかについての透過的な調査を求めたため、このような急な決定を二度と行うことはできませんでした。

多くの人がメモが本物ではないと信じるようなやや厳しい口調にもかかわらず、多くのMicrosoft MVPが前に出て、その手紙がDivDev部門のMicrosoft従業員によって実際に書かれたことを確認しました。

以下の手紙を完全に読んでください：

マイクロソフト開発者部門のリーダーシップに、

Microsoft Developer Division（DevDiv）で働く私たちの人々は、dotnet6の「dotnetwatch」機能のプルと復元をめぐる最近の論争に対応したいと思っています。保存されていたので、これが二度と起こらないとは確信していませんか？まったく逆です。

この点を示すために、Scott Hunterによる最近のブログ投稿（https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/）を見ていきます。 状況と開発者部門の運営方法について私たちが知っているすべてに基づいて、スコットが書いたことのほとんどは真実ではなく、起こったことと矛盾しています。 明確にするために、これはスコットハンターへの攻撃ではありません。 代わりに、他の人が経営陣を保護するためにどれだけ進んで進んでいるかを示しています。

「チームとして、私たちは.NETがオープンプラットフォームであり、オープンで開発を行うことに取り組んでいます。 ホットリロード機能の開発を最初からデフォルトでオープンポスチャにすることにしたという事実は、その証拠です。」

プルリクエストについては何も開かれていませんでした。 ブログ投稿（https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/）で言及し、PRを不透明に急いで回避しましたコメント。 これが明らかに反対である場合、どうすれば私たちは透明であると言うことができますか？ それは、私たち全員がこれが間違っていることを集合的に知っていたが、とにかくそれに沿って行かなければならなかったかのようです。

「.NET開発者の大多数はVisualStudioを使用しており、VSが.NET6で最高のエクスペリエンスを提供できるようにしたいと考えています。」

これが真実であるとしても、これは、Visual Studio以外のユーザーを気にしないことを意味しますか？ この機能を開発の非常に遅い段階でプルすると、Visual Studioがホットリロードに最適なエクスペリエンスを提供できるようになりますか？ ドットネットの開発にVisualStudioを常に使用しているとは限らない人々を侮辱し、私たちが構築したものを使用している顧客や従業員さえも理解していないと言っています。

CLIを使用し、VSCodeを使用します。 そうでなければふりをやめなさい。

「私たちは、この計画の実行方法を間違えました。 スコープを設定するために、コードパスを呼び出さないだけでなく、誤ってソースコードを削除してしまいました。」

明確にするために、この「間違い」についてエンジニアを非難することは臆病です。 問題は、機能の削除であり、実行方法ではありませんでした。 削除するのではなく、「オフにする」だけでは、変更を元に戻せなかったと言っているのでしょうか。 このコードは積極的に処理されたのでしょうか、それとも腐敗したままでしたか？

「.NET6リリースとVisualStudio 2022の滑走路が短くなっているため、最初にVS2022にホットリロードを導入することに重点を置くことにしました。」

「品質管理」が「ドットネットウォッチ」の場合ではなかったことを示すために、遅延した別の製品であるMAUIと比較します。

マウイは大まかな形です。 ドットネット1が出荷されるまでに、品質が十分に高くならないことはRC6によって明らかでした。 修正するには多すぎて、修正するのに十分な時間がありませんでした。 MAUIチームとそのパートナーは、これらの問題をリーダーシップに持ち込み、製品を来年初めに戻しました。

「ドットネットウォッチ」が同じ場所にあったという兆候はありましたが、今でもありません。 GitHubの問題やdotnetチームのバックログを調べると、品質がそこになかったという懸念がわかります。 それどころか、それはうまくやっていた。 出荷のXNUMX週間前ではなく、実際の品質上の懸念があった場合、これらはリリースサイクルのはるかに早い段階で発生していました。

「多くの企業に当てはまるように、私たちはOSSコミュニティのニーズのバランスを取り、.NETの企業スポンサーになることを学んでいます。」

行間を読むと、このステートメントは真です。 dotnet、Visual Studio、およびVisual StudioCodeに入れたものと競合します。 Visual Studioの「付加価値」としてホットリロードを維持することで、有料製品に固定され、VSCodeにジャンプする理由が少なくなります。 冷静で計算された方法で、それは完全に理にかなっています、そしてそれはまた絶対にナンセンスです。

Visual Studioのホットリロードに取り組んでいるチームが「ドットネットウォッチ」を製品に統合した場合はどうなりますか？ リーダーシップが一般リリースの数週間前にこれらの機能を引き出した場合はどうなりますか？ それはどのようにVisualStudioを改善しますか？ Visual Studioからの収益が失われるのではないかと心配しているので、CLIからパーツを削除し続けるつもりですか？

最高のVisualStudioを構築する方法は、地球上で最高のランタイムを使用することです。 Visual Studioチームがdotnetの基盤に機能を追加すると、誰もが作業して貢献できる一貫した基盤が得られます。 オープンソースの製品を恣意的に悪化させることなく、ランタイムでコラボレーションすることで最高のIDEを構築できます。

次は何ですか？ Omnisharpをクローズドソース製品にするつもりですか？ Visual Studioの「価値」を損なう新機能を確実に取得できないようにするには、どうすればよいでしょうか。 ライダーに機能を提供しないように？ それはどのように私たちを助けますか？ リーダーシップによるこれらの決定により、VisualStudioは常に市場に出回っている他のすべてのものに次ぐものになります。 このような動きは、お客様を傷つけるだけでなく、社内で製品を構築する方法にも悪影響を及ぼします。 彼らは「OSSコミュニティ」だけでなく、開発者部門とマイクロソフトの全員を傷つけています。

これについて真に透明にしたい場合は、これを正しくするために次の変更を行う必要があります。

これがどのように起こったか、そしてそれがどのようにこれにつながったかについて直接責任を負う人々について、公に投稿された完全なタイムラインが必要です。
私たちは二度とPRを急ぐべきではありません。 コードを削除することは間違った行動であることが最初から明らかでした。コミュニティからのフィードバックが本当に必要な場合は、後ではなく前に喜んで耳を傾ける必要があります。
これらの決定が指導者によって一方的に行われた場合、それが二度と起こらないようにする必要があります。 VSの「ニーズ」とdotnetの「ニーズ」の間には明らかな利益の対立がありました。 どんなに高くても、部門内外からの真のフィードバックなしにこのような決定を下すことができないように、チェックとバランスを取る必要があります。

ここでの私たちの目標は、この決定を下した可能性のあるリーダーシップの特定の人物を侮辱することではありません。 代わりに、コアの問題を修正することです。直接リリースに近いdotnetのような製品に影響を与えるほどの力を持っている人はいないはずです。 開発者部門を率いる人なら誰でも同じ行動をとることができますが、それを防ぐ必要があります。 Visual Studioのすべての基盤を形成するこれらの製品を保護するための明確なガイドラインがあると、オープンソースソフトウェアのスチュワードとしてクラス最高になるだけでなく、可能な限り最高のIDEを構築するのにも役立ちます。

先端をありがとう、Graeme。