Blog

Desde hace más de una década se viene hablando de software libre en una u otra forma. Afortunadamente, cada vez es menos una cuestión de GNU/Linux y más de modelos de desarrollo o de negocio.
En las diferentes charlas a las que podemos asistir hoy en día se mezclan frases como «la economía de las personas» (http://www.libertaddigital.com/index.php?action=desaopi&cpn=26956), «web 2.0», «servicios de valor añadido», «desarrollo distribuido», «copyleft» o «dictadores benevolentes» (http://en.wikipedia.org/wiki/Benevolent_dictator).

Todas parecen coincidir en que el software libre –la cultura libre– es una marcha imparable porque procede de los individuos exigentes y alfabetizados digitalmente. Esto es más una voluntad bienpensante que una realidad hoy en día, pero hay que reconocer que, de momento, no hay señales de alarma que ilegitimen ese sueño.

Sin embargo, en cuanto a los modelos de desarrollo referidos al software libre (http://oasis.dit.upm.es/%7Ejantonio/documentos/revistas/teoriajuegos/teoriajuegos.html) hay un exceso de confianza ciega en «los otros». Efectivamente, ya sea porque nos consideramos pequeños en la vorágine copyleftera o porque nos gusta descansar sin más en las espaldas de lo que los gurús comentan, caemos en el error de repetir como loros las siete maravillas del software libre.

Analicemos una de esas siete maravillas: «el software libre es mejor que el privativo porque permite realizar adaptaciones a medida de las necesidades del cliente». Esta frase parece grabarse a fuego en todo documento doctrinario. Posibilidad de adaptación gracias a la posesión del código fuente = bien. Lo contrario = mal. Veamos hasta qué punto es aplicable esta afirmación.

La adaptación del código fuente de un software concreto para satisfacer necesidades particulares no es nada nuevo bajo el sol. Se ha hecho toda la vida independientemente de la naturaleza legal del software. Lo original del hecho de que se rija bajo una licencia libre es que habilita a mucha más gente esas adaptaciones en su copia local y, por tanto, pueden cumplirse las expectativas de muchos más usuarios finales (o, al menos, más perfiles de usuario). Por lo tanto, al igual que las licencias libres como la GPL no son rupturistas con la Ley de Propiedad Intelectual, sino que la enriquecen en sus diversas expresiones, el software libre no inventó la posibilidad de adaptación del código, simplemente la elevó a cotas mucho más interesantes.

Si a ello le sumamos algo ya bastante asumido, que las nuevas tecnologías banalizan cada vez más la réplica exacta –la clonación digital– esperando obtener algún beneficio o dividendo por otras vías y no por tener dos bits en 0 en lugar de sólo uno, tendremos un lema intrínseco al software libre: copiar, sí; plagiar, no.

Sin embargo, tras proceder a descargar en nuestro disco duro el software Z y mirarlo con ojos golosos pensando «tengo todo el potencial a mi disposición y sólo dependo de mi pericia como desarrollador», suele surgir una débil y minúscula pregunta que, en la mayoría de las ocasiones, queda sepultada por una mezcla de pereza y baja autoestima.

La pregunta a la que me refiero es: «¿Convendría que contribuyera al propio proyecto en lugar de hacer una versión a medida de mis necesidades?»

Esta pregunta es igual de relevante tanto si nos encontramos en un contexto puramente personal o de ocio, como si lo enfocamos desde un punto de vista profesional o remunerado. En este artículo me centraré en el segundo modelo.

Ahora mismo, mientras lee este artículo, multitud de empresas de todo el mundo tienen ocupados a buena parte de sus técnicos desarrolladores en descargar software libre para probarlo, jugar con él, simular un caso práctico, realizar comparativas con software privativo y, cómo no, integrarlo en un proyecto software concreto.

En un porcentaje nada desdeñable de estos casos, el software libre descargado es alterado o mejorado en algún punto para adecuarse perfectamente a las necesidades del equipo desarrollador. Puede ser simplemente una forma diferente de compilación, sustitución de un componente por otro o hasta la alteración del código fuente.

En los dos primeros casos, podemos entender la naturaleza «documental» del esfuerzo y, si bien sería de agradecer su puesta en común en foros o listas de correo, es perfectamente comprensible que el día a día nos arrastre e ignoremos este gasto de tiempo. Veamos dos ejemplos que a muchos les sonarán familiares si han desarrollado alguna vez (o manipulado con cierto grado técnico software en general) y que opino que ilustran razonablemente mi punto de vista:

• Encontramos un problema. Buscamos solución en Internet (típicamente, googleando). Nos agrada encontrar a más gente con el mismo problema pues nos da esperanza. Finalmente, leemos respuestas del tipo «Al final lo arreglé, era una tontería. De todas formas, gracias por la ayuda». De la «tonteria» ni rastro. La frustración nos invade.
• Encontramos un problema. Buscamos solución en Internet seguros de encontrar a más gente en idéntica situación (por ejemplo: el software afectado es bien conocido y el contexto es habitual). No encontramos nada. Finalmente, lo solucionamos por nuestra cuenta. No nos tomamos el tiempo de comunicar la solución. Alimentamos el círculo vicioso del misterio con la sensación personal de ser un crack.

¿Verdad que le suenan? Lógicamente, no podemos activar una Policía de la Colaboración Mundial; sólo insistir en las bondades de participar en un modelo en donde aportamos una solución o ayuda cada mes y, a cambio, recibimos mil de éstas al día (y, desde el punto de vista ético, satisfacción personal).

Si volvemos al hilo principal, queda pendiente el asunto de «alteración del código fuente». Aquí ya el escenario es más propio del proyecto o necesidad concreta del equipo de desarrollo. De nuevo, podemos optar por modificar y no decir nada. Con no decir nada me estoy refiriendo a no comentarlo en los foros o listas de correo del proyecto software original ni, por descontado, proponer su inclusión en el código fuente de la versión matriz.

Si la licencia del software que hemos estado modificando es de tipo copyleft «fuerte» (como la GPL) y nos obliga a distribuir las modificaciones bajo la misma licencia, tenemos tres opciones:

• Ignorar la GPL, violando una licencia y arriesgándonos a que el titular del copyright nos demande por infracción legal. Resulta vergonzoso el número de veces que se produce.
• Cumplirla y distribuir la versión modificada «tal cual», sin ningún afán de identificar las nuevas funcionalidades o cuestiones técnicas asociadas. Esto es quizá poco profesional pero lícito y comprensible.

En el caso de ser una licencia más flexible (aunque, en mi opinión, menos libre globalmente) como las del tipo BSD, pueden seguir dándose los dos escenarios anteriores aunque el primero de ellos será más difícil de alcanzar por las menores imposiciones sobre las obras derivadas a las que hay que atenerse.

• Por último, queda, creo yo, la única opción inteligente a medio y largo plazo: integrar parte o todo de los cambios en la versión «oficial». Para ello, hay que formar parte del equipo principal de desarrollo o contribuir con parches y correcciones. Esa condición es la clave para poder influir verdaderamente en el desarrollo actual y futuro de un producto y mientras nosotros, o nuestros clientes, vayan a depender de él de manera significativa no hay que desdeñar esta posibilidad en absoluto.

Imaginemos un caso práctico: tenemos un producto software libre para fabricar Intranets corporativas (secciones con documentos, gestión de vacaciones, notas de gasto, foros, noticias, etc) al que llamaremos FreeIntranet. Al evaluarlo nos convence su madurez, el número de instalaciones en el mundo, la calidad del código y su carácter multilingüe. Nos lanzamos a un proyecto con un cliente X que nos obliga a integrar FreeIntranet con su directorio de usuarios corporativo (para que los empleados hagan login de la forma en la que ya lo hacen con otras herramientas). No hay problema, pensamos; FreeIntranet es compatible con el producto de directorio de usuarios del cliente. A la hora de la verdad resulta que no es todo tan sencillo[1] y hay que invertir horas en arreglar errores de interpretación de formato, codificación de caracteres y rendimiento. Para ello, ha habido que tocar código de bajo nivel y librerías incluidas en FreeIntranet pero, para consuelo de todos, finalmente aquello marcha perfectamente.

Pasa un año y nuestro cliente, satisfecho con nuestro trabajo en la Intranet corporativa, nos encarga una ampliación (ahora quieren un blog por empleado, encuestas, gestión RR.HH y descarga de la nómina en PDF). En principio estamos de enhorabuena pero todo puede torcerse si no hicimos bien los deberes al término del anterior proyecto. Al parecer, FreeIntranet ha pasado de la versión 3.5 a la 4.0 en este tiempo y, como lo ideal sería desarrollar las nuevas funcionalidades con la flamante nueva versión 4.0 con AJAX, consideramos seriamente la actualización de la plataforma 3.5 ya instalada en el cliente a la 4.0. En principio, los módulos funcionales que se pidieron en su momento necesitarán cambios menores (referentes a la API, por ejemplo) pero no ocurre lo mismo con la parte de autenticación contra el directorio de usuarios. De la 3.5 a la 4.0 no ha habido mejoras en ese sentido y, lo que es peor, se ha alterado completamente el módulo de gestión de usuarios, haciendo imposible trazar una correspondencia entre las dos secciones de código, la 3.5 y la 4.0. Desafortunadamente, es necesario volver a realizar todo el trabajo de integración. Ello supuso tantos quebraderos de cabeza en su momento que surgen ahora dudas sobre la conveniencia o no de imponer la 4.0. Al final, optamos por ser conservadores y seguir con «lo que funciona». Es decir, mantener la 3.5, con lo que el cliente no se beneficia de las mejoras aparecidas en la 4.0 y los desarrolladores «sienten» que están trabajando con tecnología, si no «legacy», si «deprecated».

Como amante de los proyectos tecnológicos, esta posibilidad me aterra y propongo evitarlo siempre que haya alguna posibilidad. ¿Qué alternativa sería deseable?

Tras el final del proyecto primero, el asociado a la versión 3.5, el equipo de desarrollo debería haber limpiado el código, documentado los cambios y, de forma modular, proponer su inclusión en la versión oficial. Lógicamente, cuando fusionamos ingeniería informática y software libre la palabreja «meritocracia» salta como un resorte y nos obliga en parte a defender con argumentos sólidos nuestra contribución.

• ¿Está bien codificada? ¿Cumple el estándar propio del proyecto FreeIntranet?
• ¿Está bien documentada? ¿Se comprende bien dónde empieza y dónde acaba nuestra contribución?
• ¿Qué resuelve exactamente? ¿En qué situaciones es útil?
• ¿Qué dependencias de terceros tiene?

No es seguro que nuestra aportación sea aceptada pero no intentarlo es ciertamente poco profesional. Cada línea de código o funcionalidad que consigamos introducir en el repositorio de código de FreeIntranet, seguirá su vida cuasiindependiente en la evolución global y más compleja del software y tiene grandes posibilidades de mutar adecuadamente en el paso a la versión 4.0, enriqueciéndose incluso de aportaciones de otros desarrolladores que construyen mejoras sobre nuestra propuesta ahora que pueden emplearla en situaciones como la que nosotros nos encontramos y que no eran tan infrecuentes.

Naturalmente, si las modificaciones son críticas, convendrá estar pendiente de su evolución dentro del mar de código general y defender su permanencia (de nuevo, con argumentos sólidos) o alterarlas si lo estimamos conveniente. Debemos valorar objetivamente el ahorro de trabajo y la satisfacción de nuestros clientes al pensar en la supervivencia de nuestra contribución.

En definitiva, el modelo, tanto de desarrollo como de negocio, basado en el software libre no depende de si hay más o menos autores (todos estamos, de alguna manera, obligados a fabricar o crear) sino de qué decisiones tomamos como autores y cómo nos coordinamos para invertir tiempo en lugar de gastarlo sin más. De lo contrario, estaremos mucho más cerca del modelo del software privativo de lo que creemos.

Notas:

[1] En esto no hay diferencia esencial entre software libre y software privativo.

Fuente | http://www.diacritica.net/?p=76