¿Porqué comenzar desde cero no siempre es la respuesta?

Jun 16, 2014

Cada vez que pensamos en la construcción de un proyecto de software se lo relaciona con dos salidas viables, construir o comprar.  Dependiendo del tamaño de la empresa, las experiencias anteriores, nivel de inversión y recursos disponibles determinarán qué opción escoger.

Si tomamos el camino de la compra nos toparemos con las limitaciones que nos impone el proveedor de la herramienta de software, los costos asociados a las modificaciones o adaptaciones para poder cubrir nuestras necesidades.  Otro elemento con el que tendremos que lidiar en este caso es la dependencia con respecto al proveedor o "Vendor Lock-In", que nos mantiene atados al proveedor de la solución y dependemos de su respuesta para poder avanzar en el proyecto. Muchas empresas dan mucha importancia a estos puntos, por lo cual no siempre escogen la opción de comprar y prefieren realizar desarrollos desde cero, en donde se represente desde el principio las necesidades del proyecto, se establecen las condiciones y las limitaciones y además se convierten en dueños de la solución final. Al escoger la segunda opción tendremos que enfrentar a un viejo y temido conocido de los proyectos de software, el tiempo de entrega.  A esto le podemos sumar las pruebas, las evaluaciones de compatibilidad, las revisiones, en general todas tareas que nos permiten asegurar la calidad en un proyecto. Una medida para reducir el impacto es acotar las funcionalidad de los proyectos, con lo cual nos enfrentamos a otra limitante, el no cubrir las expectativas del cliente.

¿Cuál es la solución entonces? ¿Abandonar el proyecto, pagar el precio de las adaptaciones de nuestro proveedor y quedar atados a sus disposiciones o pensar en más alternativas? Hace algunos años hablar de Software Libre o Código Abierto dentro de las empresas pasó de ser una locura a una especie de tendencia que hoy en día ha demostrado ser una fórmula  válida no sólo a nivel económico, sino por la reducción en el tiempo de desarrollo y la posibilidad de enfocarnos más en las funcionalidades principales en lugar de tener que pensar en la construcción de los elementos básicos o de las tareas repetitivas como la administración de parámetros por ejemplo. Una clara muestra de estas soluciones las da el sistema operativo Android de Google, tomando como base varias tecnologías desarrolladas bajo el esquema de Software Libre, entre ellas el sistema operativo GNU/Linux más el lenguaje de programación Java pudieron reducir el tiempo de desarrollo y aprovechar el conocimiento de la comunidad para generar un resultado efectivo en un tiempo mucho menor a los demás fabricantes de software para dispositivos móviles.  Si unimos eso al hecho de que China ha sido desde hace mucho un productor de dispositivos electrónicos económicos, que en hardware tienen componentes similares e inclusive a veces superiores a los del resto, pero con un sistema operativo nada agradable o poco usable, unimos estos dos factores y tenemos un proyecto que ha logrado pasar de tener el 5% de cuota de mercado en Estados Unidos al 29% en muy poco tiempo, sobrepasando e inclusive poniendo en aprietos a grandes fabricantes como Nokia.  (Fuente: Android Takes Lead Of US Smartphone Market [2011-03-08]). Otros proyectos como el bien conocido Facebook no habrían podido llegar al nivel de desarrollo actual si no fuera por todos los proyectos de Software Libre que utilizaron como base para poder arrancar y evitar desarrollar todas esas soluciones desde cero, algunos de los proyectos que utilizaron para armar su infraestructura base fueron: PHP, Apache Hadoop, CFEngine, MySQL, Varnish, Python, entre otros. (Fuente: Facebook Open Source [2010-12-09]) Suena como si fuera la solución ideal fuera desarrollar a partir desde el código de un proyecto de Software Libre, realmente sí puede convertirse en una solución viable, pero como casi todo en la vida tiene sus trucos.   O como dicen los anglosajones el "tradeoff". En base a las experiencias de distintas empresas y lo que hemos podido observar como asesores de T.I., algunos de los problemas con los que nos podremos encontrar al utilizar componentes o proyectos basados en Software Libre o Código Abierto son:

  • Falta de soporte técnico.- Algo a lo que las medianas y grandes empresas siempre han estado acostumbradas a tener, poder contar con el respaldo de una firma que pueda resolver dudas o problemas en caso de  que se presentaran con el software o la herramienta que se está utilizando, si bien podemos encontrar ayuda o soporte en base a la información publicada por la comunidad, representa consumo de tiempo, recursos y además no existe legalmente alguien obligado a responder por los problemas que se pudieran presentar.  La solución más común para esto ha sido que los creadores de la herramienta o algún grupo afin se encargue de dar el soporte y llevar la relación comercial a través de un contrato de soporte con los diferentes usuarios, respetando siempre las normas de la licencia que esté asociada al proyecto.
  • Documentación incompleta o inexistente.- Al igual que el soporte la documentación no es algo que siempre puede encontrarse en todos los proyectos, en los más organizados y estructurados generalmente sí tienen información al día generada por los propios miembros de la comunidad, sin embargo podemos encontrarnos también con casos en los que la documentación es escasa o vaga y el tiempo que pudo haberse convertido en ganancia, se convierte en tiempo desviado del proyecto para poder entender el funcionamiento del componente de software.  Posibles soluciones son:  Utilizar unicamente herramientas o proyectos de software en los que todo se encuentre apropiadamente documentado y registrado o solicitar dicha documentación a los creadores originales del proyecto o ser nosotros mismos los generadores de esa documentación y aportarla al proyecto.
  • Falta de verificación de niveles de calidad en el código base.- Un error común es asumir que si lo vemos funcionar, debe estar bien.  A pesar de que en el Software Libre y el Open Source se aplica la lógica del "millón de ojos", es decir que no sólo tenemos un grupo pequeño de personas probando y revisando nuestra aplicación, sino que puede haber millones de personas de distintas partes del mundo revisando el contenido, forma de funcionamiento y usabilidad, existe la posibilidad de que alguno de esos proyectos haya sido desarrollado sin llevar estándares de calidad o revisiones previas (Esto es más común en proyectos desarrollados por miembros jóvenes de la comunidad que comienzan a veces como un hobbie y sin esperarlo terminan siendo proyectos populares).  Para evitar este problema debemos realizar revisiones de código, de calidad de software e inclusive pensar en formar parte del proyecto original si es que realmente nos interesa poder utilizar esa herramienta para nuestros proyectos.
  • Necesidad de mantenimiento constante y actualización.- Por más que hayamos encontrado la herramienta de software ideal para nuestro proyecto, no implica que esta herramienta no tenga errores o fallas, podemos minimizar o reducir esas fallas con una buena evaluación y revisión, pero siempre será necesario verificar si el autor original del proyecto no ha corregido errores o generado parches de seguridad.  Esto es mucho más común en aplicaciones web, un ejemplo claro es el caso de herramientas de manejo de contenido como Joomla o Wordpress que necesitan constantemente estar pendientes de posibles vulnerabilidades y si decidimos crear proyectos en base a dichas herramientas debemos considerar que los cambios o adiciones que realicemos puedan permanecer en el tiempo a pesar de las posibles modificaciones o ajustes que realicemos.
  • Errores de licenciamiento.- Este es uno de los problemas más comunes, al ser Software Libre u Open Source, a menudo se cree que es simplemente "gratis" y que podemos usarlo como querramos, si bien es cierto tenemos un conjunto de libertades, esto no implica que no existan condiciones y estas no deban ser respetadas.  Basta con comenzar a nombrar algunas de las posibles licencias como para confundir a quien quiere comenzar a trabajar en base a una herramienta de este tipo, por ejemplo: GPL,LGPL,BSD,Mozilla Public License (MPL), Afero, Creative Commons , MIT License y la lista continúa (Lista del Open source Iniciative), cada una con sus características, atribuciones, derechos y restricciones  que si no son consideradas pueden causar problemas a la larga, cuando el proyecto ya está en marcha.  Para evitar esto tenemos que revisar de manera prolija la licencia de las herramientas que vayamos a utilizar para estar seguros de que no vamos a infringir ninguna de las condiciones de la licencia y de ser posible asesorarnos a nivel legal antes de iniciar el proyecto.

Cada una de estos problemas pueden sonar casi como buenas razones para evitar el uso de algún software o herramienta de ese tipo, pero realmente no lo son, más bien son puntos muy importantes que no debemos descuidar al momento de iniciar nuestro proyecto para que sea exitoso, una buena gestión del proyecto y un análisis de riesgos a tiempo pueden marcar la diferencia entre un proyecto entregado a tiempo y un proyecto de marcha mortal (Más información respecto a qué es un proyecto de marcha mortal en InformIT - en inglés -).