Un proceso libre y superior para hacer una tesis

From Software libre para los países en desarrollo

El complicado reto que nos pusimos: crear un proceso mejorado para el desarrollo de una tesis, que:

• use exclusivamente herramientas colaborativas en línea de última generación,
• use software libre al máximo (o, en su defecto, gratuito, pero en el marco de la ley),
• use únicamente formatos de archivo publicados como estándares libres,
• siga las recomendaciones de expertos en materia de publicación de documentos,
• mejore todas las fases de la producción del trabajo, desde la incepción misma del trabajo hasta su impresión final,
• sea automático al máximo, incluyendo la generación de la edición impresa del trabajo (el libro),
• sea generalizable a cualquier proceso creativo que tenga como meta la generación de un libro, y
• fomente el proceso creativo, en lugar de interferir con él.

Lo logramos. A continuación, cómo lo hicimos.

La práctica establecida: odioso software propietario

Una vez decidido el tema, encontramos un escollo en el camino: ¿Y ahora, qué herramientas de software y formatos usaremos?

La práctica establecida en materia de trabajos finales de carrera en nuestra universidad es utilizar Microsoft Word, una plantilla estándar, y LearnLoop como centro de colaboración en línea. En detalle, el proceso para realizar un trabajo de memoria, usualmente involucra (entre otras tareas):

• la edición de uno o más documentos utilizando métodos electrónicos de procesamiento de textos
• la consolidación de las partes separadas en un solo documento final
• el formato del documento final, de conformidad con el formato impuesto por el tribunal o el reglamento de la memoria

Pero nosotros no teníamos Microsoft Word a nuestra disposición. Y hubiera sido extremadamente absurdo utilizar una herramienta de software propietario para desarrollar una tesis sobre software libre. Momentáneamente dejando de lado aquel absurdo, aun cuando este proceso representaba el estado del arte hace 10 años, y sigue siendo útil, ya no es el más idóneo, porque:

• requiere constante coordinación en el contenido de los documentos, sea por medios electrónicos o encuentros cara a cara
• impide la colaboración eficiente en un mismo documento
• generalmente facilita los errores humanos
• el formato y la consolidación son procesos tediosos que consumen mucho tiempo
• dificulta el desarrollo orgánico de una memoria
• elimina totalmente la posibilidad de documentos hipertextuales
• el formato final de archivo no es libre

Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.
Robert Frost - The Road Not Taken

Lógicamente, tomamos el camino menos usado. Veamos en qué consistió ese camino.

Colaboración no presencial en tiempo real: fantástica pero inadecuada

El estado del arte hoy en día está representado por las herramientas de colaboración que permiten a varios participantes editar un mismo documento en tiempo real, y visualizar segundo a segundo las modificaciones que los demás hacen, en modalidad LQVELQO.

Varias herramientas de software libre (p. ej., AbiWord) incorporan esta facilidad. Lamentablemente, aunque la tecnología es excitante, la no disponibilidad de conexión permanente a Internet la deja fuera de juego para esta memoria.

Adicionalmente el estado del arte de estas tecnologías no está suficientemente avanzado, especialmente si invocamos la potencia de herramientas maduras como los wikis (tratados a continuación).

Finalmente, ninguna de las herramientas existentes cumplen con nuestros requerimientos de automatización.

Wikis: (casi) todo lo que necesitamos

De acuerdo a evidencia anecdótica, Wiki es una palabra originaria de Hawaii, que significa rápido. Apropiadamente, se utiliza para describir esta tecnología.

Para llevar a cabo nuestra tesis, hemos utilizado lo que hoy se considera como el estado del arte en herramientas colaborativas: el Wiki. Generalmente, un wiki:

Hipertexto significa, justamente, "más que texto". Al aumentar al texto con enlaces a otros textos y elementos multimedios, la experiencia del usuario mejora dramáticamente. La prueba está en la evidencia: las páginas de la World Wide Web conforman la colección más grande de información, y son hipertexto.

• permite la creación de colecciones de información hipertextual, mucho más valiosa y usable que la información textual tradicional;
• permite desarrollar un trabajo o cuerpo de conociento orgánicamente, en oposición al tradicional top-down;
• pone énfasis en el contenido por sobre el formato -- es decir, facilita la redacción y estructuración del texto (esto es un título... esto es una lista...) en lugar de fomentar micromanagement de su formato visual (esto va en negrillas y cursivas, con tipo de letra Arial), lo cual agilita el desarrollo del trabajo;
• remueve grandes barreras tecnológicas para la colaboración, con el objetivo de integrar un máximo de colaboradores; y
• facilita enormemente la hipertextualización de un cuerpo de conocimiento existente o en desarrollo.

Evidentemente, MediaWiki es software libre.

Y que, incidentalmente, es la tecnología a través de la cual construimos este trabajo de memoria. Hemos seleccionado y usado MediaWiki, el motor Wiki utilizado para construir los explosivamente exitosos proyectos de la fundación Wikimedia, cuyo proyecto líder es la famosa Wikipedia.

Metodología wiki en este trabajo

Dejemos a los wikis de lado por un momento, y pensemos sobre la metodología que aplicamos a este trabajo. Lógicamente, está íntimamente relacionada con la tecnología wiki:

• Absolutamente todo cuerpo de conocimiento desarrollado integralmente por nosotros y que forma parte de la tesis se encuentra incorporado en el wiki.
• Trabajamos de forma orgánica: cuando se necesita estructura a priori o se puede visualizar fácilmente, comenzamos con un esquema; cuando las ideas aparecen de golpe, redactamos al vuelo, y refactorizamos el contenido a posteriori en el área correspondiente.
• Organizamos la información en artículos discretos relacionados entre sí. Cuando un documento crece en extensión, inmediatamente separamos el documento en documentos compuestos por porciones lógicas del original.
• Existe un historial completo y auditable de todos los cambios, desde el primero hasta el último.
• Las discusiones y desacuerdos se encuentran documentados directamente (inline) en los documentos del wiki, o (en su defecto) en el área de discusión de cada documento (Discussion). Cuando un desacuerdo se resuelve, se elimina del documento en donde aparece (mas no de la página de discusión).
• Las referencias en el wiki están marcadas como hipervínculos intra- o inter-documento, y etiquetadas con un título (que aparece en el glosario impreso). Aparte de ser más usables, los hipervínculos facilitan la navegación y revisión en línea, y les permiten al lector verificar rápidamente la veracidad de nuestro trabajo.

¿Qué ganamos con todo esto? Las siguientes ventajas:

• Auditabilidad: absolutamente todos los cambios se pueden auditar, y la responsabilidad de cada cambio es evidente y transparente. Incluso las eliminaciones pueden ser rápidamente identificadas.
• Transparencia: el mundo entero puede, si se desea, auditar nuestro avance, nuestros errores y aciertos.
• Consistencia: debido al enfasis en la estructura en lugar del formato, no perdemos tiempo en dar formato, puesto que el formato es parte integral de la estructura y responde a ella.
• Evolución rápida: con el wiki encontramos el balance perfecto entre top-down y bottom-up; mucha planificación a priori induce a reorganizaciones grandes a posteriori (refactoring); poca organización induciría al desorden.
• Sincronía: no gastamos tiempo en identificar cuál es la "última versión" de un documento escrito o electrónico, puesto que el versionamiento está completamente integrado en la metodología y la herramienta.
• Un-do: un error leve o grave puede ser deshecho a voluntad.
• Persistencia: la información persistirá y será de extrema utilidad para futuros tesistas y gente de negocios.
• Apertura: la idea del trabajo con un wiki está alineada con nuestra propia filosofía de apertura y con el objetivo de esta tesis (que, a fin de cuentas, es difundir el software libre).

Evidentemente, tanto nuestros métodos como nuestros motivos están 100% incorporados en la herramienta seleccionada. Ahora, estudiemos las características y ventajas de la herramienta que posibilitan y facilitan las nociones antedichas.

Características y ventajas de MediaWiki

MediaWiki es, por falta de mejor palabra, prácticamente fantástico (derivado de una fantasía):

• La creación de una página o unidad de conocimiento es extremadamente sencilla.
• La creación de hipervínculos también es elemental.
• Se pueden crear plantillas, para repetir bloques de hipertexto en varias unidades de conocimiento.
• La reestructuración de los documentos en diferentes secciones es cuestión de cortar y pegar.
• MediaWiki no usa formatos exóticos, propietarios o difíciles de usar, sino wikitexto, una forma especial de texto plano que permite adornar el texto con caracteres normales para obtener determinados estilos; al presentarse este texto, automáticamente se convierte en una página Web. En consecuencia, la velocidad de redacción del texto (rico en formato) está únicamente limitada por la experiencia mecanográfica del redactor.
• El wikitexto facilita la gestión de estilos -- hay prácticamente un mapa 1:1 entre estilos HTML (más que adecuados para documentos de la índole implícita en este trabajo) y expresiones wikitexto. Adiós al

  ¡pero este párrafo está con Arial 12 y el siguiente con Arial 11!

  Con wikitexto, el formato es consistente y representativo del elemento adornado por la expresión de markup.
• Las tablas de contenido para cada sección se generan automáticamente.
• MediaWiki lleva un historial completo de todos los cambios hechos en el sitio, y permite revertir instantáneamente a versiones anteriores de artículos, páginas o secciones, sin ningún tipo de dificultad.
• También se puede comparar visualmente las diferencias entre dos versiones de un mismo documento.
• Es posible listar los cambios (junto con sus resúmenes) hechos en todo el cuerpo de conocimiento (extremadamente útil en combinación con lectores RSS). En consecuencia, es fácil determinar el esfuerzo relativo invertido en el cuerpo de conocimiento.

Pero, ¿hace todo lo que necesitamos?

Como podemos ver, MediaWiki cumple con nuestros requisitos. En consecuencia, fue la herramienta que usamos. Lamentablemente, MediaWiki no incorpora ninguna característica diseñada para generar automáticamente un libro impreso, por lo que había que complementar el proceso con otras tecnologías.

De un wiki a un libro

Procesamiento del contenido de la tesis

Bien. Tenemos toda la información en línea, y la tesis está (casi) lista. ¿Ahora qué hacemos? ¿Copiamos y pegamos el texto de la Web a un procesador de palabras?

¡No, señor! Un ingeniero informático tiene que saber qué hacer para evitar trabajos repetitivos y errores humanos. Una de las grandes virtudes de un buen programador es la pereza: "¿por qué lo voy a hacer yo, si el computador lo puede hacer por mí?"

Y resulta que construir el documento final fue tarea sencilla. Pero, ¿cuál es la magia detrás de esta parte del proceso?

El reto del proceso era responder, en orden, a las siguientes preguntas:

1. ¿Cómo extraemos el texto de cada artículo junto con su estructura?
2. ¿Cómo organizamos los artículos extraídos en un solo documento maestro, de acuerdo a un esquema definido previamente?
3. ¿Cómo especificamos el aspecto visual de cada elemento dentro del documento maestro?
4. ¿Cómo logramos estos retos utilizando software libre, (o, al menos, públicamente disponible y en el marco de la ley)?
5. ¿Cómo hacemos repetible este proceso?

Resulta que:

• la clave del tema es la estructura, porque de la estructura se deriva el formato del documento,
• MediaWiki utiliza XHTML para marcar la estructura del documento. Del simple wikitexto a HTML, todo el trabajo ya está hecho por el motor de MediaWiki,
• los artículos redactados en MediaWiki obedecen a estructuras de jerarquía lógicas:
  • títulos (H1),
  • subtítulos (H2),
  • listas (UL),
  • definiciones (DL),
  • citas (BLOCKQUOTE y CITE),
  • tablas y recuadros
• La jerarquía y estructura del esquema están representadas en la página de inicio de nuestro sitio MediaWiki, y
• casi todas las piezas del rompecabezas ya están disponibles para automatizar el trabajo:
  • el lenguaje XHTML provee la estructura, tanto de los artículos como del documento maestro que llevará el contenido de los artículos
  • el lenguaje CSS2 provee la forma de especificar el formato visual

Así que el resto de la tarea es relativamente sencilla.

MediaBook: de artículos wiki a un solo documento HTML

Para automatizar el proceso, desarrollamos una herramienta de software totalmente original, llamada MediaBook. MediaBook es un minúsculo programa desarrollado usando el lenguaje Python que, a vuelo de pájaro:

• Descarga la página frontal de un wiki MediaWiki, y la convierte a una representación DOM en la memoria del computador.
• En este árbol DOM, busca la tabla de contenido del libro, marcado con un identificador especial. Esta tabla contiene hipervínculos a los artículos que irán en la edición impresa. También identifica el prefacio y otros componentes de la edición impresa que deberán ser integradas.
• Para cada hipervínculo en la tabla de contenido y y demás partes del libro requeridos en la edición impresa, descarga el artículo asociado, convirtiéndolo a una representación DOM y descartando los elementos que no forman parte del contenido del artículo (cabeceras, barras laterales, elementos de navegación Web).
• Inserta cada artículo en la posición que le corresponde en el esquema.
• Descarga las imágenes referidas por los artículos en una carpeta local, y arregla las referencias a las imágenes para que se muestren normalmente sin necesidad de conexión a Internet.
• Para cada hipervínculo interno (es decir, que apunta a un artículo incluido en el libro), dispone la referencia de tal forma que apunte al elemento correspondiente en el documento maestro.
• Hace una serie de procesos adicionales con la representación DOM, y remueve fragmentos innecesarios en la edición impresa.
• Convierte las citaciones marcadas con CITE en notas al pie de página con el URL de la referencia.
• Genera una tabla de contenidos a partir del esquema del documento (los títulos) y sus artículos.
• Genera un glosario a partir de los elementos DFN, ABBR y ACRONYM dispersos en los artículos.
• Genera una lista de referencias a base de las referencias externas expresadas en los hipervínculos.
• Escribe la representación DOM a un archivo HTML local.

El proceso (aumentado por un caché de software incorporado en MediaBook) se demora menos de 15 segundos. Así es, generar una nueva edición del libro, con las últimas correcciones, toma 15 segundos. No está mal, ¿no?

Todo esto sería imposible de no haberse dado el auge de los protocolos y estándares Internet, junto con la Web semántica. MediaBook únicamente se apoya en estándares establecidos libres de regalías para realizar su trabajo.

Para nosotros, MediaBook soluciona la parte difícil y repetitiva del trabajo. Tras concluir este trabajo, MediaBook será publicado bajo la licencia pública GNU GPL, lo cual permitirá que otras personas alrededor del mundo puedan aprovecharlo. Por lo pronto, Ud. puede revisar el listado preliminar del código fuente de MediaBook.

Boom! y CSS2: la estructura y el formato del libro

Una vez estructurado el documento final, resta darle un formato coherente y elegante. La función del formato visual de un documento impreso es entregar al lector pistas visuales para organizar la lectura.

Pero... ¿cómo darle formato a un documento enorme? Un documento HTML sin formato tiene un aspecto, pues, horrible. Tampoco hay consideraciones importantísimas para un libro, como pies de página, cabeceras, notas al pie, capítulos y otros elementos estructurales que se pueden ver en un libro común y corriente.

En la práctica, los documentos HTML (inclusive la edición impresa de este trabajo) se estilan con hojas de estilo CSS2.

div.sidebar {
  float: top-next;
  margin: 1.2em 0 1.2em 0;
  border: thin solid;
  background: #CCC;
  padding: 0.5em 1em;
  page-break-inside: avoid;
  column-count: 2;
  column-gap: 1.5em;
}

Buscamos en Internet cómo editar un libro exclusivamente a base de HTML y CSS2. ¡Y encontramos la respuesta! A List Apart: Printing a Book with CSS: Boom! tenía la solución. Simplemente seguimos las instrucciones propuestas por los autores:

• Reutilizamos (con pequeños cambios y complementos) la hoja de estilo provista por el autor.
• Refactorizamos MediaBook para que generase un documento HTML Boom!, el microformato propuesto por el autor para libros HTML.

Las hojas de estilo CSS2 entregan un poder fantástico al autor. Como ejemplo, basta mencionar que cada hipervínculo interno automáticamente aparece con el número de página en donde se puede encontrar su objetivo, facilitando al lector de la edición impresa seguir la línea de pensamiento que desee, tal y como si hubiera dado clic en un hipervínculo de la edición en línea. También es posible hacer referencia a un capítulo, automáticamente añadiendo el número de capítulo o de página, aunque no hacemos uso de esa característica en este libro. Esta clase de características son posibles gracias a CSS2.

Prince XML: de Boom! a PDF

Utilizamos Prince para generar un archivo PDF (idóneo para la impresión). Prince es un agente de usuario Web muy peculiar: en lugar de mostrar páginas Web en pantalla, genera archivos Adobe PDF. Aunque es menos usable que HTML, el formato PDF es idóneo para la impresión.

Prince es, también, el único agente de usuario que entiende el nivel 3 de CSS, utilizado al máximo por el formato de libros Boom!

Lamentablemente, Prince no es software libre. Sin embargo, la versión de demostración permite la generación de documentos para disertaciones académicas, lo cual se ajusta perfectamente a nuestras necesidades. Nos gustaría ver que la comunidad de software libre acepte el reto de desarrollar una herramienta de software libre como Prince.

Características notables

¿Qué resultados, aparte de los esperados, entrega esta tecnología en particular? Pues casi todos están relacionados con la usabilidad del texto, tanto en la edición en línea como en el libro:

Hipertextualización automática que funciona en el libro

Todo hipervínculo de la edición en línea automáticamente aparece en el libro como una referencia de página.

Si el hipervínculo apunta a una dirección Web que no está transcluida en el texto, el libro presenta una nota al pie con la dirección Internet.

Como bono adicional, el archivo PDF (generado expresamente para la impresión del libro) también gana hipervínculos. Si usted está leyendo el PDF, y ve una referencia de página, puede hacer clic en ella y la página en cuestión se mostrará inmediatamente. El resto de hipervínculos también funciona normalmente.

Glosario automático

Toda abreviación, acrónimo o definición en la edición en línea automáticamente aparece en el glosario del libro, y se distingue visualmente del resto del texto.

Sólo es necesario marcar y explicar los términos con el elemento HTML correcto:

• DFN
• ABBR
• ACRONYM

En la misma etiqueta (usando el atributo title) va la definición del término. Subsiguientes repeticiones del mismo término no necesitan repetir la definición, siempre y cuando hayan sido marcadas con la etiqueta que les corresponde.

Lista de referencias (bibliografía) automática

Todo hipervínculo que haya sido marcado con la etiqueta CITE automáticamente aparece en la bibliografía del libro y como una nota al pie en la página.

En la misma etiqueta (usando el atributo title) va la definición de la referencia bibliográfica; normalmente el nombre de la definición se escribe en formato APA -- pero nosotros usamos exclusivamente referencias en línea, así que escogimos una representación simplificada (apellido, nombre. Título del texto.).

Subsiguientes repeticiones de la misma referencia no necesitan repetir la definición, siempre y cuando hayan sido marcadas con la etiqueta CITE. Sin embargo, igual generan notas al pie con el nombre de la referencia correcto.

En conclusión

Hemos logrado lo que hace unos cuantos meses parecía una barrera insuperable: hacer nuestra tesis de forma enteramente congruente con la filosofía del software libre. En el camino, inventamos un proceso nuevo que, a nuestro juicio, es superior. También desarrollamos una herramienta de software totalmente original.

Este proceso es, sin embargo, mejorable:

1. Una de sus limitaciones es que es específico al dominio del problema (la creación de un libro tradicional impreso).
2. Otra limitación es que requiere una herramienta particular de software (MediaWiki), que no necesariamente resulte útil para otros.
3. La tercera es que, en teoría, debimos haber usado DocBook en lugar de HTML y un microformato. Pero escribir markup DocBook es definitivamente mucho más complicado que usar un wiki y generar HTML y Boom!.

En todo caso, como este proceso se constituyó casi enteramente a base de software libre, las generaciones futuras pueden mejorar el proceso sin depender de un tercero.

No hemos inventado nada nuevo, realmente. Si acaso, una de nuestras contribuciones es haber inventado un nuevo uso para un wiki: la creación de libros impresos de forma colaborativa. Lo único que hicimos, para lograr este cometido, fue darle un uso innovador a la intersección particular de tecnologías que aplicamos.

En el proceso:

• ganamos mucho tiempo, al cosechar las ventajas inherentes de trabajar con wikis,
• cortamos todo tipo de errores humanos en la cadena de procesos, desde la generación de conocimiento hasta la postproducción del libro,
• generamos un sitio Web que servirá enormemente a muchos internautas,
• inventamos un proceso repetible, embotellado en el producto de software MediaBook, para habilitar la creación colaborativa de libros tradicionales de papel a base de wikis, y
• entregamos MediaBook al mundo, una minúscula contribución que no le hace justicia al portentoso volumen de esfuerzos y tecnologías de la información que hicieron posible el desarrollo de MediaBook.

Esperamos sinceramente que nuestra metodología de trabajo basada en wikis y herramientas colaborativas de software libre se convierta en la norma, en lugar de ser la excepción. Estamos seguros, también, de que, después de haber leído esta corta sección, Ud. también estará convencido de lo mismo.