Desde el año 1999, MSA - Magic Software Argentina, la empresa donde trabajé hasta mediados del 2007, fue seleccionada para llevar a cabo varios procesos electorales en diferentes provincias y localidades de la República Argentina. Recientemente algunos de estos proyectos incluyeron alguna forma de voto electrónico, pero generalmente se trata de hacer el recuento de votos del escrutinio provisorio.
Desde la primer elección en que la empresa fue seleccionada, fui parte del equipo de diseño y desarrollo del sistema. Inicialmente el sistema estaba basado 100% en tecnologías privativas. El 20 de Mayo de 2007 hicimos el primer sistema de recuento de votos basado totalmente en software libre para las elecciones provinciales de la provincia de Río Negro, usando Ubuntu como distribución de Linux, y Python como lenguaje de programación.
Introducción al problema
El escrutinio provisorio es el que se hace rápidamente tomando en cuenta los datos que registran los presidentes de mesas en un formulario determinado. Éstos son los datos oficiales que generalmente están disponibles a la medianoche del día de las elecciones, y los que vamos a consultar en todos los medios de prensa al día siguiente.
Para el escrutinio definitivo, el juzgado electoral resuelve algunos votos que no fueron tomados en cuenta en el escrutinio provisorio como los votos recurridos e impugnados, y determinan si son o no votos válidos. Como este proceso puede tardar varias semanas, es de suma importancia obtener el resultado del recuento provisorio lo antes posible para dar transparencia al acto electoral. A menos que la elección haya sido muy pareja entre dos o más candidatos, no hay diferencias entre el escrutinio provisorio y el definitivo ya que los porcentajes de votos recurridos e impugnados son muy bajos, y generalmente no deciden ninguna elección.
En base a los requerimientos implícitos del recuento provisorio (velocidad y confiabilidad) el sistema que se encargue de tomar la información generada por los presidentes de mesa y genere los reportes «minuto a minuto» que van a ser consultados públicamente debe ser extremadamente confiable, estar diseñado como para permitir resolver cualquier contingencia (desde cortes de luz, hasta daños en el hardware) en menos de media hora, y como si todo esto fuera poco, tiene que ser lo suficientemente rápido como para procesar más del 80% de las mesas antes de la medianoche.
Conociendo al pingüino
El primer proceso electoral que hicimos fue basado completamente en herramientas y software privativo. Todas las máquinas corrían el sistema operativo de Microsoft (no recuerdo las versiones), el lenguaje de programación era Magic (una herramienta de desarrollo post 4GL) y los reportes (html) eran generados en lotes que luego eran subidos al sitio web de publicación de resultados.
En esa época estaba dando mis primeros pasos en el mundo de GNU/Linux, y aunque ya había utilizado sistemas AIX y SCO, no tenía el conocimiento ni la confianza como para proponer el uso de herramientas de software libre.
Rápidamente fui aprendiendo a relacionarme con el pingüino, en gran parte gracias a la comunidad de LUGAr y su maravillosa lista de correos. Gracias a toda la gente que participa de la lista aprendí mucho, primero haciendo preguntas, luego respondiendo las preguntas que estaban al nivel de mis conocimientos.
Desde el año 2000, Linux empezó a acompañarnos en los procesos electorales. Su primer colaboración fue trabajar como generador de gráficos para los reportes de resultados. Inicialmente habíamos seleccionado una herramienta que corría sobre Windows, pero la performance no era aceptable. Las bases de datos (Oracle) corrían sobre Compaq/Tru64, así que buscamos alguna herramienta de código abierto que cumpla con los requerimientos y encontramos a ploticus que desde ese momento siempre nos acompaño. La idea era compilar ploticus para que corra sobre Tru64, ya que Linux no estaba visto como algo confiable por los «no-técnicos». Por problemas de librerías y compiladores, no pudimos hacer compilar el programa para que corra en esa plataforma, así que directamente nos llevamos nuestra máquina de pruebas en Linux, y esa fue la entrada en escena del pingüino. Se realizó el proceso sin problemas, y quedó comprobado que podíamos confiar en Linux para procesos importantes.
En procesos posteriores, fuimos incorporando gradualmente más Linux y software libre dentro del sistema. Configuramos nuestros propios servidores web (Apache), hicimos la generación de reportes con PHP, las bases de datos Oracle fueron instaladas sobre RedHat, de a poco íbamos ganando conocimiento (y confianza) en la utilización de herramientas libres.
Muchas veces la selección de las herramientas libres estaba limitada a las herramientas no libres que también formaban parte del sistema. Generalmente usábamos Red Hat como distribución ya que Oracle sólo brindaba soporte para esa distribución, para el módulo de ingreso de datos seguíamos utilizando Magic sobre Windows.
Al final, Ubuntu y Python
En el año 2006 hicimos una experiencia con voto electrónico para la Municipalidad de Rosario. Ese fue un punto de inflexión ya que utilizamos por primera vez un ambiente de desarrollo abierto para desarrollar las interfases de usuario. La solución utilizada se basaba en LiveCDs de Ubuntu modificados para contener el software de voto que usaban los electores. Dado que Magic no tiene un cliente GUI para Linux, decidimos utilizar Python + Gtk.
La combinación funcionó a la perfección, y nos sirvió para sentar precedentes que no solo las distribuciones comerciales son estables y confiables. Ubuntu corriendo desde un LiveCD fue sumamente confiable, y sólo tuvimos problemas con los módulos de un touch screen cuyo fabricante sólo nos facilitó una versión beta de los mismos.
Por otro lado comprobamos que Python es un lenguaje de programación extremadamente poderoso. Sin la velocidad de programación que brinda Python, no hubiéramos tenido tiempo de hacer un módulo especialmente diseñado para que puedan votar las personas con capacidades de visión disminuidas, utilizando 'festival' para que asista al elector durante el proceso de emisión del voto (gracias a Marcelo Fernández)
En base a la experiencia recogida en la ciudad de Rosario, para el proceso de recuento provisorio de las elecciones de Río Negro, el 20 de Mayo de 2007, queríamos utilizar la misma plataforma (Ubuntu + Python) pero se imponía el problema de que Oracle sólo brinda soporte si se ejecuta sobre Red Hat Enterprise Linux.
Para el sistema de reportes y el sistema de carga de datos, ya habíamos seleccionado Ubuntu como plataforma, dado que es la distribución que usamos para trabajar diariamente. Si todo el software era desarrollado y probado en una plataforma, no era muy convincente cambiar de distribución par el día del proceso. La base de datos podría haber corrido sobre un RHEL, pero necesitábamos que los dos servidores principales puedan cumplir con las funciones del otro en caso de una caída inesperada. Tener un RHEL por un lado y un Ubuntu por el otro no nos permitía estar totalmente seguros que la aplicación se comporte igual, y si había que levantar el Oracle en Ubuntu, no íbamos a tener soporte.
Dado que los tiempos estaban muy ajustados, no podíamos hacer pruebas de compatibilidad de la aplicación en diferentes distribuciones, con diferentes librerías y versiones de programas. Entonces se tomó la decisión que tanto tiempo tardamos en tomar. Dado que Oracle no soporta Ubuntu, y necesitamos Ubuntu en los dos servidores principales, seleccionamos a PostgreSQL como base de datos.
Luego de un par de pruebas rápidas, quedamos totalmente convencidos que era lo que necesitábamos. La instalación fue más simple de lo que pensábamos: un simple apt-get install. Para la configuración no tuvimos que tocar demasiados parámetros ya que el volumen de datos no era demasiado grande. Lo importante era que los inserts y las consultas sean rápidos, y consistentes.
Para la parte de carga de datos, teníamos que instalar la aplicación en doce máquinas alquiladas para la ocasión. Si bien nos permitían hacer una instalación e instalar Ubuntu en todas las máquinas, hacer esto nos hubiera llevado un par de horas largas. Para resolver el problema, configuramos un LTSP sobre Ubuntu, y utilizamos las máquinas como clientes delgados. En consecuencia la instalación de la aplicación sólo se hizo en una máquina, y el resto fue arrancar las máquinas desde la red.
Descripción de la solución utilizada
El funcionamiento del sistema es, en forma sintética, el siguiente:
- Luego de hacer el recuento manual de votos, el presidente de mesa llena un formulario con los resultados del recuento para esa mesa.
- Los formularios son enviados físicamente al juez de paz más cercano.
- Los jueces de paz son los responsables de transmitir los formularios por fax al centro de cómputos de la ciudad de Viedma.
- Tres equipos Cisco reciben los faxes y los envían a un servidor de correos dentro de la red local.
- Un proceso en python se encarga de desempaquetar las imágenes y procesarlas para que puedan ser utilizadas en el resto del circuito.
- Mediante una aplicación GUI, varios operadores confirman que los faxes recibidos sean verídicos, legibles, etc.
- Las imágenes aprobadas son transmitidas a través de una VPN al centro de computo de Buenos Aires.
- Los dataentries ven las imágenes en un programa que muestra la imagen y los campos para ingresar los votos.
- Las imágenes son cargadas por dos personas distintas, si los datos de las dos cargas no coinciden, se resuelve la incidencia en la ciudad de Viedma mediante un sistema de carga web (apache + mod_python) que sólo es accesible mediante la VPN.
- Las planillas que fueron cargadas correctamente son publicadas en el sitio web de reportes públicos (apache + python).
En la ciudad de Viedma, se utilizaron las siguientes herramientas:
- Ubuntu 7.04 (mailserver, aprobación de faxes)
- postfix
- Python + Imagemagick (proceso de imagenes)
- Python + pygtk + glade
En la ciudad de Buenos Aires:
- Ubuntu 6.10 (servidor de base de datos, servidor web, servidor LTSP)
- PostgreSQL 8.1
- Python + pygtk + glade (programa de carga de datos)
- Apache 2.2 + mod_python (consulta de estado de proceso y resolución de incidencias)
- Apache 2.2 + python (cgi de generación de reportes públicos)
- ploticus (generación de gráficos para los reportes)
Pueden ver algunas imágenes desde este enlace.
Conclusión
Generalmente se piensa que las herramientas de software libre mantenidas por la comunidad no son 100% confiables en aplicaciones de misión crítica, y se termina recurriendo a distribuciones comerciales, bases de datos propietarias, etc. Durante el desarrollo de este proceso, no sólo pudimos comprobar que esta visión es errónea, sino que en algunos casos se incrementa la productividad.
Usar Ubuntu como única distribución nos facilitó muchísimo la instalación y configuración de los múltiples servidores que participaron del proceso. El sistema de paquetes apt-get (y sus derivados) son una ayuda invaluable, y en los repositorios pudimos encontrar todas las herramientas que necesitamos. No necesitamos bajar programas o librerías de sitios no oficiales, y no fue necesario (re)compilar ni un sólo programa.
En cuanto a la programación, Python nos brindó todo lo que necesitamos, y al momento de necesitar instalar algunas librerías en particular, siempre las encontramos en los repositorios de Ubuntu. Python, al ser tan potente y rápido para el desarrollo, nos permitió desarrollar el sistema completo solamente entre dos personas (Marcelo y yo). Cuando usábamos otras herramientas de desarrollo nunca fuimos menos de cuatro desarrolladores.
En definitiva, las herramientas libres mantenidas por la comunidad, por lo menos las utilizadas en este proyecto, son totalmente confiables en aplicaciones de misión crítica como el caso presentado. Si son confiables para este tipo de procesos tan delicados, ¿por qué no usarlas en su empresa? ;)
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License.
