Microsoftov razvojni programer poziva Upravu zbog rukovanja problemom .Net Hot Reload

Članovi zajednice otvorenog koda nedavno su bili bijesni na Microsoft jer je očito namjerno uklonio značajku iz platforme za razvoj softvera otvorenog koda .Net 6 (kojom Microsoft upravlja) kako bi profesionalni programeri umjesto toga koristili Visual Studio 2022, Microsoftov prilično skup, ali vrlo moćan IDE.

Ispostavilo se da su programeri unutar Microsofta bili jednako ljuti, i Microsoft poništio svoju odluku nije ih umirio, a mnogi se plaše sljedeće prilike u kojoj Microsoft stavi svoje kratkoročne financijske interese iznad njihovog angažmana u zajednici otvorenog koda.

To je rezultiralo oslobađanjem anonimno pismo upravi Microsofta u kojem autor izravno optužuje tvrtku da laže kako bi zaštitila menadžment.

Primjećuju da je Microsoft namjerno pokušao sakriti uklanjanje Hot Reloada tako što je požurivao s PR-om prije nego što su .Net 6 programeri mogli komentirati te da je Microsoftov izgovor da se ne mogu usredotočiti na Hot Reload za .Net 6 i VS 2022 bio prazan kad nije bilo indikacija da posao nije mogao biti dovršen na zadovoljavajući način za oboje.

Izrazili su zabrinutost da će Microsoft uložiti dodatne napore da osakati .Net 6 u nastojanju da progura VS 2022, unatoč tome što su alati otvorenog koda prilično popularni u samom Microsoftu.

Autor je zatražio transparentnu istragu o tome kako je Hot Reload povučen i promjene u Microsoftovoj upravi kako se takve ishitrene odluke više ne bi mogle donositi.

Unatoč pomalo oštrom tonu zbog kojeg su mnogi povjerovali da poruka nije stvarna, oglasili su se brojni Microsoftovi MVP-ovi i potvrdili da je pismo doista napisao Microsoftov zaposlenik u odjelu DivDev.

U nastavku pročitajte pismo u cijelosti:

Vodstvu Odjela za razvojne programere tvrtke Microsoft,

Oni od nas koji rade u Microsoftovom odjelu za razvojne programere (DevDiv) željeli bismo odgovoriti na nedavnu kontroverzu oko povlačenja i ponovnog uspostavljanja značajke "dotnet watch" za dotnet 6. Iako smo zahvalni što su hladne glave prevladale i "dotnet watch" sačuvan, nismo sigurni da se to neće ponoviti? upravo suprotno.

Da bismo to pokazali, pogledat ćemo nedavni post na blogu Scotta Huntera (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Na temelju svega što znamo o situaciji i načinu na koji Odjel za programere funkcionira, malo toga što je Scott napisao čini se istinitim i proturječi onome što se dogodilo. Da budemo jasni, ovo nije napad na Scotta Huntera; i umjesto toga, pokazuje koliko su daleko drugi spremni ići kako bi zaštitili menadžment.

“Kao tim, predani smo tome da .NET bude otvorena platforma i da svoj razvoj radimo na otvorenom. Sama činjenica da smo odlučili prihvatiti otvoreni stav prema zadanim postavkama od samog početka za razvoj značajke Hot Reload dokaz je tome.”

Ništa o zahtjevu za povlačenje nije bilo otvoreno. Spomenuli smo to u objavi na blogu (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) i neprozirno požurili PR da izbjegne komentari. Kako možemo reći da smo transparentni kada je ovo tako jasno suprotno? Kao da smo svi kolektivno znali da to nije u redu, ali smo se ipak morali složiti s tim.

"Velika većina .NET programera koristi Visual Studio i želimo biti sigurni da VS pruža najbolje iskustvo za .NET 6."

Čak i ako je to istina, znači li to da nam nije stalo do korisnika koji nisu Visual Studio? Kako bi povlačenje ove značajke tako kasno u razvoju omogućilo da Visual Studio ima najbolje iskustvo za Hot Reload? To je uvredljivo za one koji ne koriste uvijek Visual Studio za svoj dotnet razvoj, i kaže da ne razumijemo naše kupce pa čak ni zaposlenike koji koriste ono što mi napravimo.

Koristimo CLI i koristimo VS kod. Prestani se pretvarati da nije tako.

“Pogriješili smo u realizaciji ovog plana na način na koji je izveden. U našem nastojanju da odredimo opseg, nenamjerno smo završili brisanjem izvornog koda umjesto da jednostavno nismo pozvali taj put koda.”

Da budemo jasni, kriviti inženjera za ovu "pogrešku" je kukavički. Problem je bio uklanjanje značajke, a ne kako su to izveli. Hoćemo li reći da ne bismo vratili promjenu da smo je samo "isključili" umjesto da je uklonimo? Bi li se na ovom kodu aktivno radilo ili bi ga se ostavilo da trune?

"Budući da je pista sve manja za izdanje .NET 6 i Visual Studio 2022, odlučili smo se prvo usredotočiti na dovođenje Hot Reloada u VS2022."

Kako bismo pokazali da "Kontrola kvalitete" nije bio slučaj s "dotnet watchom", usporedit ćemo ga s drugim proizvodom koji smo odgodili: MAUI.

MAUI je u teškom stanju. RC1 je jasno da kvaliteta neće biti dovoljno visoka do trenutka isporuke dotneta 6; bilo je previše toga za popraviti, a premalo vremena za to. MAUI tim i njegovi partneri iznijeli su te probleme pred vodstvo, što je proizvod vratilo na početak sljedeće godine.

Nije bilo i još uvijek nema naznaka da je “dotnet watch” bio na istom mjestu. Pregledavanje problema s GitHubom niti zaostataka dotnet tima pokazuju zabrinutost da kvaliteta nije bila tu. Naprotiv, išlo je sasvim dobro. To bi se pojavilo mnogo ranije u našem ciklusu izdavanja da je bilo stvarnih problema s kvalitetom, a ne tri tjedna prije otpreme.

"Kao što je istina s mnogim tvrtkama, učimo balansirati potrebe OSS zajednice i biti korporativni sponzor za .NET."

Ako čitamo između redaka, ova tvrdnja je točna. U sukobu smo s onim što stavljamo u dotnet, Visual Studio i Visual Studio Code. Održavanje Hot Reload-a kao "dodatne vrijednosti" za Visual Studio drži one zaključane u plaćenom proizvodu i manje razloga za skok na VS Code. Na hladan i proračunat način, to ima potpunog smisla, ali je i apsolutna besmislica.

Što ako timovi koji rade na Hot Reloadu za Visual Studio integriraju "dotnet watch" u svoje proizvode? Što ako je vodstvo povuklo ove značajke tjednima prije općeg izdanja? Kako bi to poboljšalo Visual Studio na bilo koji način? Hoćemo li nastaviti uklanjati dijelove iz CLI-ja jer se bojimo da ćemo izgubiti prihod od Visual Studija?

Način na koji gradimo najbolji Visual Studio je najbolji runtime na planetu. Kada Visual Studio tim doda značajke temeljima dotneta, imamo dosljednu bazu na kojoj svi mogu raditi i doprinositi. Možemo izgraditi najbolji IDE surađujući u vremenu izvođenja, ne čineći proizvoljno naše proizvode otvorenog koda gorima.

Što je sljedeće? Hoćemo li Omnisharp učiniti proizvodom zatvorenog koda? Kako bismo bili sigurni da ne može dobiti nove značajke koje oduzimaju "vrijednost" Visual Studija? Da ne damo značajke Rideru? Kako nam to uopće pomaže? Ove odluke vodstva osiguravaju da će Visual Studio uvijek biti drugorazredan u odnosu na sve ostalo na tržištu. Ovakvi potezi ne samo da nam štete kupcima, već i tome kako interno gradimo proizvode. Ne nanose štetu samo nama s “OSS zajednicom”, već svima u Odjelu za razvojne programere i Microsoftu.

Ako želimo biti istinski transparentni u vezi s ovim, trebali bismo napraviti ove promjene kako bismo ovo ispravili:

Potreban nam je potpuni vremenski okvir, javno objavljen, o tome kako se to dogodilo i onima koji su izravno odgovorni kako je to dovelo do ovoga.
Nikada više ne bismo trebali žuriti s PR-om. Od početka je bilo jasno da je uklanjanje koda bila pogrešna radnja, a ako doista želimo povratne informacije od zajednice, moramo biti voljni slušati ne poslije nego prije.
Ako su te odluke jednostrano donijeli oni u vodstvu, moramo spriječiti da se to ikada više dogodi. Postojao je očiti sukob interesa između “potreba” VS-a i onih dotneta. Mora postojati kontrola i ravnoteža kako bi se spriječilo da bilo koja osoba, bez obzira na to koliko je visoka, donosi ovakve odluke bez istinske povratne informacije unutar i izvan odjela.

Naš cilj ovdje nije uvrijediti bilo koju osobu u vodstvu koja je možda donijela ovu odluku. Umjesto toga, to je rješavanje temeljnog problema: nitko ne bi trebao imati toliku moć da utječe na proizvod kao što je dotnet tako blizu izravnog izdavanja. Svatko tko vodi odjel za razvojne programere mogao bi činiti iste radnje, što moramo spriječiti. Posjedovanje jasnih smjernica za zaštitu ovih proizvoda koji čine temelj svega što Visual Studio jest ne samo da će nas učiniti najboljima u klasi kao upravitelja softvera otvorenog koda, već će nam također pomoći da izgradimo najbolji IDE koji možemo.

Hvala, Graeme na savjetu.