Llegamos a ustedes gracias a:



Reportajes y análisis

Evaluando código abierto: Una tarea no tan simple

[27/05/2013] La universidad de West Texas A&M quiso desarrollar un portal sencillo para sus ocho mil alumnos que pudiera unificar sus aplicaciones web, los recursos para alumnos y los servicios de redes sociales. A un comité directivo se le ocurrió una lista de seis criterios para la evaluación del software disponible. Ellos compararían las características de los sistemas de software, la movilidad, las capacidades de inicio de sesión único, el look and feel y la flexibilidad, así como su capacidad para integrarse con las aplicaciones web existentes.
Pero no era una comparación de manzanas con manzanas. El CIO, James Webb, incluyó un par de proyectos de código abierto para ser considerados junto con los paquetes comerciales de software. Aunque era fácil comparar los sistemas en muchos de los criterios (los paquetes de código abierto ganaron en las seis categorías), el comité tenía otra pregunta: ¿qué tan fuerte es la comunidad de usuarios de código abierto y podría ayudar a la universidad a lograr sus metas? La respuesta fue , y la escuela establecida en el Cañón de Texas eligió las dos herramientas de código vierto: uPortal, una arquitectura basada en Java y en XML que también incluye soporte para dispositivos móviles; y Central Authentication Service (CAS), ambas de Jasig, para su servicio de inicio de sesión único.
Una de las principales razones por la que fuimos con la solución de código abierto uPortal fue que Yale, Rutgers y la Universidad de Wisconsin-Madison son los mayores desarrolladores. Así que creo que se podría decir que estaba construida por grandes educadores para grandes educadores, explica Webb. Sabemos que tenemos un ecosistema de grandes universidades que están contribuyendo a la iniciativa de código abierto, aportándolo y ofreciendo características adicionales para mantener el producto innovador.
El código abierto es el nuevo factor X en la selección de software. Más del 50% de todo el software adquirido será de código abierto para el año 2017, según un estudio del 2012 en 740 empresas, publicado por una alianza de 26 empresas de código abierto. Ese hallazgo indica un punto de inflexión en la adopción de software de código abierto en la empresa y los campos no técnicos, tales como las industrias de servicios financieros, automotriz y de sanidad.
Escoger la oferta correcta de código abierto puede ser fundamental para el éxito de una organización. Sin embargo, la evaluación de un proyecto de código abierto tiene más advertencias y peligros que cuando se habla de software tradicional.
Los departamentos de TI deben tener en cuenta la cultura de la comunidad de código abierto, la calidad y la línea de tiempo de los lanzamientos, el modelo de gobernanza de los proyectos y la disponibilidad de soporte. También tienen que considerar si, y en qué grado, están dispuestos a contribuir con código y con correcciones a la comunidad.
Aquí, las organizaciones que han adoptado con éxito los sistemas de código abierto comparten los criterios que utilizan para evaluar los proyectos y su filosofía de retribuir a la comunidad de código abierto.
'Proyectos' vs 'Productos'
Muchos departamentos de TI evalúan los sistemas de código abierto de la misma manera en que evalúan los productos comerciales. Buscan herramientas que ofrezcan una funcionalidad superior y menores costos de mantenimiento y soporte. Muchas de ellas también recurren al código abierto para escapar de los bloqueos de los fabricantes, fomentar la sostenibilidad dentro de la infraestructura de TI, e impulsar la innovación en las operaciones de TI.
Pero hay otras cosas a considerar cuando se mira los sistemas de código abierto, como la cultura de la comunidad, la consistencia de la calidad del producto, y la rapidez con la que la comunidad responde cuando se necesitan actualizaciones de seguridad y parches.
"Es importante evaluar proyectos más pequeños de código abierto de manera diferente a los más grandes o patrocinados por las corporaciones", señala Tomas Nystrom, director senior y líder mundial de código abierto en Accenture.
Hay cientos de miles de pequeños proyectos de código abierto o librerías, como la NAS y la Spring, que dependen en gran medida de las comunidades de usuarios. Luego están los productos de código abierto, como Red Hat Linux, que son gestionados por, y a menudo son propiedad de, las empresas que están en el negocio de venta de software.
Sprint Nextel decidió que un producto bien establecido satisfaría mejor sus necesidades cuando se aventuró con cautela en código abierto, después de haber crecido cansado de pagar a los fabricantes millones de dólares en gastos de mantenimiento por el software de servidor de aplicaciones web, aun cuando la necesidad de soporte disminuyó.
"Construimos un equipo interno que responsable de los servidores de aplicaciones web y creíamos que podíamos cambiar a un producto de código abierto y aun así tener éxito", recuerda Alan Krause, director de integración de aplicaciones empresariales en Sprint. Pero ir por solos era una propuesta que atemorizaba al CIO y a un vicepresidente, quienes querían tener la seguridad de contar con un proveedor en quién apoyarse si surgían problemas.
"Realmente hubo un poco de miedo no", recuerda Krause. Así que la organización eligió JBoss Enterprise Application Platform como su nuevo middleware, y Red Hat Enterprise Linux como su nuevo sistema operativo. También utilizaron al equipo de consultoría de Red Hat para ayudar con la implementación, y permitieron que un administrador de relaciones de Red Hat sirviera como enlace con la comunidad de código abierto.
"Estamos sumergiéndonos en el código abierto, señala Krause. Aún estamos pagando algo de mantenimiento por ello, pero es significativamente más barato que lo que pagábamos antes.
Al mirar los productos de código abierto como Red Hat, los criterios de selección no son diferentes de los que se aplican al software comercial, añade Nystrom. "Están considerados como proveedores habituales con productos de alta calidad que son comparativamente más baratos".
Dado que los productos de código abierto ganan tracción en empresas como Sprint Nextel, los departamentos de TI se sentirán más cómodos moviéndose hacia proyectos de código abierto más pequeños para fomentar la innovación, afirma Nystrom. "Si está construyendo algo personalizado, es típico que utilice [código abierto] en algún momento durante el desarrollo", señala. "Es casi imposible que no lo use si quiere construir una aplicación muy moderna".
En tales casos, Nystrom recomienda un enfoque de abajo hacia arriba para la elección de proyectos de código abierto.
"Los desarrolladores y arquitectos saben lo que las comunidades son, y lo que son las librerías que tienen mayor uso hoy en día", explica Nystrom. "Ellos tienen una visión más clara de qué librería debemos usar para cada propósito, o qué versión de algún tipo de API persistente se debería utilizar aquí, o cual es la mejor librería para procesos de registro. Así se puede reducir muy rápidamente el número de librerías que son relevantes para la empresa-probablemente pasen de cientos de miles a menos de cien, dependiendo de lo que queremos construir. Y a partir de ahí se trata de un movimiento rápido hacia unas cuantas alternativas ya conocidas, añade.
West Texas A&M eligió el proyecto CAS por su sistema de inicio de sesión único, el cual había sido implementado con éxito en la Universidad Texas A&M en College Station "y las referencias eran sólidas", señala Webb. Su equipo también asistió a eventos de usuario y conferencias de educación superior relacionadas con CAS como parte del proceso de toma de decisiones.
Se necesita un pueblo
Para muchos proyectos de código abierto, la comunidad de desarrolladores es el alma del software, y aquellos que son nuevos en código abierto deben saber que todas estas comunidades funcionan de manera diferente.
La comunidad Linux bien establecida, por ejemplo, ha operado bajo la benevolente dictadura de su fundador Linus Torvalds desde su creación. Pero los desarrolladores de nuevos proyectos a menudo mantienen un estricto control de sus comunidades también.
WibiData, una empresa de análisis de usuario basada en Hadoop, que ayuda a las organizaciones a crear aplicaciones de Big Data, ofrece parte de su pila de software de código abierto para que sea más fácil para los desarrolladores construir grandes aplicaciones de datos en una base de datos NoSQL HBase.
"Ahora mismo, el 99,5% del software es escrito por nuestro propio equipo", señala Aaron Kimball, arquitecto en jefe de WibiData. Se necesita un tiempo relativamente largo para que la gente lo use, y por cada 50 personas que lo utilizan, una podría empezar a ayudar a contribuir".
Luego están los modelos radicalmente democráticos. Los desarrolladores que donan un producto a la Apache Software Foundation, por ejemplo, deben alcanzar un "consenso holgado" con la comunidad; lo que significa que "se necesita un número de individuos que den a la idea su aprobación y ninguno que se oponga, y si lo hacen, son obligados a trabajar contigo para hacer los cambios, explica Kimball, agregando: "Está diseñado para ralentizar las cosas de tal forma que todos los usuarios puedan participar, y a través del consenso llegar a la mejor solución. Aunque se espera que los desarrolladores que participan más activamente en la escritura de código fuente sean los primeros en ser escuchados, añade.
¿Es mejor dar que recibir?
Los departamentos de TI pueden pensar que cuando compran código abierto también tienen que participar activamente en la comunidad para asegurar su supervivencia. Pero ese no es siempre el caso.
Con productos de código abierto ampliamente utilizados como Red Hat, "[los proveedores están] mucho más en control de la comunidad", señala Nystrom. Y aunque ellos toman de la comunidad, aún controlan el producto", añade. "No son dependientes de la comunidad para que el producto sea estable y siga adelante".
Sprint Nextel se basa actualmente en consultores de Red Hat como su enlace con la comunidad de código abierto, pero Krause cree que la compañía va a necesitar menos ayuda conforme pase el tiempo. "Con el tiempo vamos a abandonar a Red Hat como nuestro sistema de soporte y trabajaremos directamente con la comunidad de código abierto", agrega.
Para los usuarios de librerías o proyectos de código abierto más pequeños, las comunidades son mucho más importantes.
"Solo hay un grupo de gente que pone esto junto, y tal vez no haya una entidad comercial detrás de ello", señala Nystrom. En estos casos, se espera que los desarrolladores contribuyan, pero ¿qué pasa si se niegan?
Un usuario de código abierto dice que es difícil aportar, o "devolver el dinero", cuando el producto es específico a una industria.
Cuando Hallmark Services Corp. (HSC), en Naperville, Illinois, estaba repotenciando sus sistemas de back-end, compró una licencia de código abierto Healthation, un sistema comercial off-the-shelf para administración de transacciones comerciales de cuidado de la salud.
Adoptar un enfoque de código abierto redujo la cantidad de trabajo necesario para completar el proyecto, lo que permitió a HSC terminar más de nueve meses antes y ahorrar 4,8 millones de dólares en costos laborales, de acuerdo con Neal Kaderabek, CIO y vicepresidente de servicios financieros. HSC es un co-desarrollador de software en Lisle, con sede en Healthation, Illinois, y tiene el derecho de uso exclusivo de las funciones que desarrolla -estas no tienen que ponerse a disposición como código abierto.
"Rara vez devolvemos algo -solo tomamos, modificamos y lo hacemos único para nuestro negocio, señala Kaderabek, agregando que HSC comparte con la comunidad menos de la mitad de lo que desarrolla. Francamente, creemos que nos diferencia de nuestros competidores, así que ¿por qué queremos permitir que el mundo comparta eso?".
Él reconoce que Healthation se decepcionó al ver que HSC no contribuía a su comunidad de código abierto. "Su punto de vista era que lo hacía un producto más atractivo para la industria. Pero en este caso, me sentí como si fuera nuestra salsa secreta", señala.
Este no es a menudo el caso, dicen los observadores de la industria. La mayoría de las aplicaciones de código abierto son esencialmente commodities, y la plataforma en sí por lo general no tiene muchos secretos.
HSC procesa 3.500 millones de dólares en primas de seguros anuales y presta servicios a cerca de 1,5 millones de miembros de seguros al por menor.
La compañía eligió Healthation porque era el único software de transacción de cuidado de la salud que Kaderabek conocía que estaba disponible como código abierto. Con Healthation, HSC podría poner en marcha su proyecto de transformación de TI, debido a que la mayoría de las nuevas funciones básicas ya estaban en su lugar y el equipo tuvo que modificar solo alrededor de un tercio del sistema.
"Estaba por delante del diseño y la arquitectura" de los sistemas tradicionales de software, señala Kaderabek. "Fue construido con la última y mejor tecnología, utilizaba servicios web, era .Net usando SQL Server -todo lo cual cumplía con nuestros estándares. Hicimos más en un período más corto de tiempo, y no tuvimos que añadir recursos adicionales", señala.
Kaderabek agrega que aun cuando evalúen proyectos de código abierto pequeños o específicos de una industria, los departamentos de TI deberían buscar proveedores que se especialicen en mantener una oferta de código abierto. Asegúrese de que haya alguien que pueda decir he hecho esto durante los últimos cinco años y conozco gente que ha hecho lo que usted está haciendo en caso que necesite ayuda, añade.
Cuando abandonar es lo adecuado
Las contribuciones a una comunidad de código abierto no tienen que ser enormes para ser valiosas. "A veces, incluso, los pequeños cambios -que pueden no tomar más de una tarde en escribirse- tendrán una beneficio descomunal en la usabilidad", señala dice Kimball, de WibiData.
WibiData inicialmente desarrolló toda su pila de software por sí solo, pero en septiembre del 2012 decidió poner parte de esa pila disponible como código abierto, y lanzó el proyecto Kiji en noviembre.
Ofrecer algunas herramientas de código abierto beneficia a WibiData de varias maneras, sobre todo por la ampliación de la base de usuarios de la compañía, señala Kimball. Las capas fundamentales de la pila tienen un valor bajo, y los usuarios no pagarán por herramientas que no son exclusivas de su negocio, especialmente si se dispone de otras herramientas similares. Al convertir esas capas en elementos de código abierto, conduce a los nuevos usuarios a otras ofertas de WibiData. "Hay un montón de personas que pueden hacer uso de estos componentes, que [no eran] clientes o clientes potenciales, pero ahora están utilizando y probando el mismo software que utilizan nuestros clientes de pago", agrega Kimball. "Así que todo el mundo disfruta de un incremento en la confiabilidad del sistema en su conjunto, en virtud de que sea más ampliamente adoptado.
Por otra parte, el código abierto ofrece un pie en la puerta a las empresas que podrían no estar listas para una herramienta de Big Data aún. "Si las capas de base común de nuestro sistema general están ampliamente disponibles a través de código abierto, [los desarrolladores] simplemente podrían empezar a usarlas. Y más tarde, cuando su organización necesite tomar en serio el uso de una aplicación de código abierto, será mucho más fácil para nosotros entrar y venderles a los usuarios de negocios, ya que nuestro software ya se ejecuta en parte de su infraestructura. Interoperar con él y conseguir que funcione con el resto de nuestros sistemas es mucho más fácil, en lugar de que si hubiera que construir este mismo sistema de una forma completamente a medida".
Kiji ha recibido pocas contribuciones de la comunidad de desarrolladores hasta ahora, pero Kimball cree que eso va a cambiar. "Por cada 15 personas que lo utilizan, una podría presentar un informe de bug -sin aportar una solución. Pero aún está en sus primeros días", señala. "A dónde irá esto, es una pregunta abierta".
El futuro del software libre en general se ve brillante. Una adopción más amplia creará comunidades más grandes para pruebas y retroalimentación; lo cual a su vez impulsará la innovación en áreas como la computación en la nube, los datos móviles y grandes, de acuerdo con proveedores de código abierto.
El ciclo de innovación también está creando nuevos modelos de negocio. "El código abierto es clave para la capacidad de una empresa para innovar y mantener la innovación con beneficios financieros, interoperabilidad y una comunidad de apoyo", señala Webb. "Esas son las cosas que van a mantener esto funcionando", concluye.
Stacy Collett, Computerworld (EE.UU.)