Hace casi exactamente un año escribí un post sobre cómo .NET había pasado a ser open source y lo que eso significaba, al menos para mi. De momento no he dejado .NET por Java y, aunque reconozco que cada vez sigo más de cerca el mundo de la JVM y en los desarrollos nuevos que he realizado este año he huido al máximo de .NET, todavía sigue siendo mi plataforma principal de desarrollo por lo que trato de estar al tanto de su evolución.
En el año que ha pasado desde aquel post, y como pudimos ver en el evento Connect 2015 de hace unos días, el cambio de estrategia de Microsoft se ha consolidado: cada vez son más los proyectos open source que lidera, ha profundizado en el soporte multiplataforma y, en general, se podría decir que todo marcha bien. ¿O no?
OJO: Este es el típico post muy personal, en el que vierto opiniones con las que no tienes por qué estar de acuerdo, que posiblemente ni siquiera consideres bien fundadas y, por tanto, como siempre que escribo cosas así, estaré encantado de leer otros puntos de vista en los comentarios.
Para algunos el objetivo está cumplido. Hay quien me ha explicado que .NET es la mayor comunidad Open Source y me ha recordado que OpenSource no implica necesariamente la cooperación sino sólo el acceso al código libremente.
Puede ser. No voy a entrar a discutir el tamaño de la comunidad porque ni siquiera sé muy bien cómo se mide eso (¿quién es comunidad?), pero el problema es que otros esperábamos algo más.
O bueno, a lo mejor tampoco lo esperábamos, pero era lo que nos hubiera gustado. A otros nos hubiese gustado encontrarnos con un ecosistema lleno de alternativas, en el que proyectos de distintos orígenes pudieran coexistir y hubiese variedad. Esperábamos, seguramente sin motivo, un resurgimiento de lo que fue allá por el 2007 el movimiento ALT.NET.
En aquella época no hizo falta que Microsoft liderase nada, simplemente se juntó un grupo de gente muy buena que disfrutaba con C# y .NET y tenía ganas de dar un paso más. De traspasar ideas de otras comunidades, de probar cosas nuevas, de crear otras formas de trabajar, de exprimir sus herramientas. Fue una época de experimentación de la que salieron proyectos interesantes (y también en la que muchos proyectos se quedaron por el camino). Al no tener un agente dominador claro influenciando «lo que había que hacer», era relativamente fácil para un proyecto ganar tracción e interés (siempre dentro de los 4 gatos que éramos), y por tanto conseguir que sus ideas acabasen influyendo en otros proyectos.
La realidad que tenemos hoy en día es ésta:
En el top 10 de paquetes más descargados de Nuget, ocho son de Microsoft y otro ni siquiera podemos considerarlo un proyecto de .NET (jQuery).
¿Qué me hubiera gustado? Ver algo así:
Lo de menos son los proyectos concretos, pero hubiese querido ver librerías desarrolladas por distintos grupos, posiblemente con el apoyo de Microsoft en aquellos proyectos que considerase oportuno, pero lideradas por la comunidad, no por el fabricante. Esto no es algo tan extraño, y seguramente si hubiese existido Nuget en la época de ALT.NET las estadísticas habrían sido parecidas (de hecho lo eran en el extinto Hornget).
En otras plataformas la norma es la diversidad.
Daos una vuelta por Maven (Java), RubyGem (Ruby), npm (Javascript), Clojars (Clojure) o PyPi (Python), por citar unos cuantos, y veréis que no existe ese elefante en el ecosistema capaz de quedarse con todo.
Sin embargo, a veces es como si Microsoft volviese a aplicar su estrategia de los 90 de Embrace, extend and extinguish. Por supuesto, no creo que ese sea su objetivo porque es el primer interesado en que .NET tenga un futuro prometedor y sabe que eso pasa por conseguir un ecosistema atractivo y una comunidad fuerte, pero es como si su naturaleza de empresa dominante le llevase a tener que marcar la agenda de todo el mundo.
La sensación que tenemos algunos es que Microsoft necesita acaparar todo el ecosistema. Todas las librerías deben estar desarrolladas y controladas por ellos. Todas las herramientas deben ser suyas. En lugar de colaborar con Brackets o con Atom, necesita sacar su propio editor, Visual Studio Code.
Es lo que se transmite también en respuestas como ésta a peticiones de los creadores de Paket, un gestor de paquetes alternativo a Nuget, en la que a la vez que se dice que debería haber lugar para más de un gestor de paquetes, se dice que no deberían existir motivos para necesitar más gestores de paquetes.
Esto ha generado cierto revuelo en twitter, acabando con un «Haters gonna hate» por parte de David Fowler, arquitecto de ASP.NET 5, que, sinceramente, no me parece la forma más acertada de tratar con la «comunidad» que tiene que construir tu «ecosistema» de proyectos y librerías. Porque no olvidemos que los usuarios que más se quejan y más reclaman apertura y colaboración son precisamente los que más pueden aportar a tu ecosistema. De hecho, todos los tweets que he citado son de personas que desarrollan o han desarrollado proyectos bastante conocidos dentro del mundo .NET.
¿Es así en todas partes? No. Por poner un ejemplo reciente, con React, Facebook ha decidido descontinuar sus propias herramientas (react-tools) en favor de Babel y apoyar ese proyecto porque, sencillamente, es más avanzado y mejor. Pese a ser algo estratégico para ellos (es el «compilador» de su librería), en lugar de intentar controlarlo todo han decidido colaborar y apoyar un proyecto de la comunidad.
Pero claro, la situación de Facebook y Microsoft no es la misma. Para Facebook, React es sólo una librería. Para Microsoft, .NET es parte de su estrategia de negocio y la posición de Microsoft es complicada porque necesita recuperar el tiempo perdido y adecuar su plataforma y su imagen a los tiempo que corren.
Es una posición complicada porque, por una parte, tiene que ofrecer el mejor producto a unos usuarios que no están acostumbrados a analizar distintas alternativas, por lo que esa filosofía de «liderar todo el ecosistema» parece la única vía a seguir; y por otra, ese excesivo control refuerza el comportamiento «cómodo» de muchos usuarios, que aceptan sin cuestionarse nada las opciones que se ofrecen «por defecto» y eso acaba haciendo mucho daño a la diversidad de la plataforma, dejando una plataforma de código abierto, pero un ecosistema igual de cerrado que antes (o incluso más).
Tal vez la clave para entender lo que está pasando sea comprender el objetivo de Microsoft como empresa. El análisis de este artículo de The Register me parece acertado en ese sentido:
At dotnetConf, Program Manager Immo Landwerth described open source as the «most sustainable way to build a cross-platform stack.» The reason given for going cross-platform is to attract new customers to .NET and build a stronger ecosystem, such as third-party libraries and applications that run on .NET.
Another factor is that through .NET Core Microsoft hopes to stimulate use of its languages, including C# and F#, a functional programming language. If you code in these languages, Microsoft has a ton of libraries that will pull you towards SharePoint or Office 365, for example, so that the company can profit from licences or subscriptions there.
Convertir .NET en open source tiene como fin facilitar su adopción en múltiples plataformas a las que luego dar cabida en Azure y, en cierto modo, guiar a los usuarios hacia sus servicios de pago (Office 365, Sharepoint, etc.). Algo completamente lícito y razonable como modelo de negocio: no hay que olvidar que Microsoft es una empresa cuyo objetivo, como todas, es conseguir beneficios.
Hablando hace unas semanas con Jorge Gamba, ilustre .NETtero y fundador de altnethispano, me decía esto:
Como comentaba hace unos días, cuando uno piensa, por ejemplo, en Scala, lo conduce a un ecosistema muy rico con todos esos OSS Apache.
Hay cualquier cantidad de opciones para armar tu propia receta para sistemas distribuidos, así como en otros [lenguajes] (p.ej: Erlang/Elixir).
Es decir, no sólo es un lenguaje y una plataforma. En .NET si buscas esas cosas, todo es Azure, sé que hay cosas además, pero parece un ecosistema menos rico.
El año pasado cuando escribía sobre la noticia de un .NET open source decía:
Sin eso [innovación, proyectos locos y nuevas formas de trabajar], esto de tener una plataforma abierta no deja de ser un brindis al sol. Seguirá siendo una plataforma controlada por Microsoft, los usuarios seguirán utilizando únicamente las librerías que produzca Microsoft y, sí, todo será abierto, pero a efectos prácticos no habrá mucha diferencia.
Por desgracia, ahora mismo la situación que siento es esa, e incluso teniendo en cuenta que la migración a .NET Core no es trivial y eso va a hacer que muchos proyectos existentes se caigan, me atrevería a decir que es peor que la que había antes, al menos temporalmente.
Hay quien piensa que es posible que todo esto esto contribuya a resetear el ecosistema de proyectos Open Source en .NET y se convierta en algo positivo dentro de un par de años. Ójala.
Creo que esa sensación de que Microsoft acapara el desarrollo «open source» en .NET comparado con Java es un poco ficción. Realmente Java está bastante abandonado por parte de Oracle y es la comunidad Java quien se mueve para mantener el lenguaje en un nivel avanzado, mientras que en .NET nos encontramos con una empresa muy comprometida con el desarrollo de su plataforma.
Personalmente estoy bastante decepcionado con la lentitud del avance de .NET Core. A estas alturas ya no veo sostenibles los entornos de programación cerrados y que no son multiplataforma. Apostar por ellos es un suicidio profesional, el cambio a «open source» es ya imparable y se está imponiendo masivamente en el entorno empresarial.
El problema de ese top 10 es que no se distingue entre librerías y extensiones de dichas librerías. Instalarte algo como Asp.net mvc te instala un tropel de nugets satelite que aumentan su predominio. Eso y el hecho que las plantillas base Visual Studio te inyectan esas librerías en sangre.
Lo del top-ten … no te dice mucho, es como decir que el programa más usado en Windows es explorer.exe, «sa jodio» :D
En cuanto a la intención de Microsoft a acaparar todo, ni entro ni salgo, pero yo si noto algunas cosas que me gustan, por ejemplo que hayan desistido de seguir metiendo los bundles de MVC en favor Grunt y tal, aportando tooling para usarlos. Cada día te resulta más fácil integrar cualquier herramienta con Visual Studio
Creo que la tendencia es buena aunque como tu bien dices no sea lo que nos gustaría a muchos.
En cuanto a Alt.Net … diría que es la culpable directa de que Microsoft haya abierto los ojos. Aún recuerdo algunos tweets de gente de Microsoft diciendo que la inyección de dependencias no era necesaria … lo que no entiendo es por que coño se sacan de la manga Unity cuando ya hay containers para parar un tren. Igual con Visual Studio Code, vaya una cagada… pero bueno, ellos que desarrollen lo que quieran siempre y cuando te faciliten hacer tu las cosas como quieras, y creo que ir liberando código fuente de muchas cosas te hace el trabajo más sencillo.
Por último también considero un gran paso matar el puto System.Web y desatarse de IIS, adoptar Katana implementando Owin de forma que se abren las puertas para crear los midlewares que quieras. Está claro que tendrán que ir saliendo midlewares para todo y poder suplir todo lo que daba System.Web. El que la migración a .NET Core no sea trivial se basa en eso… Queríamos un .NET que corra en cualquier sitio, pues bien ya lo tenemos, lo que no podemos pretender es que ese .NET tenga todo lo que tiene el .NET Full y que corra en todos sitios … Ahora es momento de que la comunidad vaya creando librerías para hacer en cualquier máquina/sistema lo que antes se hacía con el .Net Full solo en Windows.
En definitiva, los cimientos ya están y la puerta ya está abierta … te atreves a pasar ya o esperas a que terminen los pintores? ;)
Mmm, más bien creo que es un tema de ritmo y de impaciencia.
Al menos en lo poco que conozco, si que se ve a Micro dejando a su lado su stack y adoptar la de otros. ¿Ejemplos?
Ndpm y bower en vez de nuget.
Docker, en vez de reinventar la rueda.
Implementar jQuery, knocout, etc. En vez de también reinventar la rueda.
No veo el problema en que MS lidere como nadie su propia plataforma. Creo más bien que aún no se ha terminado de superar por parte de la comunidad la sensación de que aportar para MS es algo contranatura, y por eso no salen proyectos a tutiplen.
Creo que la puerta está abierta, y ahora tiempo al tiempo.
Gracias a todos por los comentarios.
Javi, el top ten me parece significativo porque en este caso son paquetes que elige la gente. De hecho, me quedé en top ten en lugar de coger más porque por debajo aparecen paquetes «del framework» de esos que ahora se bajan por separado y que no te queda más remedio que usar, pero podrías elegir entre EF/NH o entre MVC/Nancy, y lo que parece claro es que todo son librerías de Microsoft.
Juan, es posible que el tiempo cambie todo (como digo al final de post, ójala), pero la realidad es que de hace 4 años para acá, muchos de los proyectos Open Source del mundo .NET que no eran desarrollados por Microsoft están parados, han perdido usuarios o, directamente, han desaparecido.
Los ejemplos que mencionas están bien, pero si te fijas ninguno se ejecuta sobre .NET. Cuando se trata de proyectos desarrollados en .NET, es más frecuente lo que dice Javi (sacar Unity en lugar de apoyar Windsor/StructureMap/AutoFac/NInject, EF en lugar de NH, MVC en lugar de MonoRail…).
Muy buenas,
estoy bastante de acuerdo con el articulo. Mi sensación es que de momento el Open Source es más un ayudarme a mi a hacer la plataforma que no un hago una plataforma para que florezca una verdadera comunidad.
Otro tema curioso es el hecho de engordar Visual Studio con una determinada selección de herramientas. Y si no quiero utilizar grunt? O bower?
En lo de Code también estoy de acuerdo, apoyando otros editores habrían hecho mucha más faena.
Creo que cierta parte de la comunidad de desarrolladores de Microsoft también tiene parte de culpa. Hace poco estube en un proyecto donde el «arquitecto» decidió utilizar MSTest por el simple hecho de estar integrado en VS y TFS. Sin ni tan siquiera evaluar otras opciones. Con esta mentalidad no se va a llegar muy lejos.
En definitiva, que también estoy a la espera y que, por supuesto, espero que esto acabe bien y tengamos un ecosistema rico donde poder escojer.
Hola,
Estaba buscando información sobre diversos temas y econtre tu blog, he estado leyendo tus posts y son espectaculares, a partir de ahora te has ganado un fan más.
Saludos
Muchas gracias, Adrian :-)
Por alusiones casi… jejejeje
A ver, no creo que sea una cuestión de mayor o menor riqueza sino de que los que trabajamos con .NET confiamos más en las extensiones que lanza Microsoft (por aquello del soporte, rendimiento y estabilidad) y, sobre todo, porque nos aportan lo que necesitamos. En mi caso, en lo que se refiere a extensiones/apis c# sólo descargo las propias de Microsoft en el 99% de los casos por esa confianza. Si nos vamos a extensiones JS ya es otro cantar, jQuery, Modernizr, Angular, … o mías propias son las que uso.
Tiene razón un comentario que he leído por aquí que indica que al instalarte alguna extensión te baja otros paquetes necesarios (igual que ocurre generalmente en otros entornos dependiendo de lo que quieras instalar) pero eso ya ha cambiado con ASP.NET 5 por ejemplo.
En resumen, que la gente pueda crear extensiones, pueda aportar sus propias versiones del core, etc… no implica que los demás nos lo tengamos que descargar cuando la confianza y las ventajas en lo que aporta el «vendor» es muy superior. Vamos, que si estuviera desarrollando en Java, intentaría buscar los paquetes oficiales primero.
Muchas gracias por explicar tu punto de vista, Santiago.
Sinceramente, creo que representas mucho mejor que yo a la base de usuarios de .NET, y creo que justo por eso la postura de Microsoft es la que es: es lo que sus usuarios demandan y su (loable) objetivo como empresa es proporcionárselo.
Por la exposición que has hecho, a ti que los paquetes sean Open Source o no te afecta poco, te importa más que estén soportados y avalados por Microsoft. Otros estamos más tranquilos con un paquete Open Source mantenido y soportado por la comunidad que no dependa del roadmap de una única empresa.
Hay ejemplos de sobra para argumentar en un sentido u otro. Hay paquetes abandonados por Microsoft (Linq2sql) y por la comunidad (Castle Monorail), y paquetes muy vivos de Microsoft (ASPNET MVC) y de la comunidad (NancyFX).
Al final, como tú muy bien dices, existe un componente de confianza que resulta fundamental, y dentro de la base de usuarios de .NET la tendencia es confiar en el «vendor», por lo que los paquetes de terceros quedan relegados a un segundo plano y el ecosistema acaba siendo más cerrado.
Pingback: 4 razones que cambiarán tu visión de Microsoft | el.abismo = de[null]