Nota: Este artículo lo comencé a trabajar para publicarlo como parte del trabajo del Seminario Construcción Colaborativa del Conocimiento. Al ver que era pertinente e indicado para su inclusión en mi columna para la revista SoftwareGurú, lo utilicé ahí también — Pero tuve que reducirlo a menos de la mitad de su extensión original. Aquí lo presento completo, en una versión muy similar a la que será publicada como resultado del Seminario, refiriendo hacia aquí a los lectores interesados de la revista. Como archivos adjuntos (al final) encontrarán también la versión de SoftwareGurú.

Voto electrónico

La postura que ante las votaciones electrónicas han tomado diversos grupos relacionados con la creación y escrutinio de software y de procesos sociales ilustra muy bien varios de los puntos delineados en otros capítulos de la presente obra. Este capítulo formaba parte originalmente del capítulo «Software Libre y Construcción Democrática de la Sociedad», e ilustra uno de los puntos y de las maneras en que las comunidades de creación de conocimiento tanto de seguridad en cómputo como de Software Libre han abordado un punto de gran importancia para la vida en sociedades democráticas actuales, insertándose en el entorno político imperante. Hemos decidido, tanto por la extensión como por la relación de este tema con varios otros de los presentados en esta obra, hacer del presente apartado un capítulo independiente.
Los promotores de las diferentes vertientes del Conocimiento Libre son los primeros en recalcar los tremendos fallos –conceptuales y de implementación– que hacen que las estaciones computarizadas de emisión y contabilización de votos sean, desde su planteamiento, una causa perdida [1] — Ninguna de las numerosas implementaciones a la fecha han salido airosas ante el escrutinio (incluso casual) de expertos en seguridad [2], a veces con resultados verdaderamente nefastos [3], [4]. Los escrutinios generalmente han sido dirigidos por grupos de activistas independientes buscando señalar las deficiencias del proceso, con la muy notable excepción del ejemplo puesto por el Tribunal Superior Electoral de Brasil, al cual abordaremos más adelante.
Obviamente, estos resultados no son del agrado de las compañías que buscan vender máquinas supuestamente seguras, diseñadas ex-profeso para el conteo de votos. Se han dado a conocer incluso amenazas hechas contra dichos equipos de investigadores [5] por desarrollar estos trabajos. En este caso, la demanda es que, en asuntos tan sensibles, relevantes e intervenibles como la vida democrática, es sencillamente imposible asegurar los elementos básicos de confiabilidad y auditabilidad.
Diversos argumentos han sido esgrimidos a favor del voto electrónico, pero pueden ser resumidos en tres:

• Disminución de costos: Un adecuado proceso democrático es caro. La papelería electoral debe ser impresa con mecanismos suficientes para asegurar su unicidad, deben proveerse mecanismos para garantizar que sólo los electores autorizados emitan su voto, y debe haber garantías de no manipulación para todos los componentes involucrados en el proceso. La automatización del proceso ayuda a implementar estos candados a un menor costo.
• Agilidad en la obtención de resultados: No hay nada que genere mayor falta de confianza y suspicacia en los procesos que una demora en la publicación de los resultados. Se ha argumentado que a través del voto electrónico, los resultados pueden ser anunciados prácticamente de inmediato tras haberse cerrado la casilla.
• Confiabilidad de los actores: La experiencia de muchos países en torno a los fraudes electorales apunta dolorosamente a la falta de integridad de los actores involucrados en el proceso — Personas susceptibles ya sea a la compra de concienicas, a la extorsión, o directamente a la violencia física; si todo el proceso es controlado por computadoras, éstos factores deberían perder peso.

En las siguientes secciones analizamos por qué los tres argumentos caen por su propio peso.

Agilidad en la obtención de resultados

Una de las principales obsesiones de la sociedad actual es la velocidad del acceso a la información. Los medios electrónicos de comunicación y el uso de Internet nos han acostumbrado a que la información debe estar disponible tan pronto ocurren los hechos, y debe llegar a toda la sociedad tan pronto está disponible.
Los sistemas electorales en general estipulan que, para no manipular los resultados de una elección en proceso, no deben darse a conocer sus resultados parciales hasta que haya cerrado la última de las urnas – No hacerlo de esta manera significaría que la tendencia influiría en los resultados de muchas maneras indeseables. Sin embargo, una vez que cierra ésta última urna, en la mayor parte de las democracias modernas hay un periodo típicamente de un par de horas en que es necesario esperar a que las autoridades electorales recopilen la información generada por típicamente decenas de miles de casillas y den a conocer el resultado. Hay una gran presión por parte de los ciudadanos, y muy especialmente de los medios, para que las autoridades electorales publiquen los resultados de inmediato. Además del apetito por la información expedita, ésto viene fundamentado en ejemplos de ocultamientos de información que eran realizados conforme los números comenzaban a fluir — Ejemplo de esto son las declaraciones que hizo veinte años más tarde Manuel Bartlett Díaz, quien fuera en 1988 Secretario de Gobernación y presidente de la Comisión Federal Electoral durante las muy cuestionadas elecciones presidenciales de 1988 [6]: La decisión de no dar a conocer datos preliminares fue tomada por el presidente Miguel de la Madrid, dado que, cito: si se oficializaba en ese momento –con datos parciales– que Cárdenas Solórzano iba ganando, al final nadie aceptaría un resultado distinto.
En la experiencia mexicana, la situación ha cambiado radicalmente de la imperante hace tan sólo dos décadas, como claro resulado de las frecuentes acusaciones de fraude electoral que nuestro sistema electoral ha sufrido — En vez de una demora cercana a una semana, el Instituto Federal Electoral y las autoridades correspondientes de cada uno de las entidades federativas publican los resultados de las encuestas de salida y los conteos rápidos típicamente dentro de las dos primeras horas tras haber concluído la votación, siempre que haya suficiente márgen estadístico para no causar confusión en la población.
Impulsar una solución con tantos riesgos como una urna electrónica para ganar como tope estas dos horas sencillamente no tiene sentido. Además, el tiempo invertido por los funcionarios electorales en cada casilla en el conteo de votos emitidos es sólo una fracción del dedicado a las tareas de verificación y protocolización que deben llevarse a cabo antes de declarar concluída una elección. Sumando ésto a que –por consideraciones de seguridad– las estaciones de voto no están pensadas para contar con conectividad a red (y que ni los países más industrializados cuentan con una cobertura de Internet del 100% de su territorio), por lo cual debe haber forzosamente un paso manual de comunicación de resultados al centro de control de la autoridad electoral, el argumento de reducción de tiempos queda descartado.
Federico Heinz cierra su texto «¿El voto electrónico mejora la democracia?» [7] con la siguiente idea:

Una alternativa factible es realizar la votación mediante formularios que contengan a todos los partidos, dejar que los votantes marquen su elección con tinta, y usar un scanner óptico para hacer un escrutinio automático, verificable mediante un simple recuento manual. No hay nada en contra de un escrutinio electrónico, pero digitalizar el acto mismo de la emisión del voto es extremadamente peligroso para la democracia.

El uso de boletas a papel y tinta aptas para ser scanneadas por equipo de reconocimiento óptico puede ser la opción más adecuada en este sentido. Permite la verificación de cientos de boletas en apenas un par de minutos, y permite conservar todos los atributos positivos del sistema tradicional.

Confiabilidad de los actores

Algunos proponentes del voto electrónico mencionan que con el voto tradicional en papel todos estos fraudes siempre han existidohttp://seminario.edusol.info/resena/beatriz-ramirez/2009/03-1 (requiere registro)" href="#footnote1_zcki0ri">1, y que éste no agrava los riesgos — Sin embargo, más que reducir las posibilidades de los agentes fraudulentos, al implementar el voto electrónico estaríamos aumentando la profundidad a la que podrían llegar, e imposibilitando cualquier acción de auditoría o rendición de cuentas.
La votación electrónica tiene muchas modalidades y muchas aristas. En líneas generales, y contrario a lo que muchos esperarían, los expertos en seguridad informática y los activistas sociales involucrados en esta lucha no recomiendan exigir que las urnas electrónicas estén basadas en Software Libre para su funcionamiento, sino que sencillamente recomiendan en contra de su utilización. Citando a Heinz, [7]:

El mecanismo de auditar completamente el funcionamiento de las urnas es impracticable. Esta es una tarea que sólo podría ser ejecutada por una elite de especialistas, de los que hay muy pocos en el mundo, y requiere la cooperación de las empresas que proveen las urnas así como de todos sus proveedores. Y aún si consiguiéramos todo eso, la eficacia de una auditoría sería más que dudosa: no sólo debemos garantizar que todo el software es correcto (lo que es imposible), sino que además debemos verificar que el software presente en las urnas el día de la elección es idéntico al auditado, tarea que nuevamente requiere de especialistas. ¿Y por qué hemos de confiar en los especialistas, si no queremos confiar en sacerdotes ni en empresas? Una de las muchas virtudes del "anticuado" sistema de escrutino tradicional es que cualquier persona que sepa leer, escribir y hacer operaciones de aritmética elemental está en condiciones de controlarlo. Esta es una característica esencial y no debemos renunciar a ella.

Uno de los más interesantes argumentos que ilustran por qué las urnas electrónicas carecen inherentemente de confiabilidad es el presentado —sin aplicarlo en éste ramo específico— por Ken Thompson en 1983 [8], en su discurso al recibir el Premio Turing de la ACM2. Thompson hace una sencilla demostración de por qué un sistema que llega al usuario final (y esto es mucho más cierto hoy en día que en 1983, en que los lenguajes y marcos de desarrollo utilizados suben increíblemente en la escala de la abstracción comparado con lo existente entonces) es prácticamente imposible de auditar por completo un programa, ni siquiera teniendo su código fuente, ni siquiera teniendo el código fuente del compilador. Traduciendo de las conclusiones de Thompson:

La moraleja es obvia. No puedes confiar en el código que no creaste tú mismo. (Especialmente código proveniente de compañías que emplean a gente como yo). No hay un nivel suficiente de verificación o escrutinio de código fuente que te proteja de utilizar código no confiable. En el proceso de demostrar la posibilidad de este tipo de ataque, elegí al compilador de C. Podría haber elegido a cualquier programa que manipule a otros programas, como al ensamblador, cargador, o incluso microcódigo embebido en el hardware. Conforme el nivel de programación se vuelve más bajo, éstos fallos se volverán más y más difíciles de detectar. Esta vulnerabilidad bien instalada en microcódigo será prácticamente imposible de detectar.

Éste argumento ha sido clave para llegar a conclusiones como la adoptada en marzo del 2009 por la Corte Suprema de Alemania [9],[10]:

Un procedimiento electoral en el que el elector no puede verificar de manera confiable si su voto fue registrado sin falsificación e incluido en el cálculo del resultado de la elección, así como comprender cabalmente de qué manera los votos totales emitidos son asignados y contados, excluye del control público a componentes centrales de la elección, y por lo tanto no alcanza a satisfacer las exigencias constitucionales.

El punto de la confiabilidad es el que más fervientemente se sigue debatiendo. El caso brasileño resulta muy esperanzador: A diferencia de la mayor parte de los gobiernos de países supuestamente desarrollados, en Brasil la tecnología utilizada para el voto electrónico está completamente basada en tecnología desarrollada localmente, empleando software libre. En noviembre del 2009, el Tribunal Superior Electoral brasileño convocó a la comunidad de seguridad a encontrar vulnerabilidades sobre las estaciones receptoras de votos, a cambio de una recompensa económica para los mejores análisis[11]. Dentro de los términos estipulados, sólo uno de los participantes (Sergio Freitas da Silva) logró su propósito [12]. Y si bien no logró vulnerar los resultados de éste sistema, sí logró –mediante un monitoreo de las radiaciones electromagnéticas– averiguar por quién emitía su voto cada uno de los electores, rompiendo el principio de secrecía electoral, empleando únicamente equipo casero de bajo costo al buscar que esto fuera meramente una prueba de concepto; un atacante determinado podría utilizar equipo mucho más sofisticado para intervenir las votaciones a mucha mayor distancia.
Y si bien el sistema empleado por Brasil sale mucho mejor parado que los empleados en Europa y Estados Unidos, no debemos tomar la ausencia de evidencia por evidencia de ausencia: Lo único que demostraron es que ninguno de los atacantes pudo demostrar una vulnerabilidad en el periodo estipulado, o no quiso hacerlo por el precio ofrecido, pero nada indica que no haya fallas no encontradas — O peor aún, puertas traseras intencionales.

Disminución de costos

La sociedad está acostumbrada a lidiar con los bemoles del voto tradicional, utilizando al papel como su medio primario. Una crítica muy común a éstos procesos, especialmente en los países cuyas democracias no están bien consolidadas (y por tanto, requieren de mucho mayor inversión tanto en la vigilancia como en la promoción de la participación de las elecciones) es el costo — En México, citando a un caso extremo (el sistema electoral más caro de América Latina [13]), cada sufragio emitido en las elecciones intermedias del 2009 tuvo un costo superior a los 17 dólares, aunque hay estimaciones que lo llegan a ubicar en hasta 50 dólares, tomando en cuenta gastos ocultos.
Como mencionamos anteriormente, un rubro que en el sin duda podrían presentarse importantes ahorros es en la generación, el manejo y la custodia del material electoral. Sin embargo, como queda demostrado tras el estudio realizado por Feldman, Halderman y Felten a las estaciones de votación Diebold AccuVote-TS [14], las más difundidas en los Estados Unidos y que han sido responsables de la recopilación de votos de hasta el 10% de los electores de dicho país, con conocimiento técnico especializado éstas máquinas presentan un nivel de confiabilidad ante ataques verdaderamente bajo, y permiten —requiriendo de un tiempo mínimo de acceso— la reprogramación resultando en resultados fraudulentos que serían prácticamente imposibles de lograr en una elección tradicional sin recurrir a métodos violentos.
Las vulnerabilidades descritas por Feldman, Halderman y Felten no son privativas a los equipos Diebold — En el sitio Web en el cual está publicado su artículo junto con un video de diez minutos demostrando su ataque y una lista de preguntas frecuentes mencionan: (traducido)

¿Por qué estudiaron éstas máquinas Diebold? ¿Por qué no otras tecnologías para votos?
Estudiamos estas máquinas porque son las que conseguimos. Si hubiésemos tenido acceso a otro tipo de máquinas, probablemente las hubiéramos estudiado.
¿Son otras máquinas más seguras que las que estudiaron?
No lo sabemos. Esperamos que así lo sean —las elecciones dependen ya de ellas— pero no hay suficiente evidencia para responder a esta pregunta
Un rastro impreso verificado por cada votante es la protección más importante que puede hacer más seguras a las máquinas de voto electrónico.

El último punto mencionado es de especial relevancia: Un rastro impreso verificado por cada votante. La única garantía que un votante puede tener de que su voto fue registrado correctamente es que el sistema genere una boleta impresa y de caracter irrevocable, misma que sea verificada por el votante al instante, la cual se convertirá en el documento probatorio de la elección3. No hay manera —ver la cita de [8] en la sección Confiabilidad de los actores— de que el estado interno de una computadora sea confiable, y muchísimo menos cuando hablamos del proceso más importante y más sensible de la vida política de un país.
Llegamos entonces a una contradicción: El equipo de votación no es barato, en términos absolutos. Su adquisición por parte de un gobierno o ente de autoridad podría justificarse si se plantea prorratear a lo largo de varias elecciones — pero si éste tiene que estar sujeto a una estricta vigilancia contínua, incluso en los años en que no será utilizado. Debe recibir mantenimiento, y debe abastecerse con una cantidad no despreciable de insumos, para asegurar un rastro impreso verificado. Además, en caso de sufrir un desperfecto, todas las casillas deben tener un plan de respaldo: Casi indefectiblemente, esto significaría tener papelería tradicional para enfrentar desde un desperfecto del equipo hasta un sabotaje, por ejemplo, en el suminstro eléctrico. Por tanto, el supuesto ahorro puede volverse en contra nuestra, convirtiéndose en un gasto mucho mayor al que implican las votaciones tradicionales.

Referencias

• [1.] ¿El voto electrónico mejora la democracia?, Heinz, Federico , (2006)
• [2.] Evidence of New Jersey Election Discrepancies, Felten, Ed , (2008)
• [3.] Are Your Votes Really Counted? Testing the Security of Real-world Electronic Voting Systems, Balzarotti, D., Banks G., Cova M., Felmetsger V., Kemmerer R., Robertson W., Valeur F., and Vigna G. , International Symposium on Software Testing and Analysis, 20/07/2008, Seattle, WA, (2008)
• [4.] Evaluating the Security of Electronic Voting Systems, Balzarotti, D., Banks G., Cova M., Felmetsger V., Kemmerer R., Robertson W., Valeur F., and Vigna G. , The Computer Security Group at UCSB, (2008)
• [5.] Interesting Email from Sequoia, Felten, Ed , (2008)
• [6.] De la Madrid me ordenó no informar que Cárdenas iba ganando, asegura Bartlett, , La Jornada, 2008/07/03, Volume 2008, Mexico, (2008)
• [7.] ¿El voto electrónico mejora la democracia?, Heinz, Federico , (2006)
• [8.] Reflections on trusting trust, Thompson, Ken , Communications of the ACM, 08/1984, Volume 27, Number 8, p.761-763, (1984)
• [9.] Beim Einsatz elektronischer Wahlgeräte müssen die wesentlichen Schritte der Wahlhandlung und der Ergebnisermittlung vom Bürger zuverlässig und ohne besondere Sachkenntnis überprüft werden können., BVerfG , p.paragraph 1-163, (2009)
• [10.] Alemania: urnas electrónicas anticonstitucionales, Heinz, Federico , 2009/03/06, Volume 2009, Number 2009/03/06, (2009)
• [11.] Teste de segurança do sistema eletrônico de votação, , Volume 2009, Number 2009/12/29, (2009)
• [12.] Un investigador logra violar el secreto del voto en las urnas brasileñas, Busaniche, Beatriz , Voto electrónico, Volume 2009, Number 2009/12/29, Buenos Aires, Argentina, (2009)
• [13.] Cuesta el voto en México 18 veces más que el promedio en AL, dicen expertos, Urrutia, Alonso, and Martínez Fabiola , La Jornada, 2009/06/19, (2009)
• [14.] Security Analysis of the Diebold AccuVote-TS Voting Machine, Feldman, Ariel J., Halderman Alex J., and Felten Ed , 2007 USENIX/ACCURATE Electronic Voting Technology Workshop (EVT’07), 08/2007, (2007)

• 1. p.ej. http://seminario.edusol.info/resena/beatriz-ramirez/2009/03-1 (requiere registro)
• 2. Premio al que comunmente se hace referencia como el nóbel del cómputo
• 3. Y claro está, es fundamental que cada una de estas boletas sea generada por separado, recortada de la inmediata anterior y posterior, con garantía de que no haya un patrón seguible en el corte, para garantizar el anonimato del elector

Modularización: Arquitecturas de paquetes al rescate

Convirtiendo a la hidra en nuestra aliada

En el número 27 de Software Gurú, Agustín Ramos presentó un artículo acerca de estrategias para lograr una modularización efectiva en Java. Varios de los puntos de su artículo me llevaron a dedicar la presente columna a explicar a qué llamamos una distribución de Linux, y cuál es su relación –y la solución que ofrece– a los problemas derivados de la complejidad derivada de la modularización, que bien describió Agustín.

Como deben ya saberlo, a diferencia de otros sistemas operativos, el entorno operativo completo al que normalmente nos referimos como Linux no es desarrollado por un sólo grupo, ni sigue un roadmap, criterios o visión en común. Mucho se ha argumentado acerca de las características que diferencían a los proyectos desarrollados desde planteamientos libres de aquellos desarrollados siguiendo metodologías tradicionales — No abordaré dicha discusión en este momento. Sin embargo, no quiero dejar de aprovechar la oportunidad de tener un artículo escrito por un colega en esta revista para ilustrar cómo abordamos la relación entre proyectos independientes –que logran una complejidad de miras mucho mayor que cualquier instancia de conjuntos de módulos desarrollados en casa– en el Software Libre, por qué enfatizamos tanto en lo prevalente que resulta dicha modularización, y cómo nos enfrentamos a su inherente complejidad.

Los sistemas basados en Linux son estructurados, pues, en distribuciones. Una distribución es un conjunto de programas –típicamente del órden de miles– que, entre todos, presentan la funcionalidad que un usuario espera ya no sólo de un sistema operativo sino que de todo un entorno operativo integrado. Además, se encargan de gestionar las relaciones de dependencia entre dichos programas, y resolver dichas dependencias, para facilitar al usuario la instalación, remoción y actualización de software.

Una instalación mínima de cualquier distribución de Linux no tiene menos de un par de centenares de paquetes individuales. El núcleo Linux, por sí mismo, no representa más que la interfaz más básica para presentar una abstracción del hardware ante los programas que corren sobre él. Formalmente, al mencionar Linux ni siquiera nos referimos a la interfaz de línea de comandos (misma que generalmente es provista por los paquetes bash, dash o sash, dependiendo de las necesidades del administrador). Son en realidad contados los paquetes que no dependen más que de paquetes esenciales. Toda distribución define un pequeño conjunto (decenas) de programas que es fundamental tener instalados como base para cualquier otro, conjunto mínimo que asumimos que siempre estará ahí para asegurarnos la funcionalidad mínima.

Si bien las primeras distribuciones tuvieron por objetivo facilitar la instalación de un sistema basado en Linux a usuarios con menor involucramiento técnico, y fueron instrumentales en la primer ola expansiva de usuarios que fuimos adoptando Linux hacia mediados de los 1990, han trascendido ya a éste rol para dar respuesta al infierno de dependencias al que se refiere en su texto Agustín Ramos: Hacia fines de los 1990, aproximadamente cuando todas las distribuciones comenzaban a contar en miles los paquetes independientes que ofrecían, comenzó a hacerse obvio que no bastaba con que cada paquete indicara de qué otros paquetes dependía (incluyendo, claro está, la información de versiones pertinente), sino que era necesario contar con una arquitectura de paquetes: Un esquema orientado a depósitos y no a paquetes individuales, que se encargara de resolver las dependencias cada que el administrador instalara o eliminara un paquete. La primera arquitectura fue introducida por la distribución Debian, bajo el nombre de apt: A Package Tool. Es definitivamente gracias a apt que, al día de hoy, la versión de desarrollo de Debian cuenta con 15640 paquetes fuente independientes, que resultan en 27886 paquetes binarios, cubriendo prácticamente todas las áreas de necesidad en cómputo, tanto a nivel de aplicaciones como de bibliotecas.

A diferencia de otras arquitecturas previas, como los ports de los Unixes BSD, Apt está además construido basado en el manejo de depósitos múltiples. Esto significa que, además de servirme para instalar los paquetes oficiales de la distribución, nos permite definir depósitos adicionales con el software que desarrollemos localmente, así como de paquetes adicionales que preparemos localmente para uso en nuestra organización.

Con esto como introducción, veamos cómo ésto se aplica al texto de Agustín. Por razones de espacio, me enfoco a cómo éste esquema reduce fuertemente los efectos negativos de la modularización, permitiendo a los desarrolladores crear software más robusto y temer menos a esta tan dificil de conciliar fuente de dolores de cabeza.

Demasiadas dependencias

El argumento principal mencionado en el texto al que hago referencia en contra de tener demasiadas dependencias es la posterior dificultad de instalación de nuestros sistemas. Sin embargo, al crear paquetes con la información de las dependencias, convertimos el fastidioso proceso de instalación (y todo el tiempo que requiere documentarlo) en una sóla instrucción al sistema.

Dependencias cíclicas

Coordinar el trabajo de cientos de voluntarios en todo el mundo, sin más factores de cohesión que su voluntad por crear un sistema de calidad trae como resultado natural el que parte importante de sus esfuerzos estén encaminados a la creación de documentos de políticas comprehensivos — y a que su comunidad de desarrolladores comprenda la importancia de dichos documentos.
Claro está, si la unidad atómica de trabajo en una distribución es el paquete, problemas tan claros como las dependencias cíclicas fueron de los primeros puntos en ser prohibidos por política. Sin embargo, conforme la complejidad de cada uno de los paquetes aumenta, se vuelve posible que aparezcan dependencias cíclicas de indirectas. Para evitar problemas como este, y otros destinados del control de calidad en sistemas complejos, se hacen revisiones periódicas de todos los procesos imaginables.
En este aspecto, si bien no hay balas de plata para evitar las dependencias cíclicas, contamos con una comunidad de desarrolladores verificando que estos problemas se mantengan al mínimo. No estamos sólos en el manejo de nuestros proyectos.

Largas cadenas de dependencias

Este fue precisamente el punto que motivó al desarrollo de las arquitecturas de paquetes. Podemos confiar en que la arquitectura que elijamos, empleando los depósitos del sistema y de nuestra organización, sepan resolver este punto sin que represente problemática alguna. Además, no tenemos por qué limitarnos al uso de este esquema para las dependencias de los componentes externos que empleemos. Si dentro de nuestra organización nos acostumbramos a empaquetar nuestro código en componentes, la reutilización de código que podamos hacer será muchísimo más simple y más natural.

Dependencias en conflicto

Nuevamente, aquí acudimos a la sabiduría de las masas, a la fuerza de la multitud. Una distribución basada en Linux no es sólo un conjunto de programas disponibles a través de un mismo depósito — La mayor parte del trabajo de sus creadores es asegurarse que todos los componentes sean mutuamente compatibles, y asegurar a los usuarios un producto de calidad, con todas las actualizaciones necesarias para asegurar su seguridad (cuidando no compormeter su estabilidad) durante su ciclo de vida.
Este puede ser un punto fundamental al elegir qué distribución vamos a usasr para determinado proyecto: Hay distribuciones principalmente orientadas al perfil de usuario de escritorio, para el cual es fundamental tener siempre soporte completo para el último hardware, aceleración gráfica compelta y demás bondades. Sin embargo, para basar nuestros desarrollos empresariales, típicamente preferiremos las distribuciones con ciclos de vida más largos, con un mayor soporte a largo plazo.

Como pueden ver, manejar una arquitectura de paquetes simplifica algunas de las tareas más complicadas (y más ingratas) del desarrollo de software, el manejo de toda la talacha creada por los componentes que, a fin de cuentas, incluimos para ahorrarnos trabajo.

Cuando veo los instaladores típicos, que crean enormes amasijos (típicamente en forma de enormes instaladores .msi o archivos .jar que incluyen copia de todas las dependencias para evitar estos problemas), no exagero: Me dan ganas de llorar. Porque además, al tener varias copias de una misma biblioteca en el sistema, tengo la certeza de que en caso de aparecer algún defecto en alguna de ellas, habrá componentes de mi sistema que reciban la corrección en cuestión — pero habrá otros que no. Acostumbrarse al manejo de dependencias externas nos reduce la tentación de acudir al tan temido ligado estático, reduce el peso de nuestras imágenes de instalación (y de nuestros sistemas ya instalados), y ayuda fuertemente a mantener un mayor control de calidad en nuestros procesos como un todo.

Mucha gente evita aprovechar la modularización como medida preventiva para no perder la razón resolviendo dependencias y bugs creados por compatibilidad incompleta entre versiones. Sin embargo, dejar de usar buen software, ya existente y probado por terceros, sólo por no contar con las herramientas de seguimiento correctas es un triste error en el que debemos evitar caer. La hidra de la modularización a la que se refiere Agustín puede ser un mounstro mortal, pero si aprendemos a hablar con ella puede ser nuestro mayor aliado. Porque si dos cabezas piensan mejor que una, ¿qué decir de decenas de cabezas?

Historia y futuro de la interfaz hombre-máquina

Frecuentemente nos mostramos maravillados de cómo ha avanzado la manera en que interactuamos con la computadora en los últimos años, sin detenernos a pensar cuánta verdad hay –o no– detrás de esta afirmación. A fin de cuentas, hace apenas unos años el uso de las computadoras era verdaderamente limitado, y hoy en día están en todos lados, y parecería que cualquiera es capaz de manejarlas — Al menos, en sus funciones básicas.

Yo sostengo que esta es una afirmación falsa, basada en las apreciaciones de gente ajena a nuestro campo, y producto más de la popularización que de un verdadero cambio cualitativo. Claro está, al poner en duda lo universalmente aceptado, recae en mí sustentar mi afirmación.

Vamos, pues, con un breve recorrido de cómo evolucionó la interacción hasta el día de hoy.

Los inicios

Las primeras décadas del desarrollo de la computación como una disciplina aplicada de la ingeniería (tomando como punto de partida de forma un tanto arbitraria a la primer computadora electrónica en 1943, ENIAC) verdaderamente vieron un cambio radical en la manera en que los usuarios se aproximaban a la computadora — Esto resulta poco más que una obviedad, dado que antes de 1943 no existían las computadoras siquiera.

Las primeras computadoras no tenían nada que hoy reconoceríamos como interfaz — Tanto instrucciones como datos eran introducidos directamente a las ubicaciones de memoria al iniciar la ejecución a través de tarjetas perforadas, y eran leídos de los registros del procesador, mostrándolos directamente en un volcado binario, hacia tarjetas o cintas perforadas, que debían ser traducidas a algo legible empleando dispositivos mecánicos independientes.

Teletipos y terminales

El primer avance resultó en una dirección obvia, pero facilitó tremendamente tanto el uso como el aprovechamiento de los resultados: La interfaz textual. No hablo aún de una pantalla, sino de la adecuación del teletipo, híbrido de teclado e impresora, que comenzó su existencia como un reemplazo más ágil y confiable que el código Morse para la comunicación a larga distancia. El teletipo permitía ingresar programas mucho más complejos a memoria, lo cual llevó a que naciera y popularizara un concepto que nos parece muy ajeno a las interfaces de usuario: El de los archivos. Aparecieron los primeros editores (obviamente, mucho más espartanos de lo que conocemos hoy, y orientados a trabajo línea por línea), y como consecuencia directa, los programas pudieron comenzar a presentar una mucho mayor complejidad – llevando a la introducción de bibliotecas de código y a las diversas abstracciones y estrategias para manejar la complejidad.

La transición del teletipo a la pantalla no es tan simple como podría parecer. Dejando de lado la mera complejidad técnica (relativa al estado del arte de la época) de crear dispositivos independientes y de relativo bajo costo capaces de mantener comunicación con la computadora central, generando la imagen en pantalla del texto que iban recibiendo — lo cual implicaba que tuvieran una memoria interna, aunque mínima para estándares modernos1, las ventajas de tener terminales con cierto grado de inteligencia se hicieron obvias, y comenzaron a aparecer terminales con diferentes estándares2 capaces de reposicionar el cursor, o de desplegar texto con atributos (negritas, subrayado, colores), caracteres semi-gráficos, hasta verdaderas capacidades de formularios como las que manejaban las IBM 3270, que comenzaron a permitir desacoplar la lógica de un programa de su presentación tal como hoy lo vemos en los navegadores Web.

Las terminales además fueron centrales para la aparición de computadoras multitarea/multiusuario. Quienes gustamos de utilizar sistemas Unix utilizamos como una de nuestras herramientas más poderosas al emulador de terminal, o como le dice el resto del mundo, la ventana negra. Si bien las terminales como producto de hardware hace mucho tiempo que ya no existen para propósitos prácticos, la interfaz de línea de comandos programable permite un grado de expresividad tan rico que no ha podido ser reemplazado por ningún otro medio.

WIMP: Window, Icon, Menu, Pointer

En diciembre de 1968, en los laboratorios de Palo Alto de Xerox, Douglas Engelbart presentó la que al día de hoy se conoce como la madre de todas las demos: La introducción de la interfaz gráfica básica que seguimos utilizando hoy en día, manejada a través de un apuntador controlado por un mouse, presentando ventanas para la visualización de las diferentes aplicaciones en uso (o vistas de una misma aplicación), iconos representando atajos a las acciones de sistema disponibles, y con un menú como elemento estándar presentando las acciones relacionadas con cada aplicación activa. Y, claro, para la entrada y manipulación de datos dentro de cada aplicación, el dispositivo primario seguirá siendo el teclado.

La demostración de Engelbart incluía ejemplos de aplicaciones verdaderamente revolucionarias en esa época, como la videoconferencia, el correo electrónico, el hipertexto o un editor colaborativo de tiempo real.

Y aunque ha habido refinamientos sucesivos y grandes cambios en la parte estética de esta propuesta, para las computadoras de uso general seguimos utilizando este esquema de interacción — Con más de cuarenta años de antigüedad.

Interfaces de propósito acotado

Posiblemente el mayor cambio en las interfaces de usuario viene de que, cada vez con mayor fuerza, tenemos dispositivos con gran poder de proceso de cómputo sin un formato de computadora de propósito general. No veo como casualidad que hoy veamos con entusiasmo a las interfaces tan revolucionarias como las presentes en teléfonos celulares o consolas de videojuego — Estamos llegando al punto en que vamos encontrando formas muy convenientes de interactuar con computadoras de propósito acotado, aunque éstas no sean adecuadas para aquellas de propósito general. Ilustro esto con dos ejemplos:

Con la generación actual de consolas de videojuegos, Nintendo se anotó el mayor éxito al introducir su Wii: Una consola de relativamente bajas prestaciones y muy inferior a su competencia en las áreas en que típicamente competían, la capacidad gráfica. Sin embargo, su apuesta más fuerte fue hacia una interfaz novedosa: Los controles basados en acelerómetros, que permitieron modelar diferentes actividades como nunca antes se habían presentado en videojuegos.

Por otro lado, el iPod de Apple introdujo una interfaz largamente prometida, basada en una pantalla táctil de tamaño reducido, y orientada a equipos destinados al entretenimiento, a la consulta rápida de información, y especialmente popularizada a través del teléfono aparecido poco tiempo después. Sin embargo, si bien esta interfaz ha resultado natural para una gran cantidad de personas, resultaría indudablemente impráctica y antiergonómica para una computadora de propósito general.

Y claro, seguiremos viendo nuevas interfaces dedicadas a tareas específicas — Las más exitosas serán, sin duda, las más transparentes: Las que se integren de manera transparente a las tareas, mejorando nuestra vida sin requerir que reparemos siquiera en su existencia. Por ejemplo, ¿cuánta gente está consciente de la cantidad de cálculos que se realizan en un automóvil? ¿No es acaso uno de los mejores ejemplos de cómputo ubicuo que se ha insertado silenciosamente en nuestras vidas?

Otras ideas

Han habido, claro, otras muchas propuestas de interfaces para uso general. En general no han sido bien aceptadas, o han sido empleadas sólo en contextos muy específicos. Algunos ejemplos son:

Pantallas táctiles

Desde mediados de los 1980, Hewlett-Packard introdujo su línea de computadoras HP110, con una pantalla sensible al tacto. Esta interfaz prometía ser más ágil y natural que el mouse (que requiere un nivel de coordinación no trivial). Y si bien esta interfaz tuvo un moderado éxito en áreas como los kioscos (cajeros automáticos, puntos de toma de pedido en restaurantes de comida rápida, etc.), nunca fue del todo aceptada para un uso general por lo poco ergonómico que resulta tener que levantar la mano constantemente para apuntar a puntos de la pantalla.

Reconocimiento de voz

La ciencia ficción de los 1970 (piensen en HAL de 2001 o en la serie Star Trek) presentó a la voz como la principal forma de interacción hacia la computadora (y un combinación de voz y despliegue en pantallas para los resultados). Se han ensayado interfaces de reconocimiento de voz, pero han fallado una tras otra por la dificultad que presenta el lenguaje humano, la alta variabilidad de los elementos que permiten reconocer las palabras en diferentes idiomas e incluso con diferentes acentos. Además de esto, fuera de dar comandos puntuales, "dictar" un texto a la computadora no es una tarea tan simple como podría parecer: Al redactar un texto, el proceso normal que seguimos implica ir hacia atrás y hacia adelante, corrigiendo el texto, reemplazando y reformulando las frases. Una interfaz de dictado deberá saber discriminar el texto de las órdenes, lo cual requerirá un entrenamiento nada trivial al usuario.

Manipulación 3D

Presentar la información como objetos del mundo real, manipulables a través de guantes o gestos, aparece como muy atractivo. Podemos ver un ejemplo muy cuidadosamente desarrollado de una interfaz basada en estas ideas en la película Minority Report (Steven Spielberg, 2002). El poder de procesamiento y el hardware especializado para hacer este tipo de manipulaciones, sin embargo, no justifica –al día de hoy– el costo que significaría. Hay aplicaciones, claro, para las que este costo sí se justifica; en México, la Dirección General de Servicios de Cómputo Académico de la UNAM cuenta con la computadora especializada Ixtli para simulación y visualización, y si están interesados en conocer esta tecnología pueden solicitar visitas guiadas demostrando su funcionamiento.

Claro, hay muchas más ideas en el tintero, y en los años por venir seguro veremos varias más. Sin embargo, no ha habido cambios substantivos en las interfaces para interactuar con una computadora de propósito general en los últimos 40 años. Me resisto a creeer que esto sea porque el modelo actual sea perfecto; como desarrolladores, tenemos la tarea de proponer, adoptar y evaluar nuevos modelos de interacción.

Uno de los términos ampliamente en boga en nuestro campo hoy en día es el cómputo en la nube. Tan en boga que me parece que se ha convertido en una palabra mágica, bastante hueca y sintomática de querer parecer en sintonía con los últimos desarrollos tecnológicos, sin comprenderlos en realidad. Además, al ser una frase que de golpe comenzó a escucharse con tanta insistencia, asumimos que es una estrategia nueva, una idea posibilitada por los nuevos avances tecnológicos — Y esto dista de ser el caso. En esta columna busco clarificar los conceptos y tipos básicos de cómputo en la nube, sus principales ventjas y desventajas, y brevemente encontrar paralelos con casos documentados de estos ”novedosos” conceptos
No critico, ojo, a las estrategias que están detrás de este sonoro término — Muy por el contrario, resultan muy convenientes a la hora de implementar, y como profesionales del desarrollo de software tenemos la obligación de estar familiarizados con ellas. Lo que critico es el abuso de un término ambíguo, que suele poner en problemas a los implementadores, al no estar claramente comprendido.
La mayor parte de las referencias que consulté mencionan a tres capas o niveles principales: El software –o la aplicación– como un servicio (Software as a Service, SaaS), la plataforma como un servicio (Platform as a Service, PaaS) y la infraestructura o el hardware como un servicio (Infrastructure as a Service, IaaS). Mi punto de vista, es que más que un nivel distinto, IaaS es un conjunto de cualidades adicionales que dan valor agregado a una oferta de PaaS.

SaaS: Bloques de construcción

Cuando uno de nuestros sistemas utiliza un API público remoto, o cuando para nuestro flujo de trabajo empleamos a una aplicación que reside y es administrada fuera de nuestra organización, estamos empleando SaaS. Nuestro proveedor puede cobrar su servicio de diversas maneras: A través de una renta directa, requiriendo del despliegue de publicidad, recibiendo autorización para recolectar nuestra información y hacer minería de datos sobre de ella — Hay una enorme variedad de esquemas, que refleja la gran variedad de niveles de integración que se puede dar a los servicios.
Notarán que la principal diferencia con los esquemas tradicionales cliente-servidor con que hemos trabajado desde hace décadas es el uso explícito de un proveedor externo — Sin embargo, técnicamente, nuestros sistemas no seguirán una lógica o un proceso de desarrollo diferente de como lo vienen haciendo por décadas.
Al mismo tiempo, sí hay una importante diferencia: Al no controlar nosotros el proceso que ocurre dentro de uno de nuestros subsistemas, nos vemos forzados a hacer bien lo que ya deberíamos estar haciendo: Implementar una separación limpia de responsabilidades entre los componentes, utiilzar exclusivamente las interfaces publicadas explícitamente — No brincarnos las capas de abstracción, como muchas veces estaríamos tentados a hacerlo en un proyecto meramente interno.
Hay un punto que no podemos perder de vista cuando empleamos un servicio de aplicaciones como parte de nuestra infraestructura en sistemas: Al depender de un tercero, ponemos en sus manos parte importante de nuestras promesas (y, por tanto, requerimientos), en tanto a disponibilidad, protección de datos y continuidad de la operación. Tocando el primer punto, resulta natural: Una falla en el servicio de cualquiera de nuestros proveedores de aplicaciones llevará a que nuestro sistema presente información incompleta o errónea a sus usuarios.
Respecto al segundo, no sólo debemos tener en cuenta las implicaciones directas (el proveedor tendrá acceso a todos los datos específicos que le enviemos para operar), sino que las indirectas: Todo ataque por medio del cual un agente hostil pueda llevar a cabo recolección de información sobre de nuestros proveedores resultará en la probable divulgación de información interna nuestra, e incluso el mismo proveedor puede estar realizando un seguimiento estadístico de nuestros patrones de uso, revelando mucho más de lo que podríamos querer darle.
En tanto a la continuidad de operación, si el proveedor del servicio decide cambiar los términos bajo los cuales brinda sus recursos, o si sencillamente deja de operar, podemos quedar sin una alternativa disponible para parte importante de nuestro flujo de trabajo.
Como corolario de la dependencia de terceros, al depender de aplicaciones como servicio perdemos la capacidad de planear las actualizaciones de nuestra infraestructura — Al depender de proveedores externos, en el momento en que cualquiera de sus APIs cambia, nos vemos forzados a actualizar de inmediato. Nuestros servicios en producción pueden fallar, y el mero concepto de rama estable pierde buena parte de su atractivo1.

PaaS+IaaS: Flexibilidad en el uso de recursos

Mientras que en el apartado anterior partíamos de que –desde el punto de vista del usuario– hay una aplicación central que corre en sus instalaciones y consume procesamiento realizado por componentes distribuídos por el mundo (”en la nube”), aquí la aplicación completa será desplegada en el proveedor de servicios. El usuario deja de emplear un servidor –o una granja de servidores– para consumir sólo los recursos. Y, consecuentemente, el esquema de utilidad para un proveedor de servicios bajo esta modalidad puede ir desde la renta a costo fijo hasta un cobro por uso de recursos, típicamente permitiendo reconfiguraciones dinámicas del paquete (del conjunto máximo de recursos) como respuesta a la demanda del sistema.
La justificación detrás de este concepto es que los servidores ”en casa” representan un gasto demasiado grande — Compra y actualización periódica de equipo, consumo eléctrico, uso de espacio físico y de ancho de banda, siendo que las instalaciones de la mayor parte de los usuarios no cuentan siquiera con un centro de datos. Además, todo servidor debe ser adquirido contemplando la carga estimada que sostendrá, pero contemplando un espacio para sobreconsumo en picos de actividad no planificable. En cambio, un proveedor masivo de servicios balancea el exceso de demanda de un usuario con la reducción de demanda de otro, permitiendo un menor sobredimensionamiento — Y una reducción neta de precios.
Nuevamente, apreciarán que la idea no es nueva — Los proveedores de presencia o de hosting existen desde hace muchos años en Internet. Más allá aún, precisamente este esquema fue planteado a mediados de los 1960, cuando fue desarrollado el sistema MULTICS2.
La principal diferencia con el esquema tradicional de renta de servidores es que bajo este esquema, el usuario deja de ser responsable de la administración incluso del servidor en el que se ejecutarán sus aplicaciones; el proveedor de servicios ofrece una cartera de plataformas administradas. Las plataformas pueden ser desde aplicaciones medianamente complejas, como plataformas Web que llevan un grado no trivial de configuración y representan una solución completa e integrada, hasta marcos para el desarrollo de sistemas (como Rails, Struts, Django, GWT), para los cuales los clientes sólo proveen el código específico de su aplicación, y aprovechan todo el andamiaje común que ya existe para una amplia base de clientes.
Respecto a consideraciones de seguridad y confiabilidad: Si bien al emplear PaaS no caemos ya en la trampa descrita en el primer apartado respecto a emplear código del cual no tenemos más conocimiento que el API, éste esquema sigue depositando todos nuestros datos en control del proveedor, en infraestructura compartida, con lo cual la probabilidad de que un ataque a un sistema sin relación aparente con el nuestro puede dar a un intruso acceso pleno a nuestra información.
El riesgo de que el proveedor cambie sus políticas de cobro a un esquema que no nos convenga se reduce también fuertemente, dado que en principio tenemos todo lo necesario para replicar la instalación con cualquier otro proveedor, o incluso migrar a una solución ”en casa”. Sin embargo, seguiremos sujetos a los días bandera de actualización forzada, dado que el proveedor típicamente ofrecerá la misma versión base a todos sus clientes — Y este factor puede dificultarnos una migración entre proveedores.
Hablando meramente de la conveniencia: Podemos enviar a uno de nuestros sistemas a la nube dados sus requisitos de almacenamiento de información, o de ancho de banda. Ahora bien, ¿cómo estamos realizando nuestros respaldos? Para poder hacer frente a contingencias, contar con una estrategia de respaldos buena y probada es mucho más importante aún que cuando hablamos de despliegues en infraestructura propia.
Por último, respecto al IaaS: Este resulta el más nebuloso y ambiguo — Ya no se trata de sistemas o entornos para que éstos se ejecuten, sino que de recursos de cómputo que están a nuestra disposición: Espacio en disco o en memoria, ”ticks” de procesador, ajuste de ancho de banda, como componentes discretos y ajustables en vivo — Atributos que se apoyan fuertemente en la virtualización para poder ser desplegados y controlados.
Hay quien incluye la virtualización de escritorios dentro de la definición de IaaS, pero si mucho, eso debe ser visto como consolidación de recursos y mejoría en el aprovechamiento de recursos, pero por calidad en el servicio debe hacerse utilizando recursos internos a la organización — Y por tanto, se aleja de las definiciones básicas de en la nube.
Llevamos años haciendo cómputo en la nube de un tipo o de otro. Al desmitificarlo un poco, espero abonar a una mejor utilización. Y al hablar acerca de los nada ignorables riesgos que conlleva, apunto a la cautela que debemos tener al adoptarlo, no entrar de lleno sólo porque es la moda.

• 1. Podemos ver un buen ejemplo de esto cuando Twitter cambió su esquema de autenticación en agosto de este año, obligando a cientos de aplicaciones a impulsar la migración a nuevas versiones — http://blog.twitter.com/2010/08/twitter-applications-and-oauth.html
• 2. El sistema operativo MULTICS partía del planteamiento de que el cómputo se convertiría en un servicio provisto centralmente, como la electricidad o el teléfono. http://www.multicians.org/