Hace poco me entretenía con la enésima discusión en twitter sobre las maravillas y desastres de node.js y acabó saliendo un tema que hacía tiempo que no veía: el uso de librerías y plataformas de código abierto.
Sobre esto del código abierto hay posiciones muy extremas, tanto en un sentido como en otro (me atrevería a decir que hay mayor extremismo entre los defensores del código abierto), pero dejando a un lado fanatismos, creo que es posible realizar un análisis más pragmático del asunto.
OJO: no voy a entrar en discusiones ético-filosóficas sobre las bondades de uno u otro sistema. Tampoco voy a meterme en las diferencias entre código abierto, software libre y software gratis, porque aunque creo que son importantes, prefiero mantener un enfoque más «práctico» en este post.
Un mundo guiado por un único fabricante
Los que trabajamos con plataformas de Microsoft hemos estado muy acostumbrados a utilizar únicamente lo que nos proporcionaba Microsoft que, por otra parte, no era poco y cubría bastante bien la mayoría de situaciones a las que nos teníamos que enfrentar.
Si necesitabas hacer una aplicación web, tirabas de WebForms (o ahora de ASP.NET MVC). Si querías un ORM, Entity Framework. Para bases de datos, SQL Server, y si tenía que ser embebida, SQL CE. Esa era la forma de hacer las cosas y mucha gente no se la cuestionaba.
Recuerdo que hace unos 6 años empecé a introducir en mi trabajo del mundo real librerías «no Microsoft». Primero log4net, luego Castle Windsor, después NHibernate, …
Al principio tuve que vencer cierta reticencia entre algunos compañeros de trabajo, pero el tiempo me ha dado la razón y hoy en día usamos muchas librerías «de terceros», la mayoría de ellas open source, y debo decir que han mejorado considerablemente nuestros procesos de desarrollo (tanto a nivel de productividad como a nivel de calidad).
Aún hoy hay empresas en que plantear usar tecnologías no Microsoft dentro de un proyecto .NET se considera una mala idea y existen directores técnicos que directamente vetan el uso de estas tecnologías.
Es como el viejo dicho de «nunca despidieron a nadie por comprar IBM«, parece que si te ciñes al uso de tecnologías soportadas por Microsoft, nada puede salir mal, o al menos si sale mal, la culpa no será de tu elección tecnológica.
Sin embargo, gracias a la exposición constante que tenemos los desarrolladores a otras comunidades y a la mezcla de ideas procedentes de otros lenguajes, ya no es tan raro emplear herramientas de código abierto en proyectos de .NET.
De hecho, en los últimos años la propia Microsoft ha abrazado ese concepto con herramientas con Nuget y las últimas librerías desarrolladas por Microsoft están siguiendo este modelo de desarrollo (ahí tenemos Entity Framework aceptando pull requests de desarrolladores externos como Unai).
Una cuestión de confianza
En realidad, el problema que tiene mucha gente con el software de código abierto no tiene nada que ver con que el código sea abierto o cerrado o con que la licencia y el modelo de desarrollo sea más o menos libre, sino con quién está detrás del código.
Existe una sensación demasiado habitual de que un proyecto de código abierto que no está dirigido por una organización comercial es algo en lo que no se puede confiar, pero el tiempo nos ha enseñado que esto no es cierto.
Hay proyectos realizados por voluntarios que llevan mucho tiempo funcionando bien y tienen bases de usuarios tan grandes que los convierten en soluciones mucho más sólidas que sus equivalentes comerciales. Los más extendidos han conseguido además el apoyo de grandes empresas, lo que les da ese plus de confianza que parece necesario para usarlos en ciertos entornos (estoy pensando en casos como jQuery).
Al final, lo más importante para que una librería o plataforma tenga un buen soporte es que cuente con un número suficiente de usuarios. Si una tecnología alcanza el suficiente grado de adopción, siempre será más fácil encontrar alguien dispuesto a soportarla, ya sea de manera altruista respondiendo preguntas en Stack Overflow o de forma comercial cobrando por servicios de consultoría.
En ese sentido, a la hora de decidir si una librería determinada o una plataforma concreta son confiables, me parece más importante tener en cuenta la base de usuarios que quién está detrás de ella. De hecho, hay ocasiones en que tener una empresa detrás puede llegar a ser contraproducente porque puede que mantener esa tecnología viva vaya en contra de los objetivos económico/estratégicos de la empresa (preguntádselo a los que decidieron usar Linq2SQL para ver cómo en poco tiempo era descontinuado y reemplazado por Entity Framework).
También es cierto que existen empresas capaces de garantizar la supervivencia de un producto y el soporte del mismo durante un tiempo prefijado. Ahí están casos como Canonical (una empresa tan «comercial» como Microsoft) y sus releases de Ubuntu con soporte extendido o los ciclos de vida que ofrece Microsoft para productos como SQL Server.
Conclusiones
Este post no pretende ser un alegato a favor del movimiento Open Source y en contra de Microsoft. Nada más lejos de mi intención. Como he dicho al principio, creo que hay demasiado fanatismo en ambos bandos y se tiende a perder de vista el objetivo real: generar valor desarrollando software.
A la hora de elegir sobre qué plataforma desarrollar o qué librería utilizar hay muchos factores a tener en cuenta y, sin duda, el soporte que podamos obtener es uno de ellos, pero también lo es la facilidad para desarrollar sobre ella, el rendimiento que podamos conseguir y la disponibilidad de buenos desarrolladores.
Los típicos argumentos de «código cerrado malo porque no lo puedo tocar», «código abierto malo porque nadie me lo va a mantener» suelen caerse por su propio peso. Todos conocemos ejemplos de productos comerciales que han sido descontinuados dejando de dar soporte a sus usuarios, y todos usamos un montón de código abierto que no sabríamos tocar ni en un millón de años.
Lo que cuenta es resolver un problema y buscar las mejores herramientas para ello, que a veces serán open source y a veces no. No dejes que eso sea lo único que te guíe a la hora de elegir las herramientas más adecuadas para tu próximo proyecto. El código (abierto o cerrado) importa, pero el contexto más.
Muy bien, como de costumbre, sintético. Creo que hay otro aspecto positivo en el movimiento de MS de ciertos elementos al mundo OSS como MVC / EF / Katana etc y es que su ciclo de vida ya no está ligado al framework y eso ha sido un beneficio muy importante para nosotros, los desarrolladores de esta plataforma.
Unai
Es cierto, haber desacoplado las librerías del framework ha permitido que evolucionen de forma mucho más ágil.
De todas formas, me da la impresión de que para algunos resulta un poco más «incómodo». Antes instalabas el Visual Studio y con eso contabas. Ahora toca pensar qué versión quieres de qué librería, e incluso justificarlo delante de jefes de proyecto.
Por suerte creo NuGet ayuda mucho a gestionar todo eso (y eso que no lo uso :-)).
Microsoft hoy en día es totalmente abierto e incluso internamente promovemos fuertemente el soporte para otras herramientas y publicar mucho código en forma de open source.
Inclusive la mayoria, por no decir todas, las funcionalidades de azure para developers estan expuestas como Open Source GitHub.
Un buen desarrollador debe saber que es lo mejor para su proyecto y las tecnologias open source suelen ser una buena herramienta.
Sin embargo algo que pocos saben es que algunos directores de proyecto y arquitectops de software desconfian del open source por una razón muy válida: los terminos de licencia de gran parte de los componentes bajo licencias de open source (no los de ms) exigen que el software creado sea convertido en open source tambien y en otras ocasiones inclusive reclaman la propiedad de los productos derivados en caso de no ser entregados de manera gratuita.
Un tema muy crítico y en verdad como developers raras veces estamos atentos a ese tipo de cosas, por ello muchos ‘vieja guardia’ , mejor letrados en estos temas on reaceos a usar muchos de estos componentes, otros desde luego son reaceos solo porque se resisten al cambio.
Estoy completamente de acuerdo en que Microsoft está siguiendo un proceso de apertura muy beneficioso para todos, y de hecho lo menciono en el post original.
En lo que no estoy tan de acuerdo es en el comentario con respecto a las licencias. Es un argumento que podía tener sentido hace unos cuantos años, cuando los proyectos con licencias GPL y otras variantes virales dominaban el panorama open source.
Hoy en día la gran mayoría de proyectos tienen licencias bastante más permisivas (MIT, Apache o similar). De hecho, esto ha permitido que la propia Microsoft integre librerías open source como jQuery, Knockout, Bootstrap, etc., en sus productos comerciales sin ningún problema.
El tema de las licencias y lo que se puede hacer con cada cosa es algo que suele resultar confuso. Hace tiempo escribí un post sobre ello (https://blog.koalite.com/2013/07/licencias-de-software-cuando-puedo-usar-que/), pero no soy abogado así que seguramente hay inexactitudes.
De todas formas, rechazar el uso de librería open source «por si acaso la licencia me impide comercializarla», es como rechazar el uso de una librería de pago «por si acaso es muy cara». Averigua primero qué te permite la licencia o si la puedes pagar, y luego decide si te compensa o no usarla.