Microsoft-udvikler kalder Management over håndtering af .Net Hot Reload-problem

Medlemmer af open source-fællesskabet var for nylig rasende på Microsoft for tilsyneladende med vilje at fjerne en funktion fra open source .Net 6-softwareudviklingsplatformen (som Microsoft administrerer), så professionelle udviklere i stedet ville bruge Visual Studio 2022, Microsofts ret dyre, men meget meget kraftfuld IDE.

Det viser sig, at udviklere i Microsoft var lige så vrede, og Microsofts omstødelse af deres beslutning har ikke beroliget dem, og mange frygter den næste lejlighed, hvor Microsoft placerer sine kortsigtede økonomiske interesser over deres engagement med open source-fællesskabet.

Dette har resulteret i udgivelsen af et anonymt brev til Microsofts ledelse hvor forfatteren direkte anklager virksomheden for at lyve for at beskytte ledelsen.

De bemærker, at Microsoft med vilje forsøgte at skjule fjernelsen af ​​Hot Reload ved at skynde sig PR, før .Net 6-udviklere kunne kommentere, og at Microsofts undskyldning om, at de ikke kunne fokusere på Hot Reload for både .Net 6 og VS 2022, lød hul, når der ikke var nogen angivelse af, at arbejdet ikke kunne udføres tilfredsstillende for begge.

De udtrykte bekymring for, at Microsoft vil gøre yderligere bestræbelser på at lamme .Net 6 i et forsøg på at presse VS 2022, på trods af at open source-værktøjer er ret populære i Microsoft selv.

Forfatteren bad om en gennemsigtig undersøgelse af, hvordan Hot Reload blev trukket og ændringer i Microsofts ledelse, så sådanne overilte beslutninger ikke kunne træffes igen.

På trods af den noget stride tone, som har fået mange til at tro, at notatet ikke er ægte, har en række Microsoft MVP'er stået frem og bekræftet, at brevet faktisk er skrevet af en Microsoft-medarbejder i DivDev-divisionen.

Læs hele brevet herunder:

Til ledelsen i Microsoft Developer Division,

De af os, der arbejder i Microsoft Developer Division (DevDiv), vil gerne svare på den nylige kontrovers omkring at trække og genindsætte "dotnet watch"-funktionen i dotnet 6. Selvom vi er taknemmelige for, at køligere hoveder sejrede og "dotnet watch" blev bevaret, føler vi os ikke sikre på, at dette ikke vil ske igen? tværtimod.

For at vise dette punkt vil vi se på det seneste blogindlæg af Scott Hunter (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Baseret på alt, hvad vi ved om situationen, og hvordan udviklerdivisionen fungerer, virker lidt af det, Scott skrev, sandt og modsiger det, der skete. For at være klar, er dette ikke et angreb på Scott Hunter; og i stedet viser det, hvor langt andre er villige til at gå for at beskytte ledelsen.

“Som et team er vi forpligtet til at .NET er en åben platform og udvikler os i det fri. Selve det faktum, at vi besluttede at indtage en åben holdning som standard fra starten for at udvikle Hot Reload-funktionen er et vidnesbyrd om det."

Intet om pull-anmodningen var åben. Vi nævnte det i et blogindlæg (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) og skyndte os uigennemsigtigt PR for at undgå kommentarer. Hvordan kan vi sige, at vi er gennemsigtige, når det så klart er det modsatte? Det er, som om vi alle sammen vidste, at dette var forkert, men alligevel måtte gå med på det.

"Størstedelen af ​​.NET-udviklerne bruger Visual Studio, og vi vil sikre os, at VS leverer den bedste oplevelse til .NET 6."

Selvom dette er sandt, betyder det, at vi er ligeglade med ikke Visual Studio-brugere? Hvordan ville det at trække denne funktion så sent i udviklingen gøre det, så Visual Studio har den bedste oplevelse til Hot Reload? Det er fornærmende for dem, der ikke altid bruger Visual Studio til deres dotnet-udvikling, og det siger, at vi ikke forstår vores kunder eller endda medarbejdere, der bruger det, vi bygger.

Vi bruger CLI, og vi bruger VS-kode. Lad være med at foregive noget andet.

"Vi begik en fejl ved at udføre denne plan på den måde, den blev udført på. I vores bestræbelser på at scope, endte vi utilsigtet med at slette kildekoden i stedet for bare ikke at påberåbe sig den kodesti."

For at være klar, er det fejt at give ingeniøren skylden for denne "fejltagelse". Problemet var at fjerne funktionen, ikke hvordan de udførte den. Siger vi, at hvis vi kun "slukkede det" i stedet for at fjerne det, ville vi ikke have fortrudt ændringen? Ville denne kode være blevet aktivt arbejdet på eller ladet rådne?

"Da landingsbanen blev kort for .NET 6-udgivelsen og Visual Studio 2022, valgte vi at fokusere på at bringe Hot Reload til VS2022 først."

For at vise, at "Quality Control" ikke var tilfældet med "dotnet watch", vil vi sammenligne det med et andet produkt, vi forsinket: MAUI.

MAUI er i hård form. Det var klart af RC1, at kvaliteten ikke ville være høj nok på det tidspunkt, hvor dotnet 6 blev afsendt; der var for meget at rette og ikke tid nok til at gøre det. MAUI-teamet og dets partnere bragte disse spørgsmål til ledelsen, hvilket skubbede produktet tilbage til begyndelsen af ​​næste år.

Der var og er stadig ingen indikation af, at "dotnet watch" var samme sted. At gennemgå GitHub-problemerne eller dotnet-teamets efterslæb viser nogen bekymring for, at kvaliteten ikke var der. Tværtimod gik det fint. Disse ville være blevet taget op meget tidligere i vores udgivelsescyklus, hvis der var reelle kvalitetsproblemer, ikke tre uger før afsendelse.

"Som det er tilfældet med mange virksomheder, lærer vi at balancere OSS-fællesskabets behov og at være en virksomhedssponsor for .NET."

Hvis vi læser mellem linjerne, er dette udsagn sandt. Vi er i konflikt med det, vi lægger i dotnet, Visual Studio og Visual Studio Code. Ved at holde Hot Reload som en "værditilvækst" til Visual Studio holder dem låst til det betalte produkt og mindre grund til at hoppe til VS Code. På en kold og beregnet måde giver det total mening, og det er også absolut nonsens.

Hvad hvis teams, der arbejder på Hot Reload til Visual Studio, integrerede "dotnet watch" i deres produkter? Hvad hvis ledelse trak disse funktioner uger før den generelle udgivelse? Hvordan ville det forbedre Visual Studio på nogen måde? Vil vi blive ved med at fjerne dele fra CLI, fordi vi er bange for, at vi mister indtægter fra Visual Studio?

Den måde, vi bygger det bedste Visual Studio på, er ved at have den bedste runtime på planeten. Når Visual Studio-teamet tilføjer funktioner til grundlaget for dotnet, har vi en konsistent base for alle at arbejde på og bidrage med. Vi kan bygge den bedste IDE ved at samarbejde i kørselstiden, og ikke gøre vores open source-produkter vilkårligt værre.

Hvad er det næste? Skal vi gøre Omnisharp til et lukket kildeprodukt? Så vi kan sikre os, at det ikke kan få nye funktioner, der fjerner "værdien" af Visual Studio? Så vi ikke giver funktioner væk til Rider? Hvordan hjælper det os overhovedet? Disse beslutninger truffet af ledere sikrer, at Visual Studio altid vil være andenrangs i forhold til alt andet på markedet. Bevægelser som disse skader ikke kun os med kunder, men også hvordan vi bygger produkter internt. De skader os ikke kun med "OSS-fællesskabet", men alle i Developer Division og Microsoft.

Hvis vi ønsker at være virkelig gennemsigtige omkring dette, bør vi foretage disse ændringer for at gøre dette rigtigt:

Vi har brug for en komplet tidslinje, offentliggjort offentligt, over, hvordan dette skete, og de direkte ansvarlige for, hvordan det førte til dette.
Vi bør aldrig haste en PR igennem nogensinde igen. Det var klart fra starten, at fjernelse af koden var den forkerte handling, og hvis vi virkelig ønsker feedback fra fællesskabet, skal vi være villige til at lytte ikke efter, men før.
Hvis disse beslutninger blev truffet ensidigt af lederne, er vi nødt til at forhindre, at det nogensinde sker igen. Der var en tilsyneladende interessekonflikt mellem VS's og dotnets "behov". Der skal være kontrol og balance for at forhindre enhver person, uanset hvor højt de er, i at træffe beslutninger som denne uden ægte feedback indefra og ud af divisionen.

Vores mål her er ikke at fornærme nogen specifik person i ledelsen, som kan have truffet denne beslutning. I stedet er det for at løse kerneproblemet: Ingen burde have så meget magt til at påvirke et produkt som dotnet så tæt på at blive frigivet direkte. Enhver, der leder Developer Division, kunne gøre de samme handlinger, som vi skal forhindre. At have klare retningslinjer for at beskytte disse produkter, der danner grundlaget for alt, hvad Visual Studio er, vil ikke kun gøre os til de bedste i klassen som forvaltere af Open Source-software, men også hjælpe os med at opbygge den bedste IDE, vi kan.

Tak, Graeme for tippet.