Vývojář společnosti Microsoft volá Management kvůli řešení problému .Net Hot Reload

Členové open-source komunity byli nedávno rozzlobeni na Microsoft za to, že zjevně záměrně odstranil funkci z open-source platformy pro vývoj softwaru .Net 6 (kterou Microsoft spravuje), aby profesionální vývojáři místo toho používali Visual Studio 2022, poměrně drahé, ale velmi výkonné IDE.

Ukázalo se, že vývojáři uvnitř Microsoftu byli stejně naštvaní a Microsoft zvrátil své rozhodnutí neuklidnil je, mnozí se obávají příští příležitosti, kdy Microsoft upřednostní své krátkodobé finanční zájmy nad jejich zapojením do open-source komunity.

To vedlo k vydání anonymní dopis vedení společnosti Microsoft ve kterém autor přímo obviňuje společnost ze lži, aby ochránil management.

Poznamenávají, že Microsoft se úmyslně pokusil skrýt odstranění Hot Reload tím, že uspěchal PR, než mohli vývojáři .Net 6 komentovat, a že výmluva Microsoftu, že se nemohli soustředit na Hot Reload pro .Net 6 i VS 2022, zazněla prázdně, když neexistovala žádná což naznačuje, že práce nemohla být dokončena uspokojivě pro oba.

Vyjádřili obavy, že Microsoft vynaloží další úsilí na ochromení .Net 6 ve snaze prosadit VS 2022, přestože open source nástroje jsou v samotném Microsoftu docela populární.

Autor požádal o transparentní vyšetřování toho, jak bylo Hot Reload staženo a změny ve vedení Microsoftu, aby nebylo možné znovu dělat taková unáhlená rozhodnutí.

Navzdory poněkud pronikavému tónu, který způsobil, že mnozí věřili, že poznámka není skutečná, se ozvalo několik MVP společnosti Microsoft a potvrdilo, že dopis skutečně napsal zaměstnanec společnosti Microsoft v divizi DivDev.

Přečtěte si celý dopis níže:

Vedení divize Microsoft Developer Division,

Ti z nás, kteří pracujeme v Microsoft Developer Division (DevDiv), by rádi reagovali na nedávnou kontroverzi týkající se stažení a obnovení funkce „dotnet watch“ dotnet 6. I když jsme vděčni, že převládly chladnější hlavy a „dotnet watch“ byl zachován, nejsme si jisti, že se to nebude opakovat? Právě naopak.

Abychom to ukázali, podíváme se na nedávný blogový příspěvek Scotta Huntera (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Na základě všeho, co víme o situaci ao tom, jak vývojová divize funguje, se jen málo z toho, co Scott napsal, zdá pravdivé a je v rozporu s tím, co se stalo. Aby bylo jasno, toto není útok na Scotta Huntera; a místo toho ukazuje, jak daleko jsou ostatní ochotni zajít, aby ochránili management.

„Jako tým jsme odhodláni k tomu, aby .NET byla otevřená platforma a náš vývoj probíhal otevřeně. Svědčí o tom i samotný fakt, že jsme se od začátku rozhodli při vývoji funkce Hot Reload standardně zaujmout otevřený postoj.“

Nic o požadavku na stažení nebylo otevřené. Zmínili jsme to v příspěvku na blogu (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) a neprůhledně jsme spěchali s PR, abychom se vyhnuli komentáře. Jak můžeme říci, že jsme transparentní, když je to tak jasně naopak? Je to, jako bychom všichni společně věděli, že je to špatně, ale stejně jsme s tím museli souhlasit.

„Naprostá většina vývojářů .NET používá Visual Studio a my se chceme ujistit, že VS poskytuje nejlepší prostředí pro .NET 6.“

I když je to pravda, znamená to, že se nestaráme o uživatele, kteří nejsou uživateli sady Visual Studio? Jak by tato funkce mohla být tak pozdě ve vývoji, aby Visual Studio mělo nejlepší zkušenosti s Hot Reload? Je to urážlivé pro ty, kteří ne vždy používají Visual Studio pro svůj dotnet vývoj, a říká, že nerozumíme našim zákazníkům nebo dokonce zaměstnancům, kteří používají to, co vytváříme.

Používáme CLI a používáme VS Code. Přestaňte předstírat opak.

„Udělali jsme chybu při provádění tohoto plánu způsobem, jakým byl proveden. V našem úsilí o rozsah jsme nedopatřením skončili smazáním zdrojového kódu, místo abychom tuto cestu kódu prostě nevyvolali.“

Aby bylo jasno, obviňovat inženýra z této „chyby“ je zbabělé. Problém byl v odstranění funkce, ne v tom, jak to provedli. Říkáme, že kdybychom to pouze „vypnuli“ místo toho, abychom to odstranili, nevrátili bychom změnu? Bylo by na tomto kódu aktivně zpracováno nebo bylo ponecháno shnít?

„Vzhledem k tomu, že se dráha pro vydání .NET 6 a Visual Studio 2022 zkracuje, rozhodli jsme se zaměřit nejprve na Hot Reload na VS2022.“

Abychom ukázali, že „kontrola kvality“ nebyl případ „dotnet watch“, porovnáme je s dalším produktem, který jsme odložili: MAUI.

MAUI je v hrubém stavu. RC1 bylo jasné, že kvalita nebude v době expedice dotnet 6 dostatečně vysoká; bylo toho příliš mnoho k opravě a málo času na to. Tým MAUI a jeho partneři přinesli tyto problémy vedení, což posunulo produkt zpět na začátek příštího roku.

Nic nenasvědčovalo tomu, že by na stejném místě byly „dotnet watch“. Procházení problémů GitHubu ani nevyřízených záležitostí týmu dotnet ukazuje, že neexistují žádné obavy, že by tam nebyla kvalita. Naopak, šlo to dobře. Ty by byly uvedeny mnohem dříve v našem cyklu vydání, pokud by existovaly skutečné obavy o kvalitu, ne tři týdny před odesláním.

„Jak je tomu u mnoha společností, učíme se vyvažovat potřeby komunity OSS a být firemním sponzorem .NET.“

Pokud čteme mezi řádky, je toto tvrzení pravdivé. Jsme v rozporu s tím, co vkládáme do dotnet, Visual Studio a Visual Studio Code. Udržování Hot Reload jako „přidané hodnoty“ pro Visual Studio udržuje ty, kdo jsou uzamčeni v placeném produktu, a nemají důvod přejít na VS Code. Chladným a vypočítavým způsobem to dává totální smysl a je to také absolutní nesmysl.

Co kdyby týmy pracující na Hot Reload pro Visual Studio integrovaly „dotnet watch“ do svých produktů? Co kdyby vedení stáhlo tyto funkce týdny před obecným vydáním? Jak by to nějakým způsobem zlepšilo Visual Studio? Budeme nadále odstraňovat části z CLI, protože se bojíme, že přijdeme o příjmy z Visual Studia?

Nejlepší Visual Studio vytváříme tak, že máme nejlepší běhové prostředí na planetě. Když tým Visual Studio přidá funkce k základu dotnet, máme konzistentní základnu, na které může každý pracovat a přispívat. Můžeme vytvořit nejlepší IDE spoluprací za běhu, aniž bychom svévolně zhoršovali naše open-source produkty.

Co bude dál? Uděláme z Omnisharpu uzavřený produkt? Abychom se mohli ujistit, že nemůže získat nové funkce, které ubírají na „hodnotě“ sady Visual Studio? Abychom neprozradili vlastnosti Riderovi? Jak nám to vůbec pomáhá? Tato rozhodnutí vedení zajišťují, že Visual Studio bude vždy druhořadé než vše ostatní na trhu. Takové kroky nás nejen poškozují u zákazníků, ale také jak interně vytváříme produkty. Neubližují jen nám „komunitou OSS“, ale všem v Developer Division a Microsoftu.

Pokud v tom chceme být skutečně transparentní, měli bychom provést tyto změny, abychom to napravili:

Potřebujeme kompletní, veřejně zveřejněnou časovou osu toho, jak se to stalo, a osob přímo odpovědných za to, jak to vedlo k tomu.
Už nikdy bychom PR neměli uspěchat. Od začátku bylo jasné, že odstranění kódu byla špatná akce, a pokud skutečně chceme zpětnou vazbu od komunity, musíme být ochotni naslouchat ne poté, ale předtím.
Pokud tato rozhodnutí učinili jednostranně ti ve vedení, musíme zabránit tomu, aby se to už někdy opakovalo. Mezi „potřebami“ VS a dotnet byl zjevný střet zájmů. Musí existovat kontroly a rovnováhy, které zabrání jakékoli osobě, bez ohledu na to, jak vysoko se nachází, v rozhodování, jako je toto, bez skutečné zpětné vazby zevnitř i vně divize.

Naším cílem zde není urážet žádnou konkrétní osobu ve vedení, která mohla učinit toto rozhodnutí. Místo toho jde o vyřešení hlavního problému: Nikdo by neměl mít tolik síly, aby ovlivnil produkt, jako je dotnet, tak blízko k přímému vydání. Každý, kdo vede vývojářskou divizi, může dělat stejné akce, kterým musíme zabránit. Jasné pokyny k ochraně těchto produktů, které tvoří základ všeho, čím Visual Studio je, z nás nejen učiní ty nejlepší ve své třídě jako správci softwaru s otevřeným zdrojovým kódem, ale také nám pomůže vytvořit to nejlepší IDE, jaké můžeme.

Díky, Graeme, za tip.