Microsoftin kehittäjä pyytää hallintaa .Net Hot Reload -ongelman käsittelystä

Avoimen lähdekoodin yhteisön jäsenet olivat äskettäin raivoissaan Microsoftille, koska se ilmeisesti tarkoituksellisesti poisti ominaisuuden avoimen lähdekoodin .Net 6 -ohjelmistokehitysalustasta (jota Microsoft hallinnoi), jotta ammattikehittäjät käyttäisivät sen sijaan Visual Studio 2022:ta, Microsoftin melko kallista mutta erittäin tehokas IDE.

Osoittautuu, että Microsoftin kehittäjät olivat yhtä vihaisia ​​ja Microsoft kumoaa päätöksensä ei ole tyynnyttänyt heitä, ja monet pelkäävät seuraavaa tilaisuutta, jossa Microsoft asettaa lyhyen aikavälin taloudelliset etunsa heidän sitoutumiseensa avoimen lähdekoodin yhteisöön.

Tämä on johtanut julkaisuun nimetön kirje Microsoftin johdolle jossa kirjoittaja syyttää suoraan yritystä valehtelusta suojellakseen johtoa.

He huomauttavat, että Microsoft yritti tarkoituksella piilottaa Hot Reloadin poistamisen kiirehtimällä PR:tä ennen kuin .Net 6 -kehittäjät ehtivät kommentoida, ja Microsoftin tekosyy, jonka mukaan he eivät voineet keskittyä Hot Reloadiin sekä .Net 6:lle että VS 2022:lle, oli tyhjä, kun sitä ei ollut. osoitus siitä, että työtä ei voitu suorittaa tyydyttävästi molempien osalta.

He ilmaisivat huolensa siitä, että Microsoft jatkaa ponnisteluja .Net 6:n lamauttamiseksi VS 2022:n työntämiseksi, vaikka avoimen lähdekoodin työkalut ovat varsin suosittuja Microsoftin sisällä.

Kirjoittaja pyysi läpinäkyvää tutkimusta siitä, kuinka Hot Reload vedettiin, ja muutoksia Microsoftin hallintoon, jotta tällaisia ​​hätiköityjä päätöksiä ei voitu tehdä uudelleen.

Huolimatta jokseenkin jyrkästä sävystä, joka on saanut monet uskomaan, että muistiinpano ei ole totta, useat Microsoftin MVP:t ovat tulleet paikalle ja vahvistaneet, että kirje oli todellakin Microsoftin DivDev-divisioonan työntekijän kirjoittama.

Lue kirje kokonaisuudessaan alta:

Microsoft Developer Division Leadership,

Ne meistä, jotka työskentelevät Microsoft Developer Divisionissa (DevDiv), haluaisivat vastata viimeaikaiseen kiistaan, joka liittyy dotnet 6:n "dotnet watch" -ominaisuuden poistamiseen ja palauttamiseen. Vaikka olemmekin kiitollisia, että viileämmät päät voittivat ja "dotnet watch" säilytettiin, emme ole varmoja siitä, ettei tämä toistu? päinvastoin.

Osoittaaksemme tämän tarkastelemme Scott Hunterin äskettäistä blogiviestiä (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Kaiken, mitä tiedämme tilanteesta ja siitä, miten kehittäjäosasto toimii, näyttää siltä, ​​​​että vain vähän Scottin kirjoittamasta on totta ja ristiriidassa tapahtuneen kanssa. Selvyyden vuoksi tämä ei ole hyökkäys Scott Hunteria vastaan; ja sen sijaan se osoittaa, kuinka pitkälle muut ovat valmiita menemään suojellakseen johtoa.

”Olemme tiiminä sitoutuneet siihen, että .NET on avoin alusta ja teemme kehitystyömme avoimesti. Jo se tosiasia, että päätimme omaksua oletuksena avoimen asennon Hot Reload -ominaisuuden kehittämisessä alusta alkaen, on osoitus siitä.

Mikään vetopyynnöstä ei ollut avoin. Mainitsimme sen blogiviestissä (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) ja ryntäsimme läpinäkymättömästi PR:tä välttämään kommentteja. Kuinka voimme sanoa, että olemme avoimia, kun tämä on niin selvästi päinvastoin? On kuin me kaikki yhdessä olisimme tienneet tämän olevan väärin, mutta meidän olisi kuitenkin edettävä sen kanssa.

"Suurin osa .NET-kehittäjistä käyttää Visual Studiota, ja haluamme varmistaa, että VS tarjoaa parhaan kokemuksen .NET 6:lle."

Vaikka tämä on totta, tarkoittaako tämä, että emme välitä muista kuin Visual Studion käyttäjistä? Miten tämän ominaisuuden poistaminen niin myöhäisessä kehitysvaiheessa tekisi siitä niin, että Visual Studiolla on paras kokemus Hot Reloadista? Se loukkaa niitä, jotka eivät aina käytä Visual Studiota dotnet-kehitykseensä, ja se sanoo, että emme ymmärrä asiakkaitamme tai edes työntekijöitämme, jotka käyttävät rakentamiamme tuotteita.

Käytämme CLI:tä ja VS-koodia. Lopeta muuta teeskentely.

"Teimme virheen toteuttaessamme tätä suunnitelmaa siinä tavassa, jolla se toteutettiin. Pyrimme saavuttamaan laajuuden, ja päädyimme vahingossa poistamaan lähdekoodia sen sijaan, että olisimme vain käyttäneet sitä koodipolkua."

Selvyyden vuoksi insinöörin syyttäminen tästä "virheestä" on pelkurimaista. Ongelmana oli ominaisuuden poistaminen, ei tapa, jolla se toteutettiin. Sanommeko, että jos se olisi vain "sammutettu" sen poistamisen sijaan, emme olisi palauttaneet muutosta? Olisiko tätä koodia työstetty aktiivisesti vai olisiko se jätetty mätänemään?

"Koska .NET 6 -julkaisun ja Visual Studio 2022:n kiitotie ei riitä, päätimme keskittyä Hot Reloadin tuomiseen ensin VS2022:een."

Osoittaaksemme, että "laadunvalvonta" ei ollut "dotnet-kellon" tapaus, vertaamme sitä toiseen tuotteeseen, jonka viivästyimme: MAUI.

MAUI on karkeassa kunnossa. RC1:llä oli selvää, että laatu ei ollut riittävän korkea dotnet 6:n toimitushetkellä; korjattavaa oli liikaa, eikä aika riittänyt sen tekemiseen. MAUI-tiimi ja sen kumppanit toivat nämä asiat johtajuuteen, mikä siirsi tuotteen takaisin ensi vuoden alkuun.

Ei ollut eikä edelleenkään ole viitteitä siitä, että "dotnet-kello" olisi ollut samassa paikassa. GitHub-ongelmien läpikäyminen tai dotnet-tiimin ruuhka osoittavat huolta siitä, että laatu ei ollut siellä. Päinvastoin, se sujui hyvin. Nämä olisivat tulleet esille paljon aikaisemmin julkaisujaksossamme, jos todellisia laatuongelmia olisi ollut, ei kolme viikkoa ennen toimitusta.

"Kuten monien yritysten kohdalla, opimme tasapainottamaan OSS-yhteisön tarpeita ja olemaan .NET:n yrityssponsori."

Jos luemme rivien välistä, tämä väite on totta. Olemme ristiriidassa dotnet-, Visual Studio- ja Visual Studio Code -koodien kanssa. Hot Reloadin pitäminen Visual Studion "lisäarvona" pitää käyttäjät lukittuina maksulliseen tuotteeseen ja vähemmän syytä siirtyä VS-koodiin. Kylmällä ja laskelmoidulla tavalla se on täysin järkevää, ja se on myös ehdotonta hölynpölyä.

Mitä jos Hot Reload for Visual Studion parissa työskentelevät tiimit integroisivat "dotnet-kellon" tuotteisiinsa? Entä jos johtajuus vetää nämä ominaisuudet viikkoja ennen yleistä julkaisua? Miten se parantaisi Visual Studiota millään tavalla? Aiommeko jatkaa osien poistamista CLI:stä, koska pelkäämme menettävämme tuloja Visual Studiosta?

Rakennamme parhaan Visual Studion käyttämällä planeetan paras käyttöaika. Kun Visual Studio -tiimi lisää ominaisuuksia dotnetin perustaan, meillä on yhtenäinen perusta, jonka parissa kaikki voivat työskennellä ja osallistua. Voimme rakentaa parhaan IDE:n tekemällä yhteistyötä ajon aikana, emmekä pahenna avoimen lähdekoodin tuotteitamme mielivaltaisesti.

Mitä seuraavaksi? Aiommeko tehdä Omnisharpista suljetun lähdekoodin tuotteen? Jotta voimme varmistaa, ettei se saa uusia ominaisuuksia, jotka vievät pois Visual Studion "arvon"? Jotta emme luovuta ominaisuuksia Riderille? Miten se ylipäätään auttaa meitä? Nämä johdon tekemät päätökset varmistavat, että Visual Studio on aina toissijaista kaikkeen muuhun markkinoilla. Tällaiset liikkeet eivät vain vahingoita meitä asiakkaiden kanssa, vaan myös sitä, kuinka rakennamme tuotteita sisäisesti. He eivät vain satuta meitä "OSS-yhteisön" kanssa, vaan kaikkia Developer Divisionin ja Microsoftin jäseniä.

Jos haluamme olla aidosti avoimia tästä, meidän tulee tehdä nämä muutokset tehdäksemme asian oikein:

Tarvitsemme täydellisen julkisesti julkaistun aikajanan siitä, miten tämä tapahtui ja jotka ovat suoraan vastuussa siitä, miten se johti tähän.
Meidän ei pitäisi koskaan enää kiirehtiä PR:n läpi. Alusta alkaen oli selvää, että koodin poistaminen oli väärä toimenpide, ja jos haluamme aidosti palautetta yhteisöltä, meidän on oltava valmiita kuuntelemaan, ei sen jälkeen, vaan ennen.
Jos johtohenkilöt tekivät nämä päätökset yksipuolisesti, meidän on estettävä sen toistuminen. VS:n ja dotnetin "tarpeiden" välillä oli ilmeinen eturistiriita. On oltava tarkastukset ja tasapainot, joilla estetään ketään, riippumatta siitä, kuinka korkealla he ovat, tekemästä tällaisia ​​päätöksiä ilman aitoa palautetta jaoston sisältä ja ulkopuolelta.

Tavoitteemme ei ole loukata ketään tiettyä henkilöä johtajuudessa, joka on saattanut tehdä tämän päätöksen. Sen sijaan se ratkaisee ydinongelman: kenelläkään ei pitäisi olla niin paljon valtaa vaikuttaa dotnetin kaltaiseen tuotteeseen niin lähellä, että se julkaistaan ​​suoraan. Kuka tahansa kehittäjäosastoa johtava voisi tehdä samat toimet, jotka meidän on estettävä. Selkeät ohjeet näiden tuotteiden suojaamiseksi, jotka muodostavat kaiken Visual Studion perustan, eivät ainoastaan ​​tee meistä luokkansa parhaita avoimen lähdekoodin ohjelmistojen valvojina, vaan myös auttavat meitä rakentamaan parhaan mahdollisen IDE:n.

Kiitos, Graeme vinkistä.