Una nueva mirada al código abierto

El software de código abierto ya no es sólo para alpha-geeks (ultrainnovadores tecnológicos)

Usted debe reducir costos, pero no es gerente. Es un desarrollador de software, o un usuario avanzado, o simplemente alguien que necesita mantener buenos resultados como para sustentar el salario. Son situaciones ideales para introducir soluciones de software de código abierto en su entorno. Podría parecer que pasará las próximas tres semanas aprendiendo a programar o a escribir makefiles, pero no es así. Siga leyendo y vea cómo el código abierto es un enfoque flexible y utilizable para lograr eficiencia en su entorno laboral.

Brett McLaughlin, Author and Editor, O'Reilly & Associates

Brett McLaughlin es una de las autoridades líderes actuales en programación empresarial. Ha diseñado, realizado la arquitectura e implementado soluciones empresariales en Nextel Communications y Allegiance Telecom, Inc., y ha ayudado a desarrollar el servidor de aplicación J2EE de código abierto Lutris Enhydra. Ha escrito libros sobre XML, Java, enlace de datos y aplicaciones empresariales, y es autor de más de 50 artículos sobre programación empresarial. Además, Brett es un miembro dedicado en cada servidor de aplicación J2EE de código abierto disponible en la actualidad: JBoss, Enhydra, and OpenEJB. También es cofundador de la API JDOM para Java y XML, el proyecto Apache Turbine, y participa en una gran cantidad de otros proyectos de código abierto. Actualmente escribe y redacta para O'Reilly & Associates, el editor técnico líder en el mundo. Para contactarse con Brett, escríbale a brett@oreilly.com



01-06-2010

Código abierto en 2010

No se preocupe, lo que sigue no es un gran discurso sobre las ventajas del código abierto. Como mucho es un intento de disipar los mitos generados precisamente por esa clase de discursos. Si hay algo que debe comenzar a pensar, es lo siguiente: el código abierto ya no es una opción a todo o nada. En otras palabras, este artículo no insistirá para que deje Windows®, instale GNU Linux®, maldiga a Adobe o queme Apple como tributo.

Este artículo tiene un propósito mucho más humilde: convencerlo de que el software de código abierto es una solución para algún subconjunto de problemas y que probablemente existan algunos desusproblemas dentro de ese subconjunto. Así que a sea que tenga problemas de explorador con Internet Explorer®, esté buscando un buen código de Entorno de Desarrollo Integrado (Integrated Development Environment - IDE), esté cansado de pagar PhotoShop, o simplemente desee un sistema de soporte más cercano al tiempo real, el código abierto podría ser parte de su estantería de software.

Casi siempre es mejor un enfoque híbrido

Supongamos que usted no se mete en el código abierto solo por motivos filosóficos. No quiere decir que no valora el enfoque de código abierto; es simplemente decir que tiene inquietudes pragmáticas para buscar soluciones alternativas a los problemas de software que enfrenta. De acuerdo a eso, probablemente no sea un candidato para pasar “completamente a código abierto”. Así que tendrá algo de software — aunque la mayoría de su software — sea de "código cerrado". Eso significa que el software es comercial o simplemente no le da acceso al código fuente. Está bien. No hay nada que sugiera que es malo mezclar software de código abierto con software que no lo es.

De hecho, un enfoque híbrido al código abierto es su mejor opción. En este enfoque encontrará uno o dos problemas en su entorno actual. Por ejemplo, suponga que está en Windows e Internet Explorer lo vuelve loco. Si cambia a Firefox, ese es un enfoque híbrido al código abierto. (Sí, por si no se dio cuenta, Firefox está construido directamente sobre software de código abierto.) Está mezclando software comercial, como Windows, con software de código abierto, como Firefox. Obtiene lo mejor de ambos mundos sin tener que vivir completamente en uno u otro.

El equilibrio entre su software de código abierto y su software de código no abierto depende completamente de usted. Quizás nunca use nada más que Firefox. Eso es genial. Por otra parte, puede inclinarse por el enfoque de Ernie Ball propugnado por Sterling Ball (consulte el enlace a la historia de Ernie Ball en CNET a la que se hace referencia en Recursos); ellos usan casi completamente software de código abierto. En ambos casos, o en los lugares intermedios, usted toma decisiones basándose en lo que necesita, y eso es bueno.

Código abierto no significa destinado únicamente para desarrolladores

Como desarrollador que ha trabajado en proyectos de código abierto durante casi 10 años, sé muy bien que muchas comunidades de código abierto tradicionalmente han sido cerradas e incluso esnob. Si uno formula una pregunta sobre una lista de usuario que otra persona preguntó hace seis meses, recibirá un insidioso: "¡Lee los archivos, novato!" Si envía una solicitud de una función, puede recibir un: "Deja de quejarte y arréglala solo. Es código abierto". Estos son enfoques horriblemente arrogantes, de desarrolladores egoístas, al código abierto.

Por suerte, la mayoría de los proyectos con esta clase de actitudes han desaparecido o cambiado drásticamente. Los desarrolladores que tiene un poco de decencia se han alejado o incluso abandonado proyectos que tienen esta clase de comportamiento. Actualmente, en 2010, la mayoría de los proyectos de código abierto no sólo tienen sólidas listas de usuarios controladas por desarrolladores amables sino que también integran Facebook, Twitter y LinkedIn como canales de comunicación complementarios. Los sistemas de rastreo de errores son algo común en los proyectos, así que puede enviar una solicitud de función o error sin miedo a ser atacado. De hecho, los mejores proyectos reciben de buen grado estos informes, pues mejoran el proyecto.

A modo de ejemplo, Xalan-J, un procesador y transformador de XML, tiene una página extensa que detalla cómo manejar problemas, que se muestra en la Figura 1.

Figura 1. Xalan-J brinda una página redactada con claridad donde detalla cómo informar problemas
Xalan-J brinda una página redactada con claridad donde detalla cómo informar problemas

No sólo se brindan instrucciones sino que se menciona una lista de usuarios para obtener ayuda. Si bien esta página propugna que usted trate de arreglar un error, vale la pena observar que Xerces-J es por naturaleza un proyecto de código de nivel bajo. Sin embargo, hay información sobre cómo enviar un error utilizando JIRA, una API de informe de errores con todas las funciones necesarias (ver la Figura 2). En otras palabras, no trata con subsistemas de interfaces de usuario de sólo texto e instrucciones complicadas. Los informes de errores y las solicitudes de funciones son carriles documentados y fácilmente accesibles para recorrer como usuario.

Figura 2. JIRA ofrece un sólido sistema de informe de errores, y es completamente abierto y accesible para los usuarios
JIRA ofrece un sólido sistema de informe de errores, y es completamente abierto y accesible para los usuarios

La comunidad es algo bueno

En última instancia, la clase de interacciones aquí descritas están a la altura de lo que se podría llamar comunidad. Aunque es posible simplemente enviar una solicitud de ayuda o enviar un informe de error y luego revisar listas de usuarios, no es la norma. La mayoría de los usuarios que se suscriben a una lista de correo de un proyecto de software terminan quedándose. Encuentran a otros usuarios que trabajan en los mismos dominios problemáticos, o enfrentan problemas similares en otro dominio.

Aunque parece simple, e incluso demasiado idealista, se forma una comunidad en estas listas de correo y sitios de soporte. Encontrará personas que nunca pensó que conocería que pueden ofrecerle consejos, o a las que usted puede ofrecerles consejos, en el contexto de sus problemas de software. Volviendo al artículo que mencionamos antes sobre la experiencia de Sterling Ball con el código abierto, éste sirvió para algo más que mejorar su negocio: generó el deseo de informar a otras personas en situaciones similares cómo trataron ese problema muy real, y cómo lo superaron. Como resultado, muchas otras empresas prueban variaciones de la solución de Sterling y de Ernie Ball.

El software de código abierto parece generar estas clases de iniciativas comunitarias. Ya sea por la naturaleza de tener listas de correo abiertas o porque el software evoluciona abiertamente al ser abierto, la interacción parece prosperar. Con certeza, nadie parece oponerse seriamente a la interacción en sí misma, ni siquiera las empresas comerciales. Pero con el software de código abierto, esa interacción parece fomentar más interacción, y en especial, la interacción de usuario a usuario. No es un beneficio trivial del código abierto.


El código abierto es abierto

Trato de evitar colocarles títulos inteligentes — a los libros, a las secciones de un artículo, o lo que sea, pero aquí, esto debe decirse: lo “abierto” del código abierto no es redundante ni carente de importancia. Sí, supongamos que tiene intereses corporativos y de gerentes; la primera sección de este artículo debería haberles hablado detalladamente.

Pero en virtud de seguir con IBM® developerWorks, voy a hacer otra suposición: Usted tiene al menos mentalidad de desarrollador. Quizás no programa tanto código como quisiera, pero aún piensa como desarrollador. Eso es bueno. También es, sinceramente, el espacio en el cual el código abierto brilla con más fuerza. Una vez que pasa los enfoques híbridos y la comunidad, sus inquietudes se hacen más técnicas; y el código abierto resuelve la mayoría de estas inquietudes extremadamente bien.

La auto documentación a menudo es tardía, pero útil

Primero, las malas noticias: los desarrolladores son notoriamente malos para documentar sus códigos. Eso significa que si va a profundizar en Xalan-J, Firefox o su proyecto favorito en Sourceforge.net, no siempre encontrará buena documentación (los enlaces a todos estos proyectos se encuentran en la sección Recursos). No es poco común ver un método llamado initParser() llamado de manera poco útil "inicializar el analizador". Eso difícilmente resulte útil.

Sin embargo, cuanto más maduro es un proyecto y su base de código, mejor tiende a ser la documentación. Por ejemplo, el proyecto JDOM, que existe hace varios años (ver Recursos). JDOM es una API de código abierto para analizar que es más fácil de usar que SAX o DOM. De hecho, muchas personas — de la NASA e incluso Sun Microsystems (actualmente Oracle)— están utilizando JDOM. Parte de ese uso es generado por su API bien documentada. Por ejemplo, el Listado 1 muestra el código para un solo método de la interfaz Element.


Listado 1. Ejemplo de documentación interna de JDOM

Como desarrollador, esto es tremendamente útil. No hay confusión, y utilizar esta clase se hizo mucho más fácil. Por supuesto, la mayoría de los lenguajes — Inclusive el lenguaje™ Java — permiten que esta clase de documentación de nivel código se convierta en algo más utilizable. La Figura 3 muestra el JavaDoc para la interfaz Element, generado directamente desde la documentación de código mencionada anteriormente.

Figura 3. JavaDoc es una representación visual de la documentación a nivel del código
JavaDoc es una representación visual de la documentación a nivel del código

Las grandes comunidades son grandes grupos de soporte

Desarrollemos esta idea de documentación a nivel código. Primero, un desarrollador escribe documentación. Luego, otras personas del proyecto interactúan con ese código y refinan o hacen que el desarrollador original refine su documentación. Por ende la documentación mejora.

Luego, los usuarios comienzan a interactuar con el código. Algunos de los usuarios encontrarán problemas, los informarán, e incluso los arreglarán. La documentación aumenta.

A medida que crece la base de usuarios, ocurre otra cosa: varios de sus usuarios serán de tipo A, personas ultra orientadas a los detalles (y puedo decirlo porque soy una de esas personas). Estas personas se meten en la base del código y mejoran la documentación. No pueden evitarlo; es su naturaleza. Así que aunque algunos de estos usuarios jamás cambian la funcionalidad del código, mejoran su documentación.

A través de todo este proceso, la comunidad de usuarios se convierte en la comunidad de soporte. Las respuestas son recibidas por un grupo cada vez mayor de personas involucradas — muchas de las cuales no reciben pago ni están afiliadas a la base de código fuente original. A modo de ejemplo, observe el foro para novatos del proyecto Eclipse (ver Recursos). Este es un entorno de desarrollo de código abierto. Desplácese por los diversos mensajes; es asombroso ver cuántos se responden — y son respondidos en detalle — por personas que tienen un correo electrónico de Eclipse.org. No son personas de IBM que tratan de ser arteros. En cambio, puede ver cómo una comunidad de código abierto rápidamente se convierte en una comunidad de soporte. Esto no es software comercial, ¿verdad?

¿Puede enviar correo directamente a Microsoft?

Bien, es un golpe bajo. Igual, este tema es real: Cuanto más grande es la empresa, más difícil es obtener soporte de calidad. ¿Cuándo fue la última vez que pensó que podía recibir un correo electrónico personal sobre sus problemas con Excel®o Mac OS X? Si bien ocasionalmente ocurre — y a menudo parece tratarse más de relaciones públicas que de un verdadero soporte — esto no es la norma. Y si bien ciertamente puede comprar contratos de soporte, resulta totalmente azaroso quién atiende el teléfono cuando llama.

Bien, seamos claros: yo, como estoy seguro de que usted también, hemos tenido buenas experiencias de soporte. Hubieron personas que hicieron caso omiso de que se había acabado mi período de registro y me ayudaron; recibí explicaciones geniales y bien formuladas por correo electrónico minutos después de colgar; me han llamado sólo para hacer un seguimiento. No hay nada que diga que las empresas comerciales no pueden contar con un gran soporte.

Además, muchos proyectos de software de código abierto tienen empresas que han crecido para brindar soporte a esos proyectos. Algunas usan estas empresas, otras no. Así que el soporte puede ser tan “comercial” en un entono de código abierto como en uno de código cerrado. Los estereotipos rara vez ayudan, y hacen que usted y los que podrían compartir su posición se vean como tontos con mayor frecuencia.

Sin embargo, considere lo que hemos explicado aquí: El soporte ya no es el dominio principal de un par de individuos pagos. La documentación de código brinda soporte. Leer esta documentación lo vuelve más experto, y en muchos casos, capaz de brindarse soporte usted mismo. El grupo de usuarios forma una comunidad de soporte mayor. En última instancia, prefiero confiar en el consejo de alguien que acaba de pasar toda la noche tratando de solucionar un error que yo también tengo que en el de una persona paga que me lea respuestas de Preguntas frecuentes — Independientemente de lo geniales y detalladas sean esas Preguntas frecuentes.


El software de código abierto es iterativo

Iteración es un término que se ha utilizado mucho. Especialmente aparece en círculos de desarrollo de software. En el software de código abierto,iteración se refiere a la tendencia que tiene el software de sacar nuevas versiones con frecuencia. De hecho, es una idea central del software de código abierto: versiones prematuras, versiones frecuentes. Así que podrían haber fácilmente 15 ó 20 versiones entre las versiones más importantes (2.0, 2.1, 2.1.1, 2.1.2, 2.2, etc., y luego finalmente 3.0).

Aquí no hay nada que sugiera que el software comercial no hace lo mismo. Sin embargo, estas iteraciones a menudo se ocultan a la base de usuarios común y típica. Incluso sistemas como Windows y Mac OS X,— aunque se actualizan con frecuencia —, les restan importancia a esas actualizaciones con mensajes discretos en la parte inferior de la pantalla, o en ventanas minimizadas. ¿Por qué? Porque para la mayoría del software comercial, la revisión se considera corrección de errores. Cuantas más revisiones, más errores se deben corregir.

Con el software de código abierto, sucede lo contrario. El código es abierto, así que si hay errores, todos— los conocen. Simplemente suscríbase a una lista de usuarios de JDOM, Xalan-J, Eclipse o Firefox. Los errores no son secretos. Regístrese en JIRA para cualquier proyecto que desee. ¿El resultado? Versiones y revisiones frecuentes para arreglar esos errores. ¿Cuál es la necesidad de esconder algo? Y con esas versiones frecuentes, usted — el usuario — puede obtener buenas ventajas.

Usted controla las solicitudes de funciones

Cuando el software tiene versiones frecuentes, y no hay errores “ocultos”, entonces hay una base de código en continua evolución. A modo de corolario, entonces, las mejoras de funciones son fáciles. Si ya saca versiones una vez por mes, o más, ¿qué evita que el software agregue funciones, y no sólo arregle errores?

Piénselo bien. La comunidad de usuarios es la comunidad de soporte, que encuentra y soluciona errores. Los desarrolladores están comprometidos con su público porque también son el público. ¿Entonces quién controla las solicitudes de funciones? ¿Un administrador en algún lugar? ¿Una junta de accionistas? ¿Un gerente de proyecto? Bueno, no, (aunque todos pueden estar involucrados en alguna u otra etapa). Usted tiene el control. Usted el público. Usted es el accionista, de muchas maneras.

En última instancia, las versiones frecuentes significan mejora frecuente. La solución de errores es una mejora, pero también lo son las mejoras de funcionalidad. Y como el desarrollo es abierto, usted es una gran influencia. En JDOM (del cual fui co-creador y activista durante mucho tiempo), la mayoría de los cambios importantes de software se hicieron en respuesta a solicitudes de usuarios. El paso a una versión que tenía un soporte más impulsado por la interfaz fue propuesto por un usuario que no tenía relación “oficial” con el proyecto. Simplemente se involucró. En gran parte Eclipse es impulsado por programadores inteligentes que tienen usuarios nuevos para la base de código.

El software de código abierto se adapta a su medida (de alguna manera)

En última instancia, hace tiempo que los usuarios que usan software de código abierto son una fuerza que adapta ese software a sus necesidades. Usted puede ser callado, jamás unirse a una lista de correo, y simplemente dejar que la calidad sea su factor de decisión. Eso es en gran parte lo que impulsó a Ernie Ball. Por otra parte, su participación significa que obtiene el control de su software. Las solicitudes de funciones que tiene se comunican, e incluso tiene la facultad de agregar su propia funcionalidad.

Al mismo tiempo, usted se adapta a la medida del software. Eso no es malo. El uso frecuente, y la clase de comprensión de una base de código que brinda el código abierto, le permiten personalizar la manera en que trabaja para que su software rinda más. Descubrirá que a medida que aumenta su conocimiento del proceso interno de su software — un efecto natural de su participación en las listas de usuario y el brindar ayuda con el código — usted toma decisiones que optimizan el uso de ese software. Lo conoce bien, sabe dónde funciona bien, y sabe dónde hay problemas. Y, en última instancia, aprovechará ese conocimiento y tendrá un mejor desempeño.


Conclusión

La mayoría de los artículos que leerá sobre código abierto en la actualidad son sermones religiosos, o en el mejor de los casos, tienen un enfoque práctico, pero aún se percibe un aire de fervor debajo de la prosa. Durante muchos años, los defensores del código abierto han utilizado argumentos filosóficos para apoyar su caso. Los defensores parecen desear conversos más que usuarios. Eso no es muy atractivo — no sólo para las personas que no son desarrolladores sino para muchos programadores que tienen tiempo de colocar una bandera de código abierto junto a su cubículo.

Lo que oscurece en realidad esta casi propaganda son los verdaderos beneficios del software de código abierto. Utilizado con juicio (es una manera menos ofensiva de decir: “¡No use código abierto en todos lados en la mayoría de los casos!"), el software de código abierto puede reducir costos y, en algunos casos, mejorar la funcionalidad. Como ya se mencionó, Firefox es el ejemplo más obvio para la mayoría de los usuarios informales: pocas personas instalan Firefox porque tienen un plan de defensa del código abierto. Es simplemente un navegador muy útil, con más complementos que todos los demás navegadores combinados. ¿Por qué? Porque el software recibe soporte de una comunidad activa y vigorosa.

Quizás el mejor argumento para que usted tome en cuenta el software de código abierto en un entorno híbrido siga siendo la misma IBM. (Sí, este es un artículo publicado en un sitio de IBM. Sin embargo, la afirmación sigue teniendo validez.) IBM parece arreglárselas para llegar a fin de mes con sus ofertas comerciales y aún tiene una buena lista de software de código abierto flotando por ahí, desde donaciones a Apache a Eclipse y demás. Este enfoque — que utiliza código abierto cuando tiene sentido— es el enfoque que se le recomienda.

Quizás no le guste Gimp, y PhotoShop sea su mejor elección. Quizás los marcadores sincronizados de Safari en su escritorio y iPhone realmente sean la mejor solución. Es genial. Simplemente no descarte toda pieza de software de código abierto en un arrebato de indignación. (Esa oración parece tan exagerada como la acción que describe). Si necesita ciclos de actualización rápidos y funciones de último momento, busque alternativas con código abierto. Si necesita soporte sin gastar miles de dólares por año, vea lo que ofrece el código abierto en un área particular. Y haga lo que haga, esté informado. Tome buenas elecciones basándose en información buena. Todos seremos más felices. E infórmenos qué ofertas particulares de código abierto escoge — y rechaza — y los motivos de estas decisiones. Nos vemos en línea.

Recursos

Aprender

Obtener los productos y tecnologías

  • Eclipse es una de las mejores IDE que hay, y tiene una arquitectura de complementos ampliables. Lo mejor de todo es que es totalmente de código abierto.
  • Xalan-J es un procesador XML de código abierto, construido en analizadores y herramientas de código abierto.
  • JDOM es una API analizadora de código abierto, construida por una frustración que generan las API existentes. Eso es código abierto puro: arreglar algo porque no funciona.
  • Pruebe Mozilla Firefox, un navegador Web de lo mejor, y el mejor punto de partida para probar software de código abierto confiable.
  • Innove su próximo proyecto de desarrollo de código abierto con el software de prueba IBM, que se puede descargar o ver el DVD.
  • Descargue las versiones de evaluación de los productos IBM o explore las pruebas en línea en IBM SOA Sandbox y haga un uso práctico de las herramientas de desarrollo de aplicaciones y middleware de DB2®, Lotus®, Rational®, Tivoli® y WebSphere®.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=966307
ArticleTitle=Una nueva mirada al código abierto
publish-date=06012010