Microsoft-ontwikkelaar roept Management op over afhandeling van .Net Hot Reload-probleem

Leden van de open-sourcegemeenschap waren onlangs woedend op Microsoft omdat het blijkbaar opzettelijk een functie verwijderde van het open-source .Net 6-softwareontwikkelingsplatform (dat door Microsoft wordt beheerd), zodat professionele ontwikkelaars in plaats daarvan Visual Studio 2022 zouden gebruiken, Microsoft's vrij dure maar zeer krachtige IDE.

Het blijkt dat ontwikkelaars binnen Microsoft even boos waren, en Microsoft's herroeping van hun beslissing heeft hen niet gerustgesteld, en velen vrezen de volgende keer dat Microsoft zijn financiële kortetermijnbelangen plaatst boven hun betrokkenheid bij de open-sourcegemeenschap.

Dit heeft geresulteerd in de release van een anonieme brief aan het management van Microsoft waarin de auteur het bedrijf rechtstreeks beschuldigt van liegen om het management te beschermen.

Ze merken op dat Microsoft opzettelijk probeerde de verwijdering van Hot Reload te verbergen door de PR te haasten voordat .Net 6-ontwikkelaars commentaar konden geven en dat het excuus van Microsoft dat ze zich niet konden concentreren op Hot Reload voor zowel .Net 6 als VS 2022 hol klonk toen er geen indicatie dat het werk voor beiden niet naar tevredenheid kon worden afgerond.

Ze spraken hun bezorgdheid uit dat Microsoft verdere inspanningen zal leveren om .Net 6 te verlammen in een poging om VS 2022 te pushen, ondanks dat open source-tools behoorlijk populair zijn binnen Microsoft zelf.

De auteur vroeg om een ​​transparant onderzoek naar hoe Hot Reload werd ingetrokken en om wijzigingen in het management van Microsoft, zodat dergelijke overhaaste beslissingen niet opnieuw konden worden genomen.

Ondanks de ietwat schelle toon waardoor velen dachten dat het briefje niet echt is, zijn een aantal Microsoft MVP's naar voren gekomen en hebben bevestigd dat de brief inderdaad is geschreven door een Microsoft-medewerker in de DivDev-divisie.

Lees de brief hieronder volledig:

Aan het leiderschap van de Microsoft Developer Division,

Degenen onder ons die in de Microsoft Developer Division (DevDiv) werken, willen graag reageren op de recente controverse rond het trekken en herstellen van de "dotnet watch" -functie van dotnet 6. Hoewel we dankbaar zijn dat koelere hoofden de overhand hadden en "dotnet watch" bewaard is gebleven, hebben we er geen vertrouwen in dat dit niet meer zal gebeuren? Integendeel.

Om dit te laten zien, kijken we naar de recente blogpost van Scott Hunter (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Op basis van alles wat we weten over de situatie en hoe de Developer Division werkt, lijkt weinig van wat Scott schreef waar en in tegenspraak met wat er is gebeurd. Voor alle duidelijkheid: dit is geen aanval op Scott Hunter; en in plaats daarvan laat het zien hoe ver anderen bereid zijn te gaan om het management te beschermen.

“Als team zetten we ons in om .NET een open platform te laten zijn en onze ontwikkeling in de open lucht te doen. Het feit dat we besloten hebben om vanaf het begin standaard een open houding aan te nemen voor het ontwikkelen van de Hot Reload-functie is daar een bewijs van.”

Er stond niets open over de pull-request. We noemden het in een blogpost (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) en haastten ons ondoorzichtig om de PR te vermijden opmerkingen. Hoe kunnen we zeggen dat we transparant zijn als dit zo duidelijk het tegenovergestelde is? Het is alsof we allemaal collectief wisten dat dit verkeerd was, maar er toch mee moesten instemmen.

"De overgrote meerderheid van de .NET-ontwikkelaars gebruikt Visual Studio en we willen ervoor zorgen dat VS de beste ervaring voor .NET 6 levert."

Zelfs als dit waar is, houdt dit dan in dat we niet geven om niet-Visual Studio-gebruikers? Hoe zou het zo laat in ontwikkeling zijn om deze functie te gebruiken, zodat Visual Studio de beste ervaring heeft voor Hot Reload? Het is beledigend voor degenen die Visual Studio niet altijd gebruiken voor hun dotnet-ontwikkeling, en het zegt dat we onze klanten of zelfs werknemers die gebruiken wat we bouwen niet begrijpen.

We gebruiken CLI en we gebruiken VS-code. Stop met anders te doen.

“We hebben een fout gemaakt bij het uitvoeren van dit plan op de manier waarop het werd uitgevoerd. In onze poging om het bereik te vergroten, hebben we per ongeluk de broncode verwijderd in plaats van dat codepad gewoon niet aan te roepen.”

Voor alle duidelijkheid: de ingenieur de schuld geven van deze "fout" is laf. Het probleem was het verwijderen van de functie, niet hoe ze het uitvoerden. Zeggen we dat als we het alleen hadden "uitgezet" in plaats van het te verwijderen, we de wijziging niet zouden hebben teruggedraaid? Zou er actief aan deze code zijn gewerkt of zijn weggegooid?

"Omdat de startbaan kort wordt voor de .NET 6-release en Visual Studio 2022, hebben we ervoor gekozen om ons te concentreren op het eerst naar VS2022 brengen van Hot Reload."

Om aan te tonen dat "Quality Control" niet het geval was met "dotnet watch", zullen we het vergelijken met een ander product dat we hebben uitgesteld: MAUI.

MAUI is in ruwe vorm. Het was duidelijk door RC1 dat de kwaliteit niet hoog genoeg zou zijn tegen de tijd dat dotnet 6 verscheept werd; er was te veel om op te lossen en niet genoeg tijd om het te doen. Het MAUI-team en zijn partners hebben deze problemen onder de aandacht gebracht, waardoor het product begin volgend jaar terugkwam.

Er was en is nog steeds geen indicatie dat "dotnet watch" zich op dezelfde plaats bevond. Het doornemen van de GitHub-problemen noch de achterstand van het dotnet-team toont enige bezorgdheid aan dat de kwaliteit er niet was. Integendeel, het ging prima. Deze zouden veel eerder in onze releasecyclus ter sprake zijn gekomen als er echte kwaliteitsproblemen waren, niet drie weken voor verzending.

"Zoals bij veel bedrijven, leren we een evenwicht te vinden tussen de behoeften van de OSS-gemeenschap en een zakelijke sponsor voor .NET te zijn."

Als we tussen de regels door lezen, is deze bewering waar. We zijn in strijd met wat we in dotnet, Visual Studio en Visual Studio Code hebben gestopt. Door Hot Reload als een "waardetoevoeging" voor Visual Studio te houden, blijven degenen die opgesloten zitten in het betaalde product en minder reden om naar VS Code te springen. Op een koude en berekende manier is dat volkomen logisch, en het is ook absolute onzin.

Wat als teams die aan Hot Reload voor Visual Studio werken "dotnet watch" in hun producten zouden integreren? Wat als het leiderschap deze functies weken voor de algemene release zou verwijderen? Hoe zou dat Visual Studio op een of andere manier verbeteren? Gaan we onderdelen uit CLI blijven verwijderen omdat we bang zijn inkomsten uit Visual Studio te verliezen?

De manier waarop we de beste Visual Studio bouwen, is door de beste runtime ter wereld te hebben. Wanneer het Visual Studio-team functies toevoegt aan de basis van dotnet, hebben we een consistente basis voor iedereen om aan te werken en bij te dragen. We kunnen de beste IDE bouwen door tijdens runtime samen te werken en onze open-source producten niet willekeurig slechter te maken.

Wat is het volgende? Gaan we van Omnisharp een closed source-product maken? Zodat we ervoor kunnen zorgen dat het geen nieuwe functies krijgt die de "waarde" van Visual Studio wegnemen? Zodat we geen features weggeven aan Rider? Hoe helpt dat ons überhaupt? Deze beslissingen van het leiderschap zorgen ervoor dat Visual Studio altijd tweederangs zal zijn ten opzichte van al het andere op de markt. Dergelijke bewegingen doen ons niet alleen pijn bij klanten, maar ook bij de manier waarop we intern producten bouwen. Ze doen niet alleen ons pijn met de "OSS-gemeenschap", maar iedereen in de Developer Division en Microsoft.

Als we hier echt transparant over willen zijn, moeten we deze wijzigingen doorvoeren om dit recht te zetten:

We hebben een volledige, openbaar gemaakte tijdlijn nodig van hoe dit is gebeurd en van degenen die direct verantwoordelijk zijn voor hoe dit tot dit heeft geleid.
We zouden nooit meer een PR door moeten haasten. Het was vanaf het begin duidelijk dat het verwijderen van de code de verkeerde actie was, en als we echt feedback van de community willen, moeten we bereid zijn om niet achteraf, maar ervoor te luisteren.
Als deze beslissingen eenzijdig werden genomen door de leiders, moeten we voorkomen dat dit ooit nog gebeurt. Er was een schijnbaar belangenconflict tussen de "behoeften" van VS en die van dotnet. Er moeten checks and balances zijn om te voorkomen dat iemand, hoe hoog hij ook staat, dit soort beslissingen neemt zonder echte feedback van binnen en buiten de divisie.

Ons doel hier is niet om een ​​specifieke persoon in leiderschap te beledigen die deze beslissing heeft genomen. In plaats daarvan is het bedoeld om het kernprobleem op te lossen: niemand zou zoveel macht moeten hebben om een ​​product als dotnet zo dicht bij een directe release te beïnvloeden. Iedereen die de Developer Division leidt, zou dezelfde acties kunnen doen, wat we moeten voorkomen. Het hebben van duidelijke richtlijnen om deze producten te beschermen die de basis vormen van alles wat Visual Studio is, zal ons niet alleen de beste in zijn klasse maken als beheerders van Open Source-software, maar ons ook helpen de best mogelijke IDE te bouwen.

Bedankt, Graeme voor de tip.