Desenvolvedor da Microsoft chama a gerência sobre como lidar com o problema do .Net Hot Reload

Membros da comunidade de código aberto recentemente ficaram furiosos com a Microsoft por aparentemente remover intencionalmente um recurso da plataforma de desenvolvimento de software de código aberto .Net 6 (que a Microsoft gerencia) para que desenvolvedores profissionais usassem o Visual Studio 2022, um software bastante caro, mas muito caro da Microsoft. IDE poderoso.

Acontece que os desenvolvedores da Microsoft ficaram igualmente irritados e Reversão da Microsoft de sua decisão não os aplacou, com muitos temendo a próxima ocasião em que a Microsoft colocaria seus interesses financeiros de curto prazo em seu envolvimento com a comunidade de código aberto.

Isso resultou no lançamento de uma carta anônima à administração da Microsoft em que o autor acusa diretamente a empresa de mentir para proteger a gestão.

Eles observam que a Microsoft intencionalmente tentou ocultar a remoção do Hot Reload apressando o PR antes que os desenvolvedores do .Net 6 pudessem comentar e que a desculpa da Microsoft de que eles não podiam se concentrar no Hot Reload para o .Net 6 e o ​​VS 2022 soou vazio quando não havia indicação de que o trabalho não pôde ser concluído satisfatoriamente para ambos.

Eles expressaram preocupação de que a Microsoft fará mais esforços para prejudicar o .Net 6 em um esforço para impulsionar o VS 2022, apesar das ferramentas de código aberto serem bastante populares dentro da própria Microsoft.

O autor pediu uma investigação transparente sobre como o Hot Reload foi puxado e mudanças no gerenciamento da Microsoft para que tais decisões precipitadas não pudessem ser tomadas novamente.

Apesar do tom um tanto estridente que fez com que muitos acreditassem que a nota não é real, vários MVPs da Microsoft se apresentaram e confirmaram que a carta foi de fato escrita por um funcionário da Microsoft na divisão DivDev.

Leia a carta na íntegra abaixo:

À Liderança da Divisão de Desenvolvedores da Microsoft,

Aqueles de nós que trabalham na Divisão de Desenvolvedores da Microsoft (DevDiv) gostariam de responder à recente controvérsia em torno da retirada e restabelecimento do recurso “dotnet watch” do dotnet 6. foi preservado, não nos sentimos confiantes de que isso não acontecerá novamente - muito pelo contrário.

Para mostrar esse ponto, examinaremos a postagem de blog recente de Scott Hunter (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Com base em tudo o que sabemos sobre a situação e como a Divisão de Desenvolvedores opera, pouco do que Scott escreveu parece verdadeiro e contradiz o que aconteceu. Para ser claro, este não é um ataque a Scott Hunter; e, em vez disso, mostra até onde os outros estão dispostos a ir para proteger a gestão.

“Como equipe, estamos comprometidos em que o .NET seja uma plataforma aberta e faça nosso desenvolvimento de forma aberta. O próprio fato de termos decidido adotar uma postura aberta por padrão desde o início para desenvolver o recurso Hot Reload é uma prova disso.”

Nada sobre o pull request estava aberto. Mencionamos isso em uma postagem no blog (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) e apressamos o PR para evitar comentários. Como podemos dizer que somos transparentes quando isso é tão claramente o oposto? É como se todos nós, coletivamente, soubéssemos que isso estava errado, mas tivéssemos que concordar com isso de qualquer maneira.

“A grande maioria dos desenvolvedores .NET está usando o Visual Studio e queremos garantir que o VS ofereça a melhor experiência para .NET 6.”

Mesmo que isso seja verdade, isso significa que não nos importamos com usuários que não são do Visual Studio? Como puxar esse recurso tão tarde no desenvolvimento faz com que o Visual Studio tenha a melhor experiência para Hot Reload? É um insulto para aqueles que nem sempre usam o Visual Studio para seu desenvolvimento dotnet, e diz que não entendemos nossos clientes ou mesmo funcionários que usam o que construímos.

Usamos CLI e usamos VS Code. Pare de fingir o contrário.

“Cometemos um erro na execução deste plano na forma como foi realizado. Em nosso esforço de escopo, acabamos inadvertidamente excluindo o código-fonte em vez de simplesmente não invocar esse caminho de código.”

Para ser claro, culpar o engenheiro por esse “erro” é covardia. O problema foi remover o recurso, não como eles o executaram. Estamos dizendo que se apenas "desligá-lo" em vez de removê-lo, não teríamos revertido a mudança? Este código teria sido ativamente trabalhado ou deixado para apodrecer?

“Com a pista ficando curta para o lançamento do .NET 6 e o ​​Visual Studio 2022, optamos por nos concentrar em trazer o Hot Reload para o VS2022 primeiro.”

Para mostrar que “Controle de Qualidade” não era o caso de “dotnet watch”, vamos compará-lo com outro produto que atrasamos: MAUI.

MAUI está em má forma. Ficou claro pelo RC1 que a qualidade não seria alta o suficiente quando o dotnet 6 fosse lançado; havia muito para consertar e não havia tempo suficiente para fazê-lo. A equipe MAUI e seus parceiros trouxeram essas questões para a liderança, o que levou o produto de volta ao início do próximo ano.

Não havia e ainda não há indicação de que “dotnet watch” estivesse no mesmo lugar. Passar pelos problemas do GitHub nem pelo backlog da equipe dotnet mostra qualquer preocupação de que a qualidade não estava lá. Pelo contrário, estava indo muito bem. Eles teriam sido apresentados muito mais cedo em nosso ciclo de lançamento se houvesse preocupações reais com a qualidade, não três semanas antes do envio.

“Como acontece com muitas empresas, estamos aprendendo a equilibrar as necessidades da comunidade OSS e a ser um patrocinador corporativo do .NET.”

Se lermos nas entrelinhas, esta afirmação é verdadeira. Entramos em conflito com o que colocamos no dotnet, Visual Studio e Visual Studio Code. Manter o Hot Reload como um “valor agregado” para o Visual Studio mantém aqueles bloqueados no produto pago e menos motivos para pular para o VS Code. De uma forma fria e calculada, isso faz todo o sentido, e também é um absurdo absoluto.

E se as equipes que trabalham no Hot Reload para Visual Studio integrassem o “dotnet watch” em seus produtos? E se a liderança retirasse esses recursos semanas antes do lançamento geral? Como isso melhoraria o Visual Studio de alguma forma? Vamos continuar removendo partes da CLI porque temos medo de perder receita do Visual Studio?

A maneira como construímos o melhor Visual Studio é tendo o melhor tempo de execução do planeta. Quando a equipe do Visual Studio adiciona recursos à base do dotnet, temos uma base consistente para todos trabalharem e contribuírem. Podemos construir o melhor IDE colaborando no tempo de execução, não piorando arbitrariamente nossos produtos de código aberto.

Qual é o próximo? Vamos fazer do Omnisharp um produto de código fechado? Para que possamos garantir que ele não consiga novos recursos que tirem o “valor” do Visual Studio? Para não entregarmos recursos ao Rider? Como isso nos ajuda? Essas decisões da liderança garantem que o Visual Studio sempre seja de segunda classe em relação a todo o resto do mercado. Movimentos como esses não apenas nos prejudicam com os clientes, mas também como construímos produtos internamente. Eles não nos prejudicam apenas com a “comunidade OSS”, mas com todos na Divisão de Desenvolvedores e na Microsoft.

Se quisermos ser genuinamente transparentes sobre isso, devemos fazer essas alterações para corrigir isso:

Precisamos de uma linha do tempo completa, publicada publicamente, de como isso aconteceu e os responsáveis ​​diretos por como isso levou a isso.
Nunca mais devemos apressar um PR. Ficou claro desde o início que remover o código era a ação errada e, se realmente queremos feedback da comunidade, temos que estar dispostos a ouvir não depois, mas antes.
Se essas decisões foram tomadas unilateralmente por aqueles que estão na liderança, precisamos impedir que isso aconteça novamente. Havia um aparente conflito de interesses entre as “necessidades” do VS e as do dotnet. É preciso haver freios e contrapesos para evitar que qualquer pessoa, não importa o quão alto esteja, de tomar decisões como essa sem feedback genuíno de dentro e de fora da divisão.

Nosso objetivo aqui não é insultar nenhuma pessoa específica na liderança que possa ter tomado essa decisão. Em vez disso, é para corrigir o problema principal: ninguém deveria ter tanto poder para impactar um produto como o dotnet tão perto de ser lançado diretamente. Qualquer um que lidere a Divisão de Desenvolvedores pode fazer as mesmas ações, que precisamos evitar. Ter diretrizes claras para proteger esses produtos que formam a base de tudo o que o Visual Studio é não apenas nos tornará os melhores da classe como administradores de software de código aberto, mas também nos ajudará a criar o melhor IDE possível.

Obrigado, Graeme pela dica.