.NET es open source, ¿y ahora qué?

En el anterior post hablaba sobre el código que había demostrado su validez y mencionaba el caso el código de .NET liberado por Microsoft recientemente. En los comentarios, Sergio Leon me preguntaba algunas cosas:

Por cierto, sé que has estado trasteando con el código de .NET que han liberado. A grandes rasgos ¿Qué quieres sacar de ello? Lo digo porque seguro que son buenos motivos los que te empujan a ello, y yo sin embargo no encuentro casi ninguno, pero claro “algo me he perdido seguro” :) Es decir, ni tengo costumbre ni he “respirado” mucho open source, la verdad, y como dices tú, será la comunidad .NET la que tendrá que tirar del carro con el open source, pero realmente ¿Qué es tirar del carro en el contexto open-source? Yo no me veo haciendo un pull-request a .NET Core… ¿Qué hacer con ese código? ¿Curiosidad? ¿Aprender de él? Poco más se me ocurre en “mi contexto”.

Son preguntas interesantes, y creo que merece la pena responderlas en un post y que queden más accesibles que una respuesta a un comentario.

OJO: Esto es una opinión puramente personal. Ni pretendo predecir el futuro, ni imponer mi criterio, ni nada parecido, tan sólo exponer mi opinión, mis deseos y mis temores. Estaré encantado de leer otras opiniones en los comentarios.

Disponer del código fuente de .NET no es algo tan novedoso. Una cosa es que el proyecto fuese de código cerrado, y otra que el código no estuviera accesible, ya fuese a través del Reference Source, o incluso dicen las malas lenguas que se podía descompilar, aunque no es lo mismo (y además creo que es ilegal).

Lo bueno de esto es que tienes código preparado para ser liberado, leído por otros, modificado por otros y compilado por otros. Eso tiene su mérito y no debe de ser nada fácil. Liberar un código que lleva muchos años semi-encerrado bajo llave tiene que costar (y no quiero ni pensar lo bien que se lo habrán pasado los abogados de Microsoft con todo esto).

Leer ese código, al igual que el de otros proyectos de código abierto, aparte de satisfacer mi afición pornográfica, me ayuda a ver otros estilos de programación, otras formas de resolver problemas y, además, en este caso no deja de ser un código en el que me baso cada día para desarrollar aplicaciones, así que no está de más conocerlo.

Como dice Sergio, yo tampoco me veo haciendo un pull request, pero eso no quita que me guste cotillear.

Un aspecto que me interesa especialmente es el sistema de compilación. Puede sonar raro, pero tengo cierta obsesión por automatizar todo lo relacionado con la compilación y ver cómo otras personas resuelven esos problemas me parece interesante.

Sin embargo, si somos realistas, para la mayor parte de desarrolladores .NET, que no son esos del twitter y los blogs, sino los que están picando código como buenamente pueden en cárnicas y no quieren complicarse la vida, poder acceder al código de .NET no sirve para nada. Y estos van a seguir pesando mucho durante muchos años, porque precisamente trabajan por y para los mejores cliente de Microsoft.

¿Qué podemos sacar de todo esto, nosotros, los usuarios de .NET?

Bueno, aquí habría que poner las cosas en contexto, ya que no sólo estamos hablando de que el código de .NET (o mejor dicho, de una parte) sea abierto, sino que dentro del pack deberíamos incluir más cosas como el anunciado soporte para otros sistemas operativos (Linux y MacOS) y la modularización del runtime y el framework en paquetes NuGet.

Desde esa perspectiva, y pensando fundamentalmente en el aspecto «de negocio» se abren posibilidades interesantes.

Por una parte, poder desplegar en un futuro (espero que no muy lejano) aplicaciones .NET sobre Linux es un factor importante. Ahora mismo, y con todos mis respetos para Mono, desplegar una aplicación .NET en Linux no es algo trivial, y los costes de licencia de Windows siguen siendo un factor a tener en cuenta en determinados sectores (al menos en los que yo me muevo).

Por otro lado, me gustaría pensar que esto puede permitir que otras grandes empresas se involucren más en la evolución de .NET como plataforma y evitar estar tan atado a un único fabricante.

Tal vez algunos recordéis una empresa llamada Sun Microsystems que, allá por el 2006, decidió liberar el código de Java. De Sun Microsystems ya no queda gran cosa, sus restos los compró Oracle, pero independientemente de lo mucho o poco que a Oracle le interese Java, es innegable que Java goza de muy buena salud y existen empresas como Google o IBM que aportan mucho al mundo de Java.

Esto es lo que me gustaría, pero lo que me temo, y ojalá me equivoque, es que a corto plazo no vamos a ver nada de esto. Microsoft ha vivido mucho tiempo muy aislado y hoy en día no me imagino a Google (que todos vemos en qué parámetros se mueve últimamente) contribuyendo a mejorar .NET, pero insisto, ójala me equivoque.

También me gustaría ver unos usuarios de .NET desligados de Microsoft como empresa.

Cuando hace un año estuve danzando por algunas charlas sobre Java 8 y teniendo conversaciones sobre el tema, los usuarios se identificaban como usuarios de Java (del lenguaje o de la plataforma), pero nunca de Oracle (cosa comprensible, por otra parte).

Sin embargo, entre los usuarios de .NET, igual que entre los de Apple, existe una identificación con la empresa que hay detrás que, para mi gusto, es poco productiva y a veces los acerca peligrosamente a ser fanboys.

Tampoco veo a los alpha geeks (o hipsters, como queráis) que abandonaron .NET hace unos años volviendo a .NET por este anuncio. Seguirán usando su node.js, scala, erlang o lo que toque, pero creo que será difícil que vuelvan, y eso es una gran pérdida, porque este tipo de personas (pese a sus rarezas y manías) aportan innovación, montando proyectos locos que rompen paradigmas e introduciendo nuevas formas de trabajar.

Sin eso, 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.

No sé qué podría hacer Microsoft para evitar esta situación y, seamos realistas, tampoco sé si se va a producir o esto es sólo un desvarío mío. Seguro que ellos cuentan con gente mucho más lista que yo y con una visión de futuro mucho más clara, pero yo sinceramente creo que es más complicado de lo bonito que quieren verlo algunos.

Aprovechar estos pasos que está dando Microsoft requiere un esfuerzo conjunto de sus usuarios, y el grueso de los usuarios de Microsoft no están acostumbrados a estas cosas, y ni siquiera sé si les compensa hacerlo. No hay que olvidar que el mayor interesado en esto es Microsoft, no sus usuarios. Éstos, o al menos los más competentes (y por tanto interesantes para el futuro de .NET), pueden cambiar de tecnología y plataforma sin demasiados problemas.

Por mi parte, me alegra mucho ver estos cambios, me encanta ver que surgen proyectos como scriptcs y OmniSharp y me gusta ver cada vez más desarrollos en F#, pero la verdad es que ahora mismo siento que todo esto llega un poco tarde para mi.

Hace bastante tiempo que ya no dedico mi tiempo libre a jugar con .NET. Lo utilizo a diario en el trabajo, es una plataforma que me gusta, soy muy productivo con C#, pero cuando quiero divertirme, programo en Clojure o en Javascript. Y divertirse también es importante.

11 comentarios en “.NET es open source, ¿y ahora qué?

  1. Pues sí, muy buenas reflexiones.

    Es cierto que Microsoft ha liberado el código fuente (o parte de él), pero va a seguir controlando la evolución de la plataforma. Es decir, que .NET no va a ser un proyecto liderado por la comunidad. Si quieres hacer un pull request, Microsoft te lo revisará, y solo pasará a formar parte del código si es algo que ellos consideran que es bueno.

    Esta forma de llevar los proyectos Open Source es buena y mala a la vez. Buena porque te garantiza que .NET no va a quedar abandonado, y mala porque se pierde algo de libertad.

    De todas formas yo estoy con Juanma, y creo que los resultados de este movimiento son difíciles de pronosticar. Quizá esto abre la posibilidad de algún fork ingenioso, que haga cosas que los demás ni hemos pensado.

    Yo espero que Microsoft se vaya quitando la (merecida) mala fama, que se ganó en épocas más monopolísticas. Y esta es una buena forma de empezar.

    Y crucemos los dedos para que la comunidad de puntoneteros crezca y abra la mente.

  2. «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 »
    Yo creo que si va a haber diferencia.
    Aunque solo sea porque Microsoft lo promueve y sus ovejitas lo siguen, esta vez lo que esta promoviendo es el open source.
    Ademas a la que sales al mundo exterior y ves todo lo que hay por ahí, creo que no hay vuelta atrás.
    No va a ser inmediato, pero creo que se va a notar, incluso diría que ya lleva unos años notándose un poquito.

    Buen post Juanma, como siempre :)

  3. Sergio León dijo:

    Juanma, lo primero agradecerte que hayas invertido un tiempo valioso en contestar de esta forma a una pregunta tan inocente. A veces describir «qué es comunidad» es difícil, puede llegar a ser un concepto ambiguo, pero a cualquiera que no lo tenga claro, le invitaría a que leyese este post y asunto resuelto :)

    En la línea de intentar aportar algo (si es que algo no está ya dicho en tu post y en los comentarios), ahí van mis reflexiones:

    Es cierto que ver el código de terceros ya no es ningún reto, hay herramientas disponibles (la mayoría gratuitas) que te permiten hacerlo (dotPeek, ILSpy, JustDecompiler, etc) pero creo que la diferencia entre descompilar de forma casi «furtiva» y verlo de forma transparente es muy notable, ahora ya no sentiremos una especie de culpa por estar viéndole las tripas a .NET y, quien sabe, quizás veas algo que puedes mejorar…

    Además, liberar el código también supone una exposición que hasta hace bien poco (ya empezó con EF, MVC, WebAPI, etc.) era impensable en Microsoft. Ahora cualquiera podrá criticar, alabar o estudiar tranquilamente ese código, ahora las puertas están abiertas, y bueno, casos como el de Unai contribuyendo a EF te hacen pensar que hacer un pull request es jodido, pero no imposible!

    Yo lo que veo mas complicado es que los usuarios de .NET (en su amplia mayoría y según mi percepción) no es que sean/seamos MS fanboys, es que es muy difícil irte de casa con 40 años, es decir, hemos vivido siempre a las faldas de MS, sin ver mucho mundo, calentitos y bien alimentados, y ahora de repente todas las señales te dicen que no seas corto de miras, que amplíes tus horizontes … pues eso, que llevará su tiempo, no es MS una empresa que naciera con esta premisa en mente.

    Un saludo!

  4. Algo que espero que aporte esta disponibilidad del codigo fuente es mas agilidad por parte de Msft a la hora de sacar HotFixes y mejoras para el código q sea open source. El motivo es que yo si espero que ahora sea mas común que los desarrolladores enviemos reportes de bugs o mejoras que indican exactamente donde esta el problema y una posible solución o como implementar una mejora. En general cuanto mas concreto es el reporte de un bug a terceros mas rápido el tercero lo soluciona. Acelerándose especialmente si el reporte va con una propuesta de solución. Que el código sea open source fomenta que esto se de mas a menudo.
    Si MSFT sabe manejar este aumento de la calidad del feedback que yo espero todos vamos a beneficiarnos de una plataforma evolucionara mucho mas rápido que hasta ahora.

  5. En mi caso hace algún tiempo que abandoné el lado en el servidor con .NET, más que nada porque no me salía rentable ni a nivel de productividad ni a nivel económico. No obstante, en mi día a día me causa más alegría el camino a ser multiplataforma que a open source, puede que algún día vuelva :)

    Por otra parte, aunque sea una empresa relativamente pequeña, Xamarin ha demostrado que está ahí. Y si la gente de Mono se suma al cambio (que lo hará), creo que hay suficiente gente como para tirar del carro, aunque sea a empujones pequeños.

    Como siempre, buen post Juanma ;)

  6. Gracias a todos por los comentarios. Siempre mejoran los posts, pero en estos posts de opinión y especulación son especialmente valiosos.

    Alfredo, es cierto que en los últimos años ya se va viendo otra filosofía en el mundo de desarrollo .NET con respecto a productos open source, pero para mi el mejor momento se vivió a finales en el 2008, con el surgimiento de ALT.NET y un montón de gente muy buena replanteándose las cosas. Desgraciadamente, muchas de aquellas personas ya han abandonado .NET.

    Sergio (León) lo del pull request no lo decía tanto por la dificultad técnica sino por la falta de motivación (en mi caso). Y Sergio (Navarro), tampoco crea que sea fácil (¿ni bueno?) empezar a aceptar contribuciones de la comunidad si quieren garantizar la compatibilidad hacia atrás y la estabilidad y no acabar como el ecosistema de node, que a veces es una locura. Para reportar bugs ya había medios (por ejemplo, connect) y no sé si liberar el código supone realmente un game changer en ese sentido.

    Juan M., coincido contigo en que, para mi, tiene más valor ahora mismo el anuncio del soporte multiplaforma que la liberación del código. A nivel de negocio me ofrece posibilidades muy interesantes.

  7. Un par de precisiones, mas allá del contenido:

    Lo que se ha liberado no es .NET , es .NET Core, y este no lleva años hecho como dices en la frase «Eso tiene su mérito y no debe de ser nada fácil. Liberar un código que lleva muchos años semi-encerrado » Es código «nuevo», y lo principal no era lo viejo o la calidad, la mayoria eran problemas de patentes. Por el resto, poco que mas que decir, para no variarr :-)

    Unai

  8. Por cierto, a lo que comenta Sergio, lo que va a mejorar los hotfix o las entregas es el hecho de que .NET Core es «autocontenido» y no el que sea Open Source.

    Unai

  9. Gracias por la puntualización, Unai.

    La verdad es que me preguntaba si era código escrito «desde cero» o habían preparado el código que ya existía. Pensé que era el código original porque leyendo partes del código daba la impresión de ser bastante añejo por el estilo de programación.

    Sobre las patentes, tiene que ser un tema sumamente complicado de orquestar, y de hecho ya he leído algunas quejas al respecto: http://www.plingzine.com/?p=686

  10. Mi experiencia personal con Msft connect es bastante mala. Que un bug en xaml q no solo yo reporte sino q tb un MVP de renombre lo reportara y pasaran meses hasta obtener alguna respuesta y q la respuesta para nada fuera solución a nada me dejo desencantado con esa vía.
    Unai como dices cambiar esto sólo es posible si tienes software modulado y autocontenido para poder hacer entregas en ciclos mas cortos. Aun así yo no desdeñaría la capacidad para marcar la diferencia de un feedback de calidad de una comunidad motivada e implicada. Que a dia de hoy no es el caso de la comunidad .Net pero ofrecer el código en Open Source es un primer paso, el segundo seria q Msft de muestras de estar con el oído abierto al feedback. Ojo no he dicho q acepten pull requests pero si q estén abiertos a una discusión en la que el código que implementa sus APIs no es tabú.Tampoco he dicho q sea fácil, cualquiera q haya participado en proyectos open source donde hay una gran comunidad implicada sabe que no es nada fácil gestionar tantas voluntades. Aun así es posible y es un reto q MSFT yo creo haría bien en tratar de afrontar. Hacer .NET Core open source y no aumentar disposición a escuchar yo lo veo mas postureo tonto que otra cosa. Digo tonto pq han dado el paso mas difícil para acabar deshechando lo mas valioso del open source.
    Pero claro yo hablo de lo que yo querría, lo que hagan Nadela lo sabrá :)

  11. En relación con esto no se si será casualidad o por saber que estan disponibles los fuentes. Pero me estaba planteando esta semana trastear con los fuentes de .Net para tratar de entender pq un mismo código que utiliza llamadas asincronas y accesos a discos en winphone 8 puede estar yendo mucho mas rápido que en un pc en una App WinRT y de llegar a alguna conclusión reportarlo.

Comentarios cerrados.