eXe

24 de enero de 2010

No vamos a describir aquí lo que es eXe-Learning (eXe para los amigos), una herramienta bien documentada en la red, en castellano también. Me limitaré a decir que viene a ser una herramienta de autor que permite generar diferentes clases de páginas web y actividades: texto html, introducciones a un tema, ejercicios en distintas modalidades, secciones «Para saber más»... es decir, una especie de editor html wysiwyg con plantillas pensadas para la creación de materiales. Que permite generar una estructura de páginas clasificadas en secciones, etc. y un índice automático. Y con la gran ventaja de que una de las formas de exportación es como las versiones de paquetes IMS y SCORM que acepta moodle sin rechistar.

Esa es la razón de su éxito: eXe está siendo usada masivamente en los CEPs, CPRs, CEFIREs y demás nombres de la rosa para la creación de cursos (sin ir más lejos se usa por indicación mía en un curso que coordino en estos momentos). Es también la herramienta principal en la creación de materiales de la Secundaria para adultos y del Bachillerato a distancia andaluces.

¿Pero?

Ahora los problemas. eXe es el producto final del Fondo eCollaboration de la Comisión para la Educación post-obligatoria del Gobierno de Nueva Zelanda. Aunque posteriormente recibió apoyo de la organización educativa sin ánimo de lucro CORE Education, no hay más que echar un breve vistazo a las fechas del repositorio de código para darse cuenta de que los cambios desde la publicación de la versión 1.04 hace 14 meses han sido mínimos y puntuales. Acabado el dinero, se acabó el trabajo. La última actualización de ficheros en la forja de Eduforge es de mayo de 2008. La última entrada en su bitácora es de febrero de 2008. El número de personas que ponen tickets y hacen aportaciones es mayor que 0 y menor que 2: se llama Jim Tittsler.

Mi experiencia con eXe es la de usar una herramienta funcional y útil, pero a falta de un acabado. Como suele suceder con las aplicaciones que son producto de un encargo con fecha y fondos. Traducciones, iDevices, fallos diversos. No debo ser el único que tiene esa impresión. «En el ITE estamos tratando de complementar y ampliar las funcionalidades de Exe Learning (temas de accesibilidad de las página que genera la aplicación y de importación de determinados formatos de archivos)» (correo de 3 de diciembre de 2009); al parecer se habló de ello en la charla de Ismail Alí en la Conferencia de Software Libre de Cáceres (necesitaría en este punto referencias, porque no pude asistir). Suena tranquilizador.

Desde el Servicio de Educación Permanente andaluz Juan Diego Pérez Jiménez, pekechis, ha trabajado sobre algunos problemas. Tuitea el 5 de octubre de 2009 (editado para recuperar el enlace largo):

nuevo videotutorial, solución a los problemas de eXeLearning con Firefox 3.5 
http://www.youtube.com/watch?v=eJIwHGnFfSI

Han desarrollado además un estilo propio, kyoiku (educación en japonés), que completa las traducciones y crea/adapta los iDevices a la estructura y necesidades de la formación a distancia que imparten. Para estar al día de las actualizaciones de este estilo, siga la sección de Documentos de BTOAD.

Si todo quedara ahí las cosas irían bien. Sería cuestión de coordinar y compartir recursos, proceso que como vemos ya se ha iniciado.

Pero

No sé si se han preguntado ustedes porqué, si eXe-Learning está incluida en las distribuciones derivadas, Guadalinex-edu o MAX por ejemplo, no ha estado nunca ni está en Debian o Ubuntu. Las distribuciones educativas autonómicas utilizan el paquete para Ubuntu Feisty creado por Jim Tittsler. Feisty era la 7.04, traducido, la Ubuntu de abril de 2007. ¿Cuál es el problema? ¿y por qué no llega a las distros madres?

Tengo el paquete delante: python2.5-exe_1.04.0.3532-ubuntu1_i386.deb, 17.491 K. El nombre da una pista: se trata de una aplicación escrita en python, que extiende las funcionalidades del navegador firefox del usuario. Espera en el puerto 51235 y cuando el usuario se conecta a él le devuelve el editor de páginas.

Momento pedagógico: ningún programa lo hace todo solo. Todos reutilizan funciones escritas por otros, que suelen reunirse en colecciones llamadas bibliotecas (libraries en inglés). Ese es el origen de las dependencias de un paquete: un programa no funciona si no están instaladas las bibliotecas que utiliza. Incluso se depende de versiones concretas de las bibliotecas, porque se han introducido funciones nuevas, o se han hecho cambios significativos. Lo habitual y correcto en un sistema como Debian o Ubuntu es que el instalador instale también los paquetes de los que se depende, si no causan ningún conflicto. Python2.5-exe depende de python-zopeinterface (>= 3.0.0-6) y de python-imaging. ¿Y por qué no depende de python, si sin su presencia no funcionaría? Porque ya dependen de él python-zopeinterface y python-imaging. ¿Y de firefox? Porque se le ha pasado a Jim. Total, depende de python-zopeinterface y python-imaging. Sólo. ¿Sólo?

La sección CREDITS de /usr/share/exe/README, la nota legal del programa, pretende recoger las licencias de las bibliotecas utilizadas y/o incluidas. Vemos que se menciona «The Python Imaging Library (PIL)», como era de esperar. Pero también  (extraigo las referencias) «CTC for APIWrapper.js and SCOFunctions.js,  Mozilla for XUL and the XPFE, Fabricio Zuardi for XSPF Web Music Player mp3 player, Anssi Piirainen for FlowPlayer FLV video player, John Forkosh Associates, Inc. for mimeTeX, Mark Pilgrim for Universal Feed Parser, Beautiful Soup is Copyright (c) Leonard Richardson, GeoGebra is Copyright Geogebra Inc., Twisted Python 2.2.0, Nevow 0.4.1». ¿Qué está pasando aquí? En pocas palabras, que el paquete no llama a la mayoría de las bibliotecas de las que depende, sino que incluye copias de las bibliotecas, en las versiones que necesita. La falta incluir su propia versión del navegador, exactamente la solución que proponía pekechis arriba.

Esto es cómodo para el empaquetador, pero la forma segura de que acabaremos encontrando problemas. El sistema de dependencias de Debian funciona muy bien. Es absurdo que cada programa incluya su copia de java, python o tomcat, como estamos hartos de ver. Esto no es Windows. El 23 de septiembre de 2009 tuve una charla con mi desarrollador Debian de referencia (sorry, sin nombres, fue una charla privada). Me contó que había intentado meterle mano a eXe para crear un paquete correcto. Transcribo:

Intenté empaquetarlo para Debian, pero: 
a) es infumable el fuente, mezcla librerías propietarias y ejecutables 
descargados de internet, y 
b) contacté con los autores y me dijeron que habían dejado el desarrollo 
hace 2 años (...)
ya te digo que tiene mezclado: archivos swf (sin fuente, por supuesto) 
con ejecutables y rutas malas, etc. (...)
es que además, en lo que usa software libre, usa versiones antiguas, 
pero no como dependencias, meten el ejecutable a capón dentro, por ejemplo 
nevow o TinyMCE, con versiones de python metidas (...)

No sé si logro precisar el problema: no es que el paquete no esté bien hecho, es que no puede estarlo sin cambios en las fuentes. Cuál es el problema, preguntábamos arriba. No disponer de las fuentes de algunas aplicaciones incluidas es el primero: no podemos garantizar que podremos arreglarlas para que funcionen en versiones futuras. A la velocidad con que evoluciona el software este argumento es devastador para una aplicación: su utilización se convierte en una trampa de recursos cautivos.

El segundo es su uso de versiones de las bibliotecas diferentes, quizás incompatibles con las del sistema. Lo hemos visto: twisted, nevow y tinymce están empaquetados para Debian/Ubuntu (python-twisted, python-nevow, tinymce). Ocurre incluso para las dos dependencias reconocidas en el paquete de Tittsler: en Ubuntu 9.10 la versión 2.5 de python tiene que ser instalada a mano por el usuario porque la versión del sistema es la 2.6. Y en Debian Testing o Inestable eXe no puede ser instalado porque python-zopeinterface 3.4.0-1 ha sido sustituido por python-zope.interface 3.5.3-1. ¿Por qué lo hace Tittsler? Porque no quiere o no puede modificar las llamadas para que funcionen correctamente con las nuevas versiones. Porque no está manteniendo la aplicación.

En cuatro palabras: la aplicación está abandonada. Por cierto, el análisis aplicado a la versión GNU Linux es aplicable 100% a las versiones para otros sistemas operativos. Es python.

Conclusión

El software libre, aunque algunos no lo crean, no cae del cielo como el maná (cuando me presenten al traductor que vertió free por gratis va a tener unas palabritas conmigo). El software que puede descargarse gratuitamente en una distribución ya ha sido pagado. Según un modelo de negocio que no consiste en pretender cobrar por copias de algo que ya se ha cobrado. Y mis contribuciones gratuitas, mis traducciones, mis charlas, son devoluciones y la forma de entrar en un sistema de intercambios (ya lo escribimos, bien o mal, en la entrada El regalo). ¿A qué viene esto? A que les corresponde a los responsables de las distribuciones educativas autonómicas superar la fase de cazadores-recolectores, hacer algo más que seleccionar el software disponible.

Señores y señoras responsables de las distribuciones: las mejoras que necesita eXe-Learning no son estéticas. Y creo que estamos de acuerdo en que la aplicación es de importancia estratégica para el desarrollo de materiales. Propongo y ruego que se asignen recursos de forma coordinada. Insisto: el software libre no es una clase de maná, hay que sembrar para recoger.

Todos lo vamos a agradecer.

Actualizaciones

27 de febrero de 2010

Novedades. Entre los paquetes de  http://sourceforge.net/projects/exe/files/ ha aparecido una revisión (build) 3598 que soluciona dos problemas de la versión para Ubuntu:

  • depende ahora de que python apunte a python2.6 (como ocurre por ejemplo en Ubuntu 9.10) y
  • hace opcional la dependencia de python-zopeinterface: ahora se depende de python-zopeinterface (>= 3.0.0-6) ó de python-zope.interface (biblioteca que reemplaza a la anterior)

Comprobado que se instala sin problemas y que la aplicación funciona en Ubuntu 9.10. Esta build 3598 no vale para Debian Testing mientras en Debian python siga apuntando a python2.5.

Nueva entrada en su bitácora desde hace dos años: los foros se han movido a http://sourceforge.net/projects/exe/support y parecen tener un tímido movimiento. ¿Habrá renacido eXe de sus cenizas?

6 de marzo de 2010

Buenas noticias. La solución del problema en Ubuntu facilitaba la solución para Debian Testing, pero había que dar con ella. El mismo Jim Tittsler (correo personal) me ha dado las claves.

Recordemos la situación: en Ubuntu python apunta a python2.6, pero en Debian apunta a python2.5. El paquete para Ubuntu del que hablábamos el 27 de febrero no funciona en Debian Testing. Segundo: el arreglo que vamos a proponer ahora es una dirty hack; si tenéis amigos desarrolladores Debian ni mentárselo.

Basta regenerar el paquete (instrucciones de Jim):

svn co https://exe.svn.sourceforge.net/svnroot/exe exe
cd exe/installs/debian/ubuntu
python make.py

Cuando generes e instales el paquete ya puedes actualizar python-zopeinterface y twisted. He comprobado que todo funciona. ¡Al fin!