Por que as bibliotecas da Microsoft dependem do Newtonsoft.Json?

Provavelmente, isso começou quando a Microsoft criou a biblioteca da API da Web do ASP.NET, pelo menos é quando eu lembro se não me engano. De qualquer forma, desde então, seus pacotes HTTP começaram a depender da biblioteca Newtonsoft.Json para serialização (des) de dados de e para JSON.

Por que uma empresa tão grande quanto a Microsoft adicionaria uma dependência a uma biblioteca de código aberto? Acho estranho, mesmo que eles fossem totalmente de código aberto com o .NET naquela época, porque, até onde eu sei, foi a única biblioteca que não é da Microsoft usada como dependência.

Como uma questão bônus, James Newton-King recebe algum apoio financeiro da Microsoft?

— paulius_l
fonte

Você faz parecer que a Microsoft tem muito dinheiro para gastar. Embora sejam bastante ricos, seus recursos não são ilimitados, o que torna o cálculo igual ao seu: "por que devo gastar tempo e dinheiro para escrever algo para o qual já exista uma alternativa de código aberto perfeitamente boa?"

— Robert Harvey

A Microsoft começou a se tornar mais amiga do código aberto anos atrás; eles empacotaram o jQuery no ASP.NET MVC desde o início. Ir de código aberto com o .NET faz parte dessa mudança.

— Robert Harvey

Você pode descobrir um pouco mais sobre a história do JSON.NET aqui: newtonsoft.com/json/help/html/Introduction.htm

— Robert Harvey

Por que não? É uma biblioteca serializada JSON de classe mundial, suponho que a MS tenha sabiamente decidido concentrar suas energias em outros problemas e não reinventar a roda.

— Fergal Moran

Curiosamente, James Newton-King anunciou em março de 2018 que se juntaria à Microsoft.

— Jeroen #

A citação mais direta que encontrei faz parte do anúncio de Scott Guthrie do roteiro do MVC 4, em 2012 (aparentemente offline, mas disponível na Wayback Machine ), que contém a seguinte citação:

Json.NET : Planejamos usar a pilha de serialização Json.NET desenvolvida pela comunidade em nosso formatador JSON padrão na API da Web do ASP.NET. O Json.NET fornece a flexibilidade e o desempenho necessários para uma estrutura da web moderna.

Portanto, o motivo mais simples é que é a melhor biblioteca JSON disponível, enquanto o MVC foi um dos primeiros grandes projetos da Microsoft a abandonar a atitude NIH que caracterizava a MS, assim como outros gigantes de software, e alcançar os melhores projetos de código-fonte aberto como fundações para suas próprias ofertas.

— Avner Shahar-Kashtan
fonte

Tudo justo, e certamente não queremos voltar ao "NIH". Mesmo assim, eu gostaria que essa biblioteca ainda fosse incluída na pilha do MS. O motivo é que existe uma enorme pressão para que as bibliotecas externas não tenham dependências de estrutura externas e não essenciais. Essa é a única biblioteca que encontramos com frequência, onde é algo difícil de fazer, e não é de admirar que seja uma funcionalidade tão fácil, é como pensar no .NET sem ferramentas XML nativas (XElement etc.). Não é de admirar que esta seja a biblioteca nº 1 em todos os nuget (!). Meus 2 centavos.

— Nicholas Petersen

@NicholasPetersen Você pode ler aqui sobre uma proposta para incluí-la no .NET Standard. A última vez que verifiquei a discussão, a maioria era contra, mas talvez por incluir um subconjunto, um analisador JSON mais leve nas bibliotecas padrão.

— Avner Shahar-Kashtan

Eles fazem bons pontos, mesmo que eu não estivesse pensando que deveria ser adicionado como parte do .NET Standard, como alguns mencionaram, pois parece muito pesado para cimentar o padrão da rede o tempo todo. Meu pensamento foi incluí-lo como parte do netcore (suponho no corefx), mas admito que poderia ser ingênuo no que estou solicitando aqui. Algumas pessoas sugeriram que isso faz parte da NET Foundation, parece bom, mas não sei se isso aliviaria o problema do mundo real de permitir que outras bibliotecas não precisassem fazer referência a uma biblioteca externa à estrutura.

— Nicholas Petersen