Microsoft-utvikler kaller Management over håndtering av .Net Hot Reload-problem

Medlemmer av åpen kildekode-fellesskapet var nylig rasende på Microsoft for tilsynelatende med vilje å ha fjernet en funksjon fra åpen kildekode .Net 6-programvareutviklingsplattformen (som Microsoft administrerer), slik at profesjonelle utviklere i stedet ville bruke Visual Studio 2022, Microsofts ganske dyre, men veldig veldig dyre. kraftig IDE.

Det viser seg at utviklere i Microsoft var like sinte, og Microsofts reversering av beslutningen deres har ikke stilt dem, med mange frykter neste anledning der Microsoft plasserer sine kortsiktige økonomiske interesser over deres engasjement med åpen kildekode-fellesskapet.

Dette har resultert i utgivelsen av et anonymt brev til Microsofts ledelse der forfatteren direkte anklager selskapet for å lyve for å beskytte ledelsen.

De bemerker at Microsoft med vilje forsøkte å skjule fjerningen av Hot Reload ved å forhaste PR før .Net 6-utviklere kunne kommentere, og at Microsofts unnskyldning om at de ikke kunne fokusere på Hot Reload for både .Net 6 og VS 2022 ringte tom når det ikke var noe indikasjon på at arbeidet ikke kunne fullføres tilfredsstillende for begge.

De uttrykte bekymring for at Microsoft vil gjøre ytterligere anstrengelser for å lamme .Net 6 i et forsøk på å presse VS 2022, til tross for at open source-verktøy er ganske populære i Microsoft selv.

Forfatteren ba om en gjennomsiktig undersøkelse av hvordan Hot Reload ble trukket og endringer i Microsofts ledelse slik at slike forhastede beslutninger ikke kunne tas igjen.

Til tross for den noe voldsomme tonen som har fått mange til å tro at notatet ikke er ekte, har en rekke Microsoft MVP-er kommet frem og bekreftet at brevet faktisk er skrevet av en Microsoft-ansatt i DivDev-divisjonen.

Les hele brevet nedenfor:

Til ledelsen i Microsoft Developer Division,

De av oss som jobber i Microsoft Developer Division (DevDiv) vil gjerne svare på den nylige kontroversen rundt å trekke og gjeninnføre "dotnet watch"-funksjonen til dotnet 6. Selv om vi er takknemlige for at kjøligere hoder seiret og "dotnet watch" ble bevart, føler vi oss ikke sikre på at dette ikke vil skje igjen? snarere tvert imot.

For å vise dette punktet, vil vi se på det nylige blogginnlegget av Scott Hunter (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Basert på alt vi vet om situasjonen og hvordan Developer Division opererer, virker lite av det Scott skrev sant og motsier det som skjedde. For å være tydelig, dette er ikke et angrep på Scott Hunter; og i stedet viser det hvor langt andre er villige til å gå for å beskytte ledelsen.

"Som et team er vi forpliktet til at .NET skal være en åpen plattform og gjøre vår utvikling i det åpne. Det faktum at vi bestemte oss for å innta en åpen holdning som standard fra starten av for å utvikle Hot Reload-funksjonen er et bevis på det.»

Ingenting om pull-forespørselen var åpen. Vi nevnte det i et blogginnlegg (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) og skyndte oss ugjennomsiktig med PR for å unngå kommentarer. Hvordan kan vi si at vi er transparente når dette så klart er motsatt? Det er som om vi alle sammen visste at dette var galt, men vi måtte gå med på det likevel.

"De aller fleste av .NET-utviklerne bruker Visual Studio, og vi vil sørge for at VS leverer den beste opplevelsen for .NET 6."

Selv om dette er sant, betyr dette at vi ikke bryr oss om ikke Visual Studio-brukere? Hvordan ville det å trekke denne funksjonen så sent i utviklingen gjøre det slik at Visual Studio har den beste opplevelsen for Hot Reload? Det er fornærmende for de som ikke alltid bruker Visual Studio for sin dotnet-utvikling, og det sier at vi ikke forstår kundene våre eller til og med ansatte som bruker det vi bygger.

Vi bruker CLI, og vi bruker VS-kode. Slutt å late som noe annet.

"Vi gjorde en feil ved å utføre denne planen på måten den ble utført på. I vårt forsøk på å sikte, endte vi utilsiktet opp med å slette kildekoden i stedet for bare å ikke påkalle den kodebanen."

For å være tydelig, det er feigt å skylde på ingeniøren for denne "feilen". Problemet var å fjerne funksjonen, ikke hvordan de utførte den. Sier vi at hvis bare "slått den av" i stedet for å fjerne den, ville vi ikke ha tilbakeført endringen? Ville denne koden vært aktivt arbeidet med eller latt råtne?

"Når rullebanen blir kort for .NET 6-utgivelsen og Visual Studio 2022, valgte vi å fokusere på å bringe Hot Reload til VS2022 først."

For å vise at "Kvalitetskontroll" ikke var tilfelle med "dotnet watch", vil vi sammenligne det med et annet produkt vi forsinket: MAUI.

MAUI er i røff form. Det var klart av RC1 at kvaliteten ikke kom til å være høy nok når dotnet 6 ble sendt; det var for mye å fikse og ikke nok tid til å gjøre det. MAUI-teamet og dets partnere brakte disse problemene til ledelsen, noe som førte produktet tilbake til tidlig neste år.

Det var og er fortsatt ingen indikasjon på at "dotnet watch" var på samme sted. Å gå gjennom GitHub-problemene eller dotnet-teamets etterslep viser noen bekymring for at kvaliteten ikke var der. Tvert imot gikk det helt fint. Disse ville blitt tatt opp mye tidligere i utgivelsessyklusen vår hvis det var reelle kvalitetsproblemer, ikke tre uker før levering.

"Som det er sant med mange selskaper, lærer vi å balansere behovene til OSS-fellesskapet og å være en bedriftssponsor for .NET."

Hvis vi leser mellom linjene, er dette utsagnet sant. Vi er i konflikt med det vi legger inn i dotnet, Visual Studio og Visual Studio Code. Å holde Hot Reload som en "verdiøkning" for Visual Studio holder de låst til det betalte produktet og mindre grunn til å hoppe til VS Code. På en kald og kalkulert måte gir det total mening, og det er også absolutt tull.

Hva om team som jobber med Hot Reload for Visual Studio integrerte "dotnet watch" i produktene sine? Hva om ledelsen trakk disse funksjonene uker før den generelle utgivelsen? Hvordan ville det forbedre Visual Studio på noen måte? Kommer vi til å fortsette å fjerne deler fra CLI fordi vi er redd vi vil miste inntekter fra Visual Studio?

Måten vi bygger det beste Visual Studio på er ved å ha den beste kjøretiden på planeten. Når Visual Studio-teamet legger til funksjoner til grunnlaget for dotnet, har vi en konsistent base for alle å jobbe med og bidra med. Vi kan bygge den beste IDE ved å samarbeide i løpet av kjøretiden, og ikke gjøre våre åpen kildekode vilkårlig verre.

Hva blir det neste? Skal vi gjøre Omnisharp til et lukket kildeprodukt? Slik at vi kan forsikre oss om at den ikke kan få nye funksjoner som tar vekk fra «verdien» av Visual Studio? Slik at vi ikke gir bort funksjoner til Rider? Hvordan hjelper det oss i det hele tatt? Disse beslutningene fra ledelsen sørger for at Visual Studio alltid vil være andreklasses til alt annet på markedet. Bevegelser som disse skader ikke bare oss med kunder, men også hvordan vi bygger produkter internt. De skader oss ikke bare med "OSS-fellesskapet", men alle i Developer Division og Microsoft.

Hvis vi ønsker å være genuint transparente om dette, bør vi gjøre disse endringene for å gjøre dette riktig:

Vi trenger en fullstendig tidslinje, publisert offentlig, for hvordan dette skjedde og de direkte ansvarlige for hvordan det førte til dette.
Vi bør aldri haste en PR gjennom noen gang igjen. Det var klart fra starten at fjerning av koden var feil handling, og hvis vi virkelig ønsker tilbakemeldinger fra fellesskapet, må vi være villige til å lytte ikke etter, men før.
Hvis disse beslutningene ble tatt ensidig av lederne, må vi forhindre at det noen gang skjer igjen. Det var en tilsynelatende interessekonflikt mellom "behovene" til VS og de til dotnet. Det må være kontroller og balanser for å hindre enhver person, uansett hvor høyt de er, fra å ta avgjørelser som dette uten genuin tilbakemelding innenfra og ut av divisjonen.

Målet vårt her er ikke å fornærme noen spesifikk person i ledelsen som kan ha tatt denne avgjørelsen. I stedet er det for å fikse kjerneproblemet: Ingen skal ha så mye makt til å påvirke et produkt som dotnet så nærme utgivelsen direkte. Alle som leder Developer Division kan gjøre de samme handlingene, som vi må forhindre. Å ha klare retningslinjer for å beskytte disse produktene som danner grunnlaget for alt Visual Studio er, vil ikke bare gjøre oss til best i klassen som forvaltere av åpen kildekode-programvare, men også hjelpe oss med å bygge den beste IDE vi kan.

Takk, Graeme for tipset.