¿Por qué las bibliotecas de Microsoft dependen de Newtonsoft.Json?

Esto probablemente comenzó cuando Microsoft creó la biblioteca de API web ASP.NET, al menos es cuando lo recuerdo si no me equivoco. De todos modos, desde entonces, sus paquetes HTTP comenzaron dependiendo de la biblioteca Newtonsoft.Json para la (des) serialización de datos hacia y desde JSON.

¿Por qué una compañía tan grande como Microsoft agregaría una dependencia en una biblioteca de código abierto? Me parece extraño incluso si iban a ser de código abierto con .NET en ese entonces porque, hasta donde yo sé, ha sido la única biblioteca que no es de Microsoft utilizada como dependencia.

Como pregunta adicional, ¿James Newton-King recibe algún apoyo financiero de Microsoft?

— paulius_l
fuente

Haces que parezca que Microsoft tiene bolsas de dinero para tirar. Si bien son bastante ricos, sus recursos no son ilimitados, lo que hace que su cálculo sea el mismo que el suyo: "¿por qué debería gastar tiempo y dinero para escribir algo para lo cual ya existe una alternativa de código abierto perfectamente buena?"

— Robert Harvey

Microsoft comenzó a ser más amigable con el código abierto hace años; agruparon jQuery en ASP.NET MVC desde el principio. Ir a código abierto con .NET es parte de ese cambio.

— Robert Harvey

Puede encontrar un poco más sobre la historia de JSON.NET aquí: newtonsoft.com/json/help/html/Introduction.htm

— Robert Harvey

Por qué no? Es una biblioteca de serialización JSON de clase mundial, supongo que MS sabiamente decidió enfocar sus energías en otros problemas y no reinventar la rueda.

— Fergal Moran

Curiosamente, James Newton-King anunció en marzo de 2018 que se uniría a Microsoft.

— Jeroen

La cita más directa que he encontrado es parte del anuncio de Scott Guthrie de la hoja de ruta MVC 4, en 2012, (aparentemente fuera de línea pero disponible a través de Wayback Machine ) que contiene la siguiente cita:

Json.NET : planeamos utilizar la pila de serialización Json.NET desarrollada por la comunidad en nuestro formateador JSON predeterminado en la API web ASP.NET. Json.NET proporciona la flexibilidad y el rendimiento necesarios para un marco web moderno.

Entonces, la razón simple es que es la mejor biblioteca JSON disponible, mientras que MVC fue uno de los primeros grandes proyectos de Microsoft en deshacerse de la actitud arraigada de los NIH que caracterizó tanto a MS como a otros gigantes del software, y llegar a los mejores proyectos de código abierto como fundamentos para sus propias ofrendas.

— Avner Shahar-Kashtan
fuente

Todo justo, y ciertamente no queremos volver a "NIH". Aun así, desearía que esta biblioteca aún se incluyera en la pila de MS. La razón es que existe una gran presión para que las bibliotecas externas no tengan dependencias externas de marco no centrales. Esta es la única biblioteca que se encuentra con frecuencia donde es algo difícil de hacer, y no es de extrañar, esta es la funcionalidad general, es como pensar en .NET sin herramientas XML nativas (XElement, etc.). No es de extrañar que esta sea la biblioteca # 1 en todo nuget (!). Mis 2 centavos

— Nicholas Petersen

@NicholasPetersen Puede leer aquí sobre una propuesta para incluirla en .NET Standard. La última vez que revisé la discusión, la mayoría estaba en contra, pero tal vez por incluir un subconjunto, un analizador JSON más ligero en las bibliotecas estándar.

— Avner Shahar-Kashtan

Hacen buenos puntos, a pesar de que no estaba pensando que debería agregarse como parte de .NET Standard, como algunos mencionaron, ya que parece demasiado pesado para consolidarlo en netstandard para todos los tiempos. Mi pensamiento fue incluirlo como parte de netcore (supongo que en corefx), pero admito que podría ser ingenuo en lo que estoy solicitando aquí. Algunas personas sugirieron que sea parte de la Fundación NET, suena bien, pero no sé si eso aliviará el problema del mundo real de permitir que otras bibliotecas no tengan que hacer referencia a una biblioteca externa al marco.

— Nicholas Petersen