El líder del equipo de investigadores, Hari Prasad (crítico del uso de estos sistemas desde hace tiempo), ha sido detenido el 22 de agosto de 2010.

Debe tenerse en cuenta que los “ataques” y manipulaciones que se muestran en el video corresponden a este modelo específico de máquina (aunque algunos son también aplicables a otras). De cualquier forma, se trata de excelentes ejemplos de como algo aparentemente seguro y confiable es fácilmente violable. Una buena pregunta para hacerse es cuántas veces se habrán explotado estas vulnerabilidades a lo largo de los años en que el sistema ha sido utilizado. Esto es imposible de saber.

Pensar que hay “expertos” que se atreven a afirmar que “la urna electrónica es tan segura como la de papel” sin que se les mueva un pelo.

Según se informa en varios medios, la empresa Indra embolsará nada más y nada menos que $ 600.000 por el uso de su sistema de “voto electrónico”. De esta forma queda totalmente claro que, a pesar de todas las dudas expuestas respecto de su aplicabilidad para una elección democrática, el sistema de Indra es altamente eficiente y eficaz para cumplir su objetivo: levantarla con una pala.

Recordemos que, según el censo provincial de 2008, Marcos Juarez tiene una población que no supera los 27.000 habitantes, y que en el padrón para estas elecciones aparecen 22.773 personas (cifra que parece excesiva respecto de la población, cabiendo preguntarse cuántos efectivamente votarán). La elección se realizará en 62 mesas, dispuestas en 5 escuelas.

Haciendo cuentas

Del monto que se pagará a Indra y los números antes expuestos resulta lo siguiente:

• Costo por votante empadronado: US$ 6,64 ($ 26,35).
• Costo por mesa de votación: US$ 2.437 ($ 9.677).

Tomemos como referencia que en Brasil, donde se utiliza el “voto electrónico”, el costo por votante es de US$ 2,3 ($ 9,13) y en Chile, con voto “convencional”, es de US$ 1,2 ($ 4,77). Resulta de esta forma que las elecciones de Marcos Juarez están costando casi 3 veces lo que cuesta en Brasil (que utiliza tecnología similar).

Y un detalle: ¿Incluyen estos $ 600.000 el resto de los costos del operativo eleccionario? (Presidentes de mesa, gastos varios que realiza el Estado, etc.). Probablemente no, pero poco deben representar al lado de semejante cifra.

Otro detalle: ¿Si el costo es de casi $10.000 por cada urna utilizada, cuánto más hubiera costado que pusieran pantallas de 17″ (como las que se usaron en la demostración previa) en vez de las de 15″ que finalmente colocarán?

Conclusión

Aunque Indra afirma que los resultados se verán 20 minutos luego de terminado el comicio, me parece que los mismos ya están a la vista: hicieron un negocio redondo. Y además, si todo sale bien (con semejante inversión y una elección poco compleja en donde la tendencia oficialista parece irreversible, y en la que la auditoría del sistema consistió de una simple e ingenua simulación, muy probablemente así sea), la implementación de la “pala electrónica” de Indra en el resto de la Provincia de Córdoba estará asegurada.

Esto quizás sea nuevo para nosotros los argentinos, pero en España ya conocen la pala electrónica de Indra (que parece ni siquiera molestarse en cumplir con los contratos).

Por lo pronto, la legislatura cordobesa los ha invitado para el próximo martes a realizar una demostración de su sistema. Si ya contaban con el beneplácito (y los subsidios, y las excenciones impositivas) del Gobernador Schiaretti, ahora también cuentan con el del candidato opositor radical Ramón Mestre. Mientras tanto, Luis Juez organiza manifestaciones recordando el supuesto fraude de 2007 (en el que involucró a Indra), pero nada dice de esto.

Estamos rodeados.

Especialmente para aquellos que sólo atienden a argumentos expuestos por legistas, Lessig es un reconocido abogado y catedrático de Derecho en la Universidad Stanford (previamente también en Chicago y Harvard), especializado en derecho informático. Cabe destacar que el texto es solamente de una sección de un capítulo dedicado a un tema mucho más general, pero de todas formas resulta muy ilustrativo sobre los riesgos a los que nos enfrentamos cuando hablamos de la “desmaterialización del voto“.

Máquinas que cuentan

Antes del 7 de noviembre de 2000, había muy poca discusión entre los políticos estadounidenses en torno a la tecnología de las máquinas de votación. Para la mayoría de la gente (entre la que me incluía), la cuestión de la tecnología de votación parecía algo trivial. Ciertamente puede que hubiera tecnologías de recuento de voto más rápidas, o tecnologías de comprobación de errores más precisas, pero la idea de que algo importante dependiera de estos detalles tecnológicos no era como para saltar a la portada del New York Times.

Las elecciones presidenciales de 2000 supusieron un vuelco en esta idea. Más concretamente, el vuelco vino provocado por el escrutinio en el Estado de Florida. Y es que la experiencia de Florida no sólo demostró la imperfección de los dispositivos mecánicos tradicionales de tabulación de votos (prueba número 1, la tarjeta electoral mal perforada), sino también la extraordinaria desigualdad que producía emplear diferentes tecnologías en diferentes partes del Estado. Como describió el juez Stevens en su voto particular en el caso «Bush contra Gore», casi el 4 % de los votos mediantetarjeta perforada fue invalidado, mientras que sólo se invalidó el 1,43 % de los votos escrutados mediante lector óptico.[5] Además, según las estimaciones de un estudio, con sólo variar un voto en cada una de las máquinas, el resultado electoral habría cambiado.[6]

Las elecciones presidenciales de 2004 pusieron las cosas aún peor. En los cuatro años transcurridos desde la debacle de Florida, algunas compañías se habían puesto manos a la obra para implementar nuevas máquinas de votación electrónica. Sin embargo, estas máquinas generaron aún más ansiedad entre los votantes. Si bien la mayoría de ellos no son expertos en tecnología, todo el mundo experimenta la obvia inquietud que produce una máquina de votación completamente electrónica. La mecánica electoral sería la siguiente: nos situamos frente a un terminal y pulsamos los botones para indicar nuestro voto; la máquina nos solicita que lo confirmemos y, a continuación, nos informa de que el voto ha quedado registrado. Ahora bien, ¿cómo podemos estar seguros de ello? ¿Cómo podría alguien estar seguro? Incluso si no creemos tanto en la teoría de la conspiración como para pensar que todas las máquinas de votación están amañadas, ¿cómo puede alguien cerciorarse de que cuando estas máquinas vuelquen sus datos en el servidor central, éste registre su voto con precisión? ¿Qué garantía tenemos de que los resultados no serán manipulados?

El ejemplo más extremo de dicha ansiedad lo desencadenó Diebold, la compañía líder en votación electrónica. En 2003 se descubrió que esta empresa había manipulado las cifras asociadas a las pruebas de su tecnología de votación. La filtración de ciertos memorandos de Diebold reveló que la dirección de la compañía sabía que sus máquinas funcionaban defectuosamente y que, pese a ello, decidió intencionadamente ocultar este hecho. (La reacción de Diebold fue demandar a los estudiantes que habían filtrado los memorandos —por infracción de copyright—, pero éstos demandaron a su vez a la compañía en el mismo proceso judicial, y ganaron).

Este incidente pareció reforzar aún más a Diebold en sus actuaciones. Así, la compañía persistió en su negativa a revelar ningún dato acerca del código de sus máquinas, y rechazó participar en ningún concurso donde se exigiera tal transparencia. Y si vinculamos este rechazo a la promesa del presidente de Diebold de «entregar Ohio» al presidente George W. Bush en el 2004, tendremos todos los ingredientes para que aparezcan nubarrones de desconfianza. Diebold controla las máquinas, Diebold no nos muestra cómo funcionan y Diebold promete un resultado específico en las elecciones. ¿Alguien duda de que la gente sospeche de la transparencia del proceso electoral? [7]

Y ahora resulta que nos percatamos de lo compleja que es la cuestión de cómo deberían diseñarse las máquinas de votación electrónica. En uno de mis momentos más mezquinos desde que cumplí veintiún años, le aseguré a un colega que no había razón alguna para celebrar un congreso sobre las votaciones electrónicas porque todas las cuestiones al respecto eran «perfectamente obvias». Y no sólo no eran perfectamente obvias, sino que, de hecho, eran muy complicadas de entender. A algunos les parecerá obvio que, como sucede con la tecnología de los cajeros automáticos, debería expedirse, como mínimo, un resguardo impreso. Ahora bien, si hay un resguardo impreso, se facilitaría que los votantes pudieran vender sus votos. Además, no hay razón para que el resguardo tenga que reflejar qué se computó ni tampoco qué se transmitió a cualquier autoridad central de tabulación. La cuestión de cómo definir el mejor diseño para estos sistemas resultó no ser tan obvia. Por lo que a mí respecta, después de haber pronunciado absolutas sandeces anteriormente, no entraré a considerar aquí cómo podría mejorarse esta arquitectura electoral.

Ahora bien, sea cual sea la arquitectura del sistema, hay una cuestión independiente en relación con la apertura del código que constituye dicho sistema. Una vez más, los procedimientos utilizados para tabular los votos deben ser transparentes. En el mundo no digital, esos procedimientos eran obvios; en el mundo digital, independientemente de su arquitectura, necesitamos un modo de asegurarnos que la máquina hace lo que se dice que hará. Una manera sencilla de asegurarnos es abrir el código de esas máquinas o, como mínimo, exigir que ese código venga certificado por inspectores independientes. Muchos preferirán esta última opción, y sólo porque la transparencia aquí podría aumentar las posibilidades de que el código fuera quebrantado por hackers. Mi intuición personal acerca de este asunto es diferente pero, sea o no completamente abierto el código, la exigencia de certificación resulta obvia. Y para que esta certificación funcione, el código de la tecnología debe ser —al menos en un sentido limitado— abierto.

Estos dos ejemplos plantean un argumento similar que, sin embargo, no es universal; hay veces en que el código tiene que ser transparente, aunque que haya ocasiones en que no. No estoy hablando, pues, de todo el código aplicado a cualquier finalidad. No creo que Wal*Mart tenga que revelar el código que emplea para calcular el cambio en sus cajas de pago; ni siquiera que Yahoo! tenga que revelar el código de su servicio de mensajería instantánea. Pero sí creo que todos deberíamos coincidir en que, al menos en ciertos contextos, la transparencia del código abierto debería constituir una exigencia.

Éste es un argumento que Phil Zimmermann nos enseñó en la práctica hace más de quince años. Zimmermann escribió y lanzó a la red un programa llamado PGP (pretty good privacy, «privacidad bastante buena»). PGP proporciona privacidad y autentificación criptográficas, pero Zimmermann se dio cuenta de que no obtendría la confianza necesaria para ofrecer estos servicios en buenas condiciones a menos que abriera el código fuente de su programa. Así que, desde el principio (excepto por un breve lapso en que el programa fue propiedad de una compañía llamada NAI) [8] el código fuente estuvo disponible para que cualquiera pudiera revisarlo y verificarlo. Esta publicidad ha construido la confianza en el código —una confianza que nunca podría haberse producido mediante una mera orden. En este caso, el código abierto sirvió al propósito del programador, que consistía en construir confianza en un sistema que apoyaría la privacidad y la autentificación.

Por lo tanto, el código abierto funcionó. El difícil interrogante que se nos plantea ahora es si hay alguna exigencia que realizar más allá de esta mínima que se ha expuesto. He aquí la pregunta que nos ocupa en lo que queda de capítulo: ¿Cómo afecta el código abierto a la regulabilidad?

[5] Véase Bush vs. Gore, 531 U.S. 98, 126, 2000 (Stevens, J., voto particular).

[6] Di Franco et al., «Small Vote Manipulations Can Swing Elections», Communications of the ACM, vol. 47, núm. 10, 2004, pp. 43–45, disponible en http://portal.acm.org/citation.cfm?id=1022621.

[7] Para un relato extraordinariamente inquietante que suscita mucho más que sospechas, véase Robert F. Kennedy, Jr., «Was the 2004 Election Stolen?», Rolling Stone, junio de 2006.

[8] David E. Ross, PGP: Backdoors and Key Escrow, 2003, disponible en http://www.rossde.com/PGP/pgp_backdoor.html.

De más está decir, el tiempo fue muy breve para tratar semejante tema, es por eso que dejo a continuación algunos puntos que me quedaron en el tintero.

• Respecto del “voto cadena”: El voto electrónico no elimina el viejo truco de robarse un sobre, dárselo a alguien con una boleta del partido X y pagarle luego cuando devuelva un sobre vacío. Con el “voto electrónico” se hace tan simple como darle una cámara fotográfica digital y pagarle a la persona cuando traiga una foto de la pantalla mostrando el voto confirmado a favor del partido X (para cada sistema en particular, hay variantes aún más igeniosas).
• Sobre el supuesto “éxito” de la experiencia en Río Cuarto: Hay que aclarar que en las pasadas elecciones a Intendente en Río Cuarto no se utilizó “voto electrónico”. Apenas se utilizó un sistema electrónico para la realización del escrutinio provisorio (no definitivo) provisto por la empresa Magic Software Argentina (MSA). La concejal Yawny lo nombra como una experiencia exitosa, algo con lo cual no coincido. El operativo eleccionario tuvo un costo superior a los $500.000 (cuando en la elección anterior rondó los $60.000), se detectaron irregularidades con software instalado ilegalmente en algunos equipos y, como si fuera poco, el sistema completo se cayó por espacio de 10 minutos (estas irregularidades están respaldadas por fotografías, video y un documento elevado a la Junta Electoral con la firma de más de 5 fiscales informáticos). ¿Puede considerarse esto una experiencia exitosa? (sólo con el escrutinio provisorio realizado por medios electrónicos).
• Respecto de la auditabilidad de los sistemas: Es fácil decir “se debe auditar el sistema informático”, pero la realidad es que dicha tarea es extremadamente compleja (personas con capacidad de realizarla no abundan ni siquiera a nivel nacional) y costosa en tiempo. Aún auditados todos los componentes de un sistema (hardware, firmware, software, elementos de conectividad), queda por resolver el problema de verificar que cada máquina de votación se corresponda exactamente con el sistema auditado. Esta tarea es, en la práctica, imposible. Debemos tener presente que no existe, a la fecha, un sólo modelo de “urna electrónica” que no se haya encontrado vulnerable mediante un acceso físico en un tiempo muy breve (usualmente, un par de minutos).
• Sobre las “pruebas piloto”: Carece de toda lógica pensar que si, por ejemplo, la experiencia de voto electrónico en Marcos Juarez no presenta ningún inconveniente, esto significará algún tipo de aval al sistema o, peor aún, una demostración de que las objeciones planteadas no son reales. De igual manera, a nadie se le ocurriría pensar en que cruzar una avenida con los ojos vendados una vez invalidaría el riesgo que esto supone. Más aún, en el caso de las elecciones de Marcos Juarez es altamente probable que todo se desarrolle con aparente normalidad: Se trata de una localidad pequeña, el énfasis está puesto en demostrar que el sistema funciona y el candidato oficialista parece ser favorito. Por el contrario, los numerosos casos problemáticos bien documentados que existen a la fecha, ponen en evidencia que los problemas del voto electrónico son reales.
• Más sobre experiencias positivas y negativas: ¿Por qué vale más la experiencia positiva de Pinamar (no “Miramar”, como se dice en la entrevista) que la experiencia negativa de San Antonio Oeste? Más bien es todo lo contrario: la primera demuestra que las cosas pueden salir bien, en tanto que la segunda demuestra que las cosas pueden salir mal. Si puede salir mal, no es confiable.
• Un argumento “no técnico” en contra del voto electrónico: Un sistema electoral basado en los principios republicanos, debe ser auditable y controlable por la ciudadanía. El sistema de votación tradicional (aún con sus imperfecciones) lo es: El votante tiene forma de asegurarse de que deposita en la urna lo que se corresponde con su voluntad, y luego el procedimiento y el control de otros ciudadanos, le aseguran que se contabilizará correctamente. Aún fallando este control, tiene la posibilidad de recurrir a la justicia electoral para pedir el recuento de votos. Con el voto electrónico (aún si fuera técnicamente posible), desde el punto de partida estaría confiando en la palabra de los expertos que aseguran que el sistema “hace lo correcto”. La votación, como acto primigenio de la democracia, no puede basarse en la confianza en la palabra de una elite. Este, básicamente, fue el argumento que siguió la Corte Federal Constitucional de Alemania cuando declaró inconstitucional al voto electrónico.
• Suponiendo… y haciendo: Realmente asusta ver a legisladores que, basándose en suposiciones, sospechas y deseos, promueven la modificación de leyes (u ordenanzas, como en este caso) de vital importancia para la vida en democracia. La Concejal Yawny, basándose en sus especulaciones, presenta un proyecto de ordenanza donde puede leerse: “Impleméntese por la presente el Sistema de Voto Electrónico, el que regirá a partir de la Elecciones Municipales del año 2012” y no, como pretende ahora “analícese, debátase, véase la conveniencia…”

A continuación, una entrevista realizada por el programa Cadena Sudeste TV del día 3 de agosto de 2010 con la presencia de un representante de Indra (los subtítulos, a modo de comentarios, han sido añadidos por mí). ¿Esto es “transparencia y seguridad“?

Actualización: He completado el artículo añadiendo varias referencias sobre la empresa Indra.

Algunas consideraciones

• En las demostraciones se usaron pantallas de 17″. En la elección se utilizarán pantallas de 15″. Cabe preguntarse que otra cosa fue sólo “a efectos de demostrar (vender) el sistema”.
• Un fiscal informático solicita acceso al código fuente para auditarlo. Está claro que la empresa sólo lo proveerá cuando una auditoría medianamente seria sea ya imposible de realizar. Y aún más: nadie plantea algún mecanismo para corroborar que el software auditado sea el mismo que se encuentra ejecutándose en las máquinas.
• Es casi graciosa la respuesta del representante de Indra: Puede fiscalizar el software “probándolo” (presionando las opciones de la pantalla). Sólo esa declaración hace perder todo viso de seriedad a la propuesta.
• Aunque el representante de Indra dice desconocerlo, aparentemente han habido problemas de logística en la distribución de las urnas. Cabe aclarar aquí que la ciudad de Marcos Juarez tiene unos 25000 habitantes (¿acaso 15000 electores?). Excelente prueba piloto para proponer un sistema para una elección en una provincia con 3 millones de habitantes (por no mencionar la superficie).
• Indra, que como ya fue dicho, es cuestionada por su desempeño en este tipo de sistemas en España (donde increiblemente se defienden aduciendo cláusulas de confidencialidad), tampoco tiene buenos antecedentes con su participación en los comicios de Ushuaia, Argentina. En esta ciudad se utilizaron sus sistemas en 2003, para mas tarde volver al sistema de votación convencional ante la rotunda negativa, por parte de Indra, de cumplir con las exigencias de los ediles municipales.
• Se ha asociado a esta empresa con a negocios turbios relacionados con el Gobierno Nacional (en particular, asociada a Anibal Fernandez). Según se ha informado, Indra también cometió irregularidades en los comicios nacionales de 2004.
• Indra posee instalaciones en la Ciudad de Córdoba, gracias a beneficiosas excenciones impositivas e incluso subsidios otorgados por el gobierno del Cr. Schiaretti. La empresa también fue apuntada como principal responsable en la denuncia de fraude realizada por Luis Juez en las elecciones a Gobernador de Córdoba en 2007 (de las cuales resultó electo el Cr. Schiaretti). En dicha oportunidad, Indra se había encargado solamente del recuento de votos, y a Juez se le negó la posibilidad de realizar un nuevo conteo. De haberse utilizado voto electrónico, simplemente no habría habido votos que contar.
• Aún con todos estos antecedentes, si la experiencia en Marcos Juarez resulta exitosa, los votantes cordobeses deberemos depositar la misma confianza en esta empresa para las próximas elecciones provinciales (sin auditorías serias, creyendo en “certificaciones” y aseveraciones varias, etc.). ¿Puede considerarse esto una “elección democrática“? ¿A esto llaman “transparencia“?
• La guinda sobre la torta: Según parece, Indra embolsará nada menos que $600.000 por la minúscula elección de Marcos Juarez (unos $30 por cada elector que figura en el padrón, y hay que tener en cuenta que no todos votarán…).

Existe una especie de ilusión, arraigada en muchas personas, consistente en creer que el desarrollo tecnológico actual permite el diseño y la construcción de sistemas informáticos totalmente seguros (y, por lo tanto, confiables). Valga de ejemplo este extracto de un documento elaborado por un legislador provincial de Córdoba (el énfasis ha sido agregado por mí):

“La eliminación de la proliferación de boletas en el cuarto oscuro se logra a través del voto electrónico o de la boleta única. Adelanto que el primero es el que a mi juicio mejor armoniza los valores de seguridad y transparencia, y que el nivel alcanzado por los sistemas informáticos y las tecnologías de la información sin duda harian factible su implementación.”

Claramente, el legislador (y seguramente su asesor en materia informática) no tiene duda alguna de que el estado actual de la informática hace posible la existencia de un sistema informático seguro y transparente. Sin embargo, para cualquier entendido en informática, resulta obvio lo contrario.

El por qué de la ilusión

La creencia es comprensible. En nuestra vida diaria usamos sistemas informáticos todo el tiempo. No sólo a través de computadoras (mediante las cuales chateamos, navegamos por la web, realizamos operaciones bancarias “electrónicas”), sino que hasta nuestros teléfonos han dejado de ser tales, para convertirse en pequeñas computadoras portátiles con cada vez más funciones. De repente, vemos hardware y software en aviones, automóviles, sistemas médicos y un largo etcétera. Es natural entonces que el común de la gente crea que existen los sistemas informáticos complejos y, a la vez, confiables y seguros.

Lamentablemente la realidad es muy diferente. Y como ya fue dicho, no voy a abundar en detalles técnicos engorrosos, sino que me limitaré a exponer algunos ejemplos que demuestran la fragilidad (y poca confiabilidad) de los sistemas actuales. Los mismos serán agrupados teniendo en cuenta los requisitos básicos que debiera satisfacer un sistema de votación electrónica.

Inviolabilidad

Como bien sabemos ya, ese aparato que llevamos casi siempre con nosotros y al que llamamos “teléfono celular” no es un teléfono, sino una pequeña computadora que incluye un programa que le permite funcionar como si lo fuera. Durante unos 20 años, los distintos fabricantes de celulares han dedicado mucho esfuerzo y dinero para intentar que sus dispositivos sean “inviolables”, esto es, impedir que los usuarios puedan modificar o alterar de alguna forma el software incluido en los mismos.

Con el paso del tiempo, los celulares se han vuelto cada vez más complejos (tanto en su hardware como en su software), y dicha complejidad ha conspirado más y más contra ese objetivo. Puede el lector tomar como ejemplo los conocidos como “smartphones”: iPhone de Apple, la línea “N” de Nokia o la serie de dispositivos basados en Android (de Motorola, HTC, entre otros). Cada uno de estos dispositivos incorpora distintos mecanismos (bastante complejos, por cierto) para impedir modificaciones por parte de los usuarios. ¿Su efectividad? Ninguna. Mediante procedimientos realizables por un niño de 12 años todos los mecanismos de protección pueden ser vulnerados en un par de minutos. Más aún, el novísimo iPhone 4G (y el innovador iPad), con uno de los sistemas de protección más estrictos, puede ser hackeado con sólo abrir un archivo PDF.

Resulta hasta gracioso entonces, cuando empresas como Indra y Diebold, entre otros fabricantes de “urnas electrónicas”, hablan de la supuesta inviolabilidad de sus sistemas. Quizás Apple, Nokia, Motorola y Sony-Ericsson deberían consultarlos (¿o será al revés?).

Confidencialidad

El voto debe ser secreto. Esto ya lo sabía muy bien Roque Saenz Peña hace 100 años. Por lo tanto, un sistema de votación electrónica debería garantizar este requisito. Pero… ¿es esto posible?

Cada vez que se utiliza una computadora electrónica, la misma emite ondas de radio que pueden ser capturadas (y decodificadas) a una distancia considerable. No, esto no es de un episodio de “Misión Imposible”, puede hacerse (y se hace) con equipamiento de muy bajo costo. A continuación, una breve muestra de este tipo de maniobra, realizada sobre las máquinas de voto electrónico que durante años utilizó Holanda (quienes desde 2008 han vuelto a votar con lápiz y papel):

El video muestra como fácilmente, desde una distancia de hasta 25 metros, logran identificar cuándo se está votando por determinado partido. Claro que, con equipamiento un poco más costoso (unos pocos miles de dólares), hasta puede reproducirse remotamente la imagen que está mostrando la pantalla de la computadora.

Por cierto (y apartandome un momento del tema que nos ocupa), ¿sabía usted que con un equipo de unos 800 dólares, cualquiera puede intervenir y capturar todas sus llamadas de celular y SMS?

Confiabilidad

Los sistemas se caen. Los programas se cuelgan. Todos. Por mejor hecho que esté un programa complejo, siempre tendrá errores. Hay numerosas y largas recopilaciones de errores “famosos” que han costado millones de dólares y, cuando no, alguna vida humana.

La cuestión se torna realmente grave cuando se utiliza software en sistemas críticos. Por nombrar solamente dos casos recientes: parece ser que tanto el problema de “aceleraciones inesperadas” en algunos modelos de Toyota (que provoca aceleraciones repentinas sin haber accionado el acelerador), como el accidente del vuelo 447 de Air France (que terminó con un AirBus 330 en el Océano Atlántico) se deben a errores en el software.

Claro que no murió nadie cuando a la gente de Magic Software Argentina (MSA) se les colgó el sistema de escrutinio provisorio en las elecciones de Río Cuarto, pero claro está que un fallo similar (o peor) en un sistema de votación (y no sólo de escrutinio) de una elección de gran envergadura provocaría un caos (y el descrédito total por parte de la ciudadanía, cuando menos). Aunque Indra, Diebold, MSA y otros llenen su material de marketing asegurando que sus sistemas no tienen errores, sepa Ud. con seguridad que están ahi, a lo sumo, todavía ocultos de los ojos de sus programadores.

Fin de la ilusión

No importa lo que diga un folleto, ni un vendedor. Los sistemas inviolables, seguros y transparentes (al nivel requerido para una elección democrática) no se han visto por aquí, y no se verán seguramente por mucho tiempo. Espero que estos pocos ejemplos que, sin mucha elaboración, he dispuesto en este artículo, sirvan al menos para sembrar una pequeña duda en aquellos para quienes estas cuestiones resultaban “obviamente” posibles.

Una expresión de deseo: que los políticos que continúan insistiendo (desde hace tiempo) en que la votación electrónica soluciona los problemas de transparencia y que reducen el costo de los procesos eleccionarios entiendan de una vez que no hay soluciones mágicas (algo que deberían saber sobradamente) y que este tipo de sistemas no sólo no contribuye a la solución, sino que agrava los problemas (y presenta algunos bastante novedosos).

Según la concejal Yawny, el voto electrónico:

“… es un método mucho más seguro, hace a un acto eleccionario transparente y eficaz, con resultados inmediatos y contribuye a mejorar la calidad institucional y legitimar la representación del sistema democrático; es un sistema con muchas ventajas por sobre el tradicional, no sólo porque tiende a erradicar el clientelismo y las prácticas fraudulentas, sino también porque genera igualdad de oportunidades …”

Tales afirmaciones sólamente pueden provenir de alguien profundamente desinformado o extremadamente malintencionado. (En virtud de otros proyectos presentados por la autora y de mi consabida ingenuidad, me decanto por la primera opción.)

Mientras intento conseguir un ejemplar impreso del libro Voto Electrónico: Los riesgos de una ilusión para acercárselo a la concejal, dejo aquí un capítulo que resume los principales problemas y riesgos de la “solución mágica” que tantos promueven hoy en día por estas pampas, sin tener la más remota sospecha del berenjenal en que se (nos) están metiendo.

Actualización: Para complementar el tratamiento de este tema, he publicado un artículo con un excelente documental.

Principales problemas detectados

Beatriz Busaniche y Federico Heinz
(Fundación Vía Libre)

Este artículo está incluido en el libro "Voto Electrónico: Los riesgos de una ilusión", que se encuentra bajo una Licencia Creative Commons Atribución-Compartir Obras Derivadas Igual-2.5-Argentina.

Los sistemas de voto electrónico (en el sentido usado en este libro) suelen venir de la mano de contundentes afirmaciones acerca de sus virtudes, tales como una mayor transparencia del acto electoral, la eliminación del clientelismo político, la rapidez e infalibilidad del conteo, el menor costo de cada elección, y la mayor participación ciudadana.

Lamentablemente, estas afirmaciones categóricas no vienen acompañadas de datos sólidos que las sustenten, y algunas empresas proveedoras invierten un esfuerzo nada despreciable en evitar que sean verificadas por terceras partes independientes, como fue el caso de Sequoia Systems en 2008, que intentó impedir una auditoría independiente de seguridad encomendada por el estado de Nueva Jersey argumentando que llevarla a cabo violaría los términos de uso del software que controla las urnas [1].

De hecho, ninguna de esas afirmaciones soporta un análisis profundo y, si bien algunas de ellas pueden ser ciertas para algunos casos particulares, la experiencia internacional demuestra que en la realidad están muy lejos de reflejar el verdadero desempeño de las urnas electrónicas.

Transparencia

La afirmación de que las urnas electrónicas aportan a la transparencia del comicio es, probablemente, la más aventurada. Es difícil comprender cómo un proceso opaco se haría más transparente mediante el recurso de agregarle una “caja negra”. Lejos de aportar a la transparencia, la urna electrónica obstaculiza la capacidad de la mayoría de los ciudadanos de fiscalizar la elección.

Cualquier persona sabe cómo verificar, con sólo mirarla, que una urna está vacía o que un precinto de seguridad está intacto, y el sistema educativo apunta a garantizar que todas las personas sepan leer, escribir y contar. Pero estas habilidades son inútiles a la hora de ver qué pasa "dentro" de una urna electrónica: la inspección ocular no sirve para ver si está vacía sino que es necesario usar un programa diseñado a tal fin, que imprima un ticket que diga "sí, estoy vacía". ¿Podemos creerle?

Cuando la urna imprime los resultados, los obtiene de operar sobre sus registros internos, almacenados en medios magnéticos que los fiscales no pueden leer por sus propios medios. La única "comprobación" posible de que la urna está efectivamente vacía, o de que los totales son correctos, es repetir la operación, la que previsiblemente dará siempre el mismo resultado. Aún si confiáramos en que el programa de la urna es correcto, el fiscal promedio carece de los conocimientos y las herramientas necesarios como para comprobar si el programa que está instalado en la urna ha sido adulterado o no.

Incluso un fiscal con grandes conocimientos de programación y electrónica digital, provisto de herramientas especializadas, probablemente demoraría días en verificar con algún grado de confianza que la urna está efectivamente "en cero", mientras que hacerlo con el mismo grado de confianza con el que puede hacerse inspeccionando el interior de una urna de cartón es efectivamente impracticable: se trata de un problema de la misma complejidad que la construcción de programas de computadora libres de errores, algo que el estado del arte aún no nos permite. Para peor, las acciones que debería realizar este hipotético auditor especializado son mucho más invasivas que las necesarias para adulterar el funcionamiento de la urna, de modo que, suponiendo que nos diga que la urna está "limpia", no sólo no va a poder demostrárselo a alguien que no esté similarmente especializado, sino que no tenemos manera de saber si lo que hizo, en realidad, fue verificarla o subvertirla.

Este es un problema fundamental de las urnas electrónicas: mientras la verificación de su confiabilidad dependa exclusivamente de comprobar que "funciona bien", la tarea de su fiscalización queda necesariamente en manos de una élite tecnológica, a la que el resto de la población no tiene más remedio que creerle. Para corromper la fiscalización de una elección basada en papel, es necesario contar con fiscales corruptos en un número importante de mesas, pero en el caso de las urnas electrónicas basta con sobornar o extorsionar a un grupo pequeño de personas fácilmente identificables.

Estas dificultades a menudo son desestimadas, argumentando que se pueden realizar elecciones de prueba controladas para ver cómo se comporta la urna, y señalando que estas urnas se han usado en muchos lugares sin problemas. Lamentablemente, este argumento ignora el hecho de que es muy sencillo programar la máquina de modo que no se comporte de la misma manera durante las pruebas que durante la elección, y que la experiencia demuestra que en la mayoría de las elecciones, la necesidad de actualizar el software (ya sea el mismo software de la urna o su sistema operativo) lleva a que el programa que corre durante la elección puede no ser el mismo que se usó durante las pruebas.

Por lo demás, la afirmación de que estas urnas han sido usadas sin problemas es harto aventurada: no sabemos si hubo problemas o no, precisamente porque la opacidad del mecanismo no nos permite comprobarlo adecuadamente. Es perfectamente posible que en esas elecciones haya habido problemas masivos, sin que nadie haya podido probarlo y ese es precisamente el escenario que las urnas electrónicas facilitan. De hecho, hay elecciones como las de EEUU en 2004, en las que las diferencias entre las encuestas en boca de urna y los resultados finales sugieren fuertemente que las urnas dieron resultados incorrectos.

El fin del clientelismo

El clientelismo político es un problema social, económico y educativo que no se soluciona con tecnología.

Para que la "compra de votos" funcione, es necesario contar con un mecanismo que permita al comprador un grado importante de confianza en que el votante efectivamente votará por el candidato al que prometió votar. En las elecciones en papel, esto puede hacerse a través del denominado "voto en cadena", mecanismo que algunos sistemas de voto electrónico hacen efectivamente imposible.

Pero pensar que el voto en cadena y el clientelismo son lo mismo es un error: el voto en cadena es sólo un mecanismo de romper el secreto del voto. No es el único, y las urnas electrónicas ofrecen mecanismos alternativos potencialmente mucho más eficaces. Esto se debe a la naturaleza fundamentalmente distinta de las urnas electrónicas. Por ejemplo, mientras que las urnas normales son contenedores pasivos, de información, los circuitos de la urna electrónica emiten radiación electromagnética.

Experimentos realizados en Holanda demostraron que estas emisiones hacían posible detectar por quién votaba una persona desde una distancia de 25 metros, usando sólo dispositivos disponibles comercialmente.

En el estado de Ohio se descubrió, dos años después de usarlas, una grave falencia en las urnas electrónicas que permite violar el secreto del voto luego de los comicios: los reportes emitidos por la urna al final del recuento permiten reconstruir el vínculo entre voto y votante. Este caso es particularmente grave, porque ilustra un aspecto a menudo ignorado del cálculo de riesgo a la hora de usar una urna electrónica: el hecho de que no conozcamos vulnerabilidades en la urna no quiere decir que no existan, ni que nadie las conozca. Alguien que estuviera en conocimiento de esta vulnerabilidad hubiera podido organizar una compra o extorsión masiva de votos que hubiera sido indetectable y requerido un esfuerzo logístico mucho menor que el voto en cadena.

La rapidez del conteo

Una de las escasas ventajas promocionadas que podría ser verificable es la rapidez en el conteo. De hecho, cuando todo sale bien, los resultados pueden ser inmediatos. El problema surge cuando evaluamos el impacto potencial de las distintas cosas que pueden salir mal. Mientras que en la urna de papel, la influencia de un inconveniente es por lo general proporcional a la magnitud de éste, en las urnas electrónicas un problema muy pequeño puede tener consecuencias muy graves. Esto lleva a que si los resultados de la urna electrónica no son inmediatos, por lo general no se los puede obtener nunca. Por lo general, no hay nada al medio.

El 16 de diciembre de 2007, por ejemplo, se utilizaron cuatro urnas electrónicas de la firma Altec Sociedad del Estado (Río Negro) en la localidad de Las Grutas, en Argentina. Transcurrida la jornada electoral, una de esas urnas arrojó un resultado sorprendente: 0 votos. Fue afortunado que en este caso las urnas hayan llevado registro en papel, porque el registro digital se había perdido completamente, pero aún así el escrutinio demoró horas, porque los votos impresos sobre una tira de papel eran mucho más difíciles de identificar que las boletas originales. La única explicación de la empresa proveedora de la urna fue que "alguien debe haber sacudido la urna".

De la misma manera, existen casos en los que una falla técnica en una urna electrónica produjo que la urna contara miles de votos en mesas en las que votaban sólo cientos de personas, o el reciente caso de Nueva Jersey, en el que los resultados fueron inmediatos, pero el total de votos emitidos no coincidía con la suma de los votos emitidos por partido. ¿Puede decirse que ese resultado es inmediato, cuando en realidad es evidentemente incorrecto? [2]

La rapidez, sin confianza ni seguridad, no sirve para mucho en un proceso electoral. Esta es un área en la que la eficacia (hacerlo bien) debe primar por sobre la eficiencia (hacerlo rápido).

La economía

La idea de que usar urnas electrónicas permite economizar dinero en los comicios ha sido refutada por auditores independientes que la pusieron a prueba. En el Estado de Maryland, por ejemplo entre 2002 y 2003 se compraron 19 mil máquinas de pantalla táctil a la firma Diebold. Para poder concretar la compra, el Estado tomó un crédito de 67 millones de dólares, 44 de los cuales fueron a las arcas de la empresa en concepto de compra y mantenimiento de las urnas. Antes de incorporar estos dispositivos, Maryland usaba un sistema de escaneo óptico.

Según el informe de la organización Save Our Votes, publicado en febrero de 2008 [3], el cambio de tecnologías implicó un aumento promedio de 179% en el costo total por votante. En uno de los condados, el aumento fue de 866%.

Por cierto, las máquinas de Diebold aún no se terminaron de pagar y ya deben ser renovadas. El Estado de Maryland está considerando volver al sistema de escaneo óptico.

La participación ciudadana

Un tema crítico a la hora de evaluar la implementación de voto electrónico es la participación ciudadana. Nuestras democracias modernas están golpeadas por el descrédito de las clases dirigentes y la falta de confianza en los sistemas políticos. El halo de modernidad que otorga el voto electrónico parece ser la panacea para entusiasmar a los votantes para participar en los comicios.

Sin embargo, es importante destacar que la incorporación de urnas electrónicas tiene efectos claramente contrarios al objetivo de mejorar la participación ciudadana. Sin ir más lejos, las personas poco afines con los sistemas computacionales serán los primeros excluidos: adultos mayores o personas de escasos recursos, personas con dificultades visuales o con bajísimo nivel educativo que hoy día no requieren mayor preparación para elegir una boleta, ponerla en una urna y emitir su voluntad política, se verán enfrentados a un sistema mucho más complejo para votar.

Pero este no es el único inconveniente. Quizás el mayor de los problemas es que aquellos que hoy auditan las elecciones en nuestro nombre (maestras de escuela, empleados públicos, fiscales de partidos políticos) se verán incapaces de auditar eficazmente un sistema de esta naturaleza. Sólo personas altamente calificadas en ingeniería de software, electrónica y hardware podrán comprender el funcionamiento de estos sistemas. Aún personal calificado en seguridad de sistemas de información se manifiesta incapaz de evaluar, validar y corroborar el funcionamiento correcto de urnas electrónicas. Estos mismos expertos difícilmente se atrevan a firmar a conciencia una certificación de seguridad de las urnas pues no existe método formal de validación que los avale.

Así, la participación real y tangible de la ciudadanía se verá reducida a la confianza ciega en un pequeño número de fiscales informáticos que, aún teniendo amplios conocimientos de la materia, no podrán certificar la validez de un resultado en el que todos los demás tendremos que confiar. Aquellos que tenemos la voluntad política de ejercer nuestro derecho a auditar nos veremos limitados por carecer de conocimientos técnicos, y tendremos que dejar la participación real a una pequeña elite de técnicos autorizados.

Si bien no existen sistemas perfectos, la diferencia de impacto es sustancial. Una mesa de votación tradicional puede registrar inconvenientes y ser anulada. El impacto sobre los resultados globales será mínimo. Sin embargo, un error mínimo en un sistema de votación electrónica puede alterar el resultado de una elección simultáneamente en un gran número de mesas.

Problemas generales

A todo esto vale agregar que, en la gran mayoría de los casos, los proveedores de urnas electrónicas son empresas privadas cuya composición accionaria deberíamos conocer en detalle antes de confiarles un proceso público y ciudadano como es la emisión del voto. ¿Cuáles serán los mecanismos para auditar a las empresas proveedoras?

¿Cómo sabremos cuáles son sus vinculaciones políticas y sus intereses en cada elección? ¿Estamos dispuestos a privatizar un proceso ciudadano como el acto de votar?

Estas preguntas surgen a la luz de escándalos ocurridos en los EEUU donde, por ejemplo, uno de los principales accionistas de una de las empresas proveedoras de urnas (ES&S) resultó ser un senador republicano con obvios y marcados intereses en el resultado electoral. [4]

No son pocos los inconvenientes que aparecen a la hora de evaluar la automatización de la emisión del voto. Sin embargo, es muy poco lo que se discute y ciertamente escaso el conocimiento sobre los mismos. El acto de votar es lo suficientemente importante como para que nos ocupemos de este tema, y nos preocupemos frente a incorporaciones acríticas de tecnología que, lejos de mejorar nuestras democracias, son amenazas al derecho esencial de la ciudadanía a votar en condiciones de secreto, transparencia y seguridad.

Notas

1. http://freedom-to-tinker.com/blog/felten/interesting-email-sequoia
2. http://freedom-to-tinker.com/blog/felten/evidence-new-jersey-election-discrepancies
3. http://www.saveourvotes.org/legislation/2008/08-costs-mdvotingsystem.pdf
4. http://www.scoop.co.nz/stories/HL0301/S00166.htm

Gracias, mi muchacho, por sorprenderme todos los días. ¡Felices diez años!

Aún haciendo caso omiso del pobre nivel de seguridad que ofrecen los productos de Microsoft (ya insuficiente para el uso que puede darles mi tía, ni que hablar de sistemas militares), es increible que las fuerzas armadas de un país decidan adoptar como plataforma para sus comunicaciones, sistemas privativos (de código cerradísimo), producidos por una empresa extranjera y sobre los cuales recaen varias sospechas respecto de la intromisión de los servicios de inteligencia de los EE.UU.

Y no sólo eso. El asunto parece ser tan notable, que hasta ha sido publicado por Microsoft como “caso de éxito”. (Es hasta gracioso ver el detalle completo de programas y versiones utilizados, algo que cualquier especialista en seguridad tendría reparos en publicar, tratándose de sistemas militares).

Cuando empecé a leer el artículo, tuve la tentación de extraer y comentar algunas afirmaciones (por lo general de integrantes de las Fuerzas Armadas) que reflejan un avanzado grado de estupidez. Desistí de ello, ya que hubiera terminado copiando casi textualmente el boletín de Microsoft.

Por lo tanto, me limitaré a reproducir aquí el copete del artículo:

El Estado Mayor Conjunto de las Fuerzas Armadas de la República Argentina, está implementando una plataforma de comunicaciones y colaboración en tiempo real, que lo coloca a la vanguardia, en la región. Sobre un ambiente nativo Microsoft Windows Server 2008 R2 y con la integración de Microsoft Exchange Server 2007, Office Communications Server 2007 y Office system 2007, el Centro de Operaciones Conjunto, materializado en la Sala de Mando y Control y el estándar de Escritorio Operacional definido para determinadas Autoridades-Usuarios; provee una infraestructura versátil, segura, confiable, fiable y de múltiples prestaciones en tiempo real, que mejoran cualitativamente el desempeño de sus funciones y potencian las facilidades disponibles tanto en el territorio nacional como en los lugares donde nuestro país tiene Organizaciones Militares de Paz en el exterior.

Las más recientes implementaciones resultan innovadoras en grado sumo, ya que logran identificación unívoca de usuarios, presencia enriquecida, modalidades de conexión y vías de comunicación unificadas, disponibilidad contextual y universal. Se dispone de mensajería instantánea encriptada y propietaria, de un servicio de conferencia entre varios interlocutores, que permite compartir aplicaciones entre muchas otras prestaciones que reducen muy considerablemente (en el orden del 80%) el tiempo de gestión operacional, enriqueciendo verdaderamente las comunicaciones y obteniendo una importantísima reducción de los costos operativos (más de 75%).

Que nuestros los militares son imbéciles (eso de “inteligencia militar” desde siempre fue una contradicción en términos) ya lo sabemos de hace rato. Que el Estado Mayor Conjunto argentino gusta acomodarse bajo las suelas de los EE.UU también es una perogrullada. Pero… entregar así el control de la información y de los sistemas de comunicaciones con anuncios, bombos y platillos incluidos, es realmente paralizante..

Me viene a la mente el eslogan utilizado en las publicidades del actual gobierno argentino, con la Dra. Cristina Fernandez de Kirchner a la cabeza: “Esto también lo hiciste vos“. Me paraliza todavía más pensar que pueda ser cierto.

Spolsky alerta sobre la creciente tendencia de muchas universidades a sobre-simplificar la currícula de las carreras de Ciencias de la Computación (con Java como “lenguaje insignia”), con el único objetivo de producir mayor cantidad de egresados y en menos tiempo. La consecuencia es directa: cada vez más abundan programadores que poco entienden de conceptos de programación (corrección, recursión, complejidad, paralelismo, entre tantos otros) y para los cuales los mecanismos “internos” de los sistemas informáticos (gestión de memoria, interacción con el sistema operativo, comunicación entre procesos, etc.) son completamente esotéricos.

El principal impulsor de este embrutecimiento es cierto sector de la llamada “Industria del Software” que requiere de mano de obra barata y de pobre formación, y empuja a las instituciones educativas a proveerles “recursos” tan rápido y en tanta cantidad como sea posible (ni qué decir de las instituciones educativas que ceden a esta presión).

Nadie está en contra de hacer la tarea del programador más simple, ni mucho menos de la evolución de los lenguajes y las metodologías de desarrollo de software. Lo que se reprocha aquí es la negación de la realidad como forma de evasión. Esto es: la necesidad de dotar a los programadores de ciertos conceptos, aún cuando esto provoque la deserción de quienes no puedan llegar a dominarlos (y mal que le pese al referido sector de la “Industria”).

Los Riesgos de las Universidades-Java

por Joel Spolsky
Jueves 29 de diciembre de 2005

Chicos perezosos.

¿Qué pasó con el trabajo duro?

Un seguro indicio de mi decadencia hacia la senilidad son mis continuas quejas y lamentos sobre “los chicos de hoy”, y cómo ya no quieren o no pueden hacer cosas difíciles.

Cuando yo era un muchacho, aprendí a programar con tarjetas perforadas. En esos tiempos si cometías un error, no tenías ninguna de esas modernas funciones como la tecla “backspace” para corregirlo. Tenias que tirar la tarjeta y empezar todo de nuevo.

Cuando empecé a entrevistar programadores en 1991, les dejaba usar generalmente cualquier lenguaje que quisieran para resolver los problemas de programación que les planteaba. El 99% de las veces, ellos elegían C.

Ahora ellos tienden a elegir Java.

No me malinterpreten: no hay nada malo con Java como lenguaje de implementación.

Un momento, quiero rectificar eso último. No digo, en este artículo en particular, que haya algo de malo con Java como lenguaje de implementación. Hay un montón de cosas mal con Java, pero tendrán que esperar hasta otro artículo.

En cambio, lo que quiero decir es que Java no es, generalmente, un lenguaje de programación lo suficientemente difícil para que pueda ser usado para distinguir entre excelentes programadores y programadores mediocres. Puede ser un buen lenguaje para trabajar, pero ese no es el tema de hoy. Puedo ir incluso mas allá y decir que el hecho de que Java no sea lo suficientemente difícil es una característica, no un bug, pero que tiene ese problema.

Si puedo ser atrevido, diría que en mi humilde experiencia han sido dos las cosas tradicionalmente enseñadas en las universidades como parte de la carrera de Ciencias de la Computación (CS) las que mucha gente nunca llega realmente a comprender: punteros y recursión.

En aquellos tiempos lo normal era empezar la universidad con un curso de estructuras de datos, con listas enlazadas, tablas hash y, por qué no, con un uso intensivo de punteros. Esos cursos eran frecuentemente usados como filtros: eran tan difíciles que cualquiera que no pudiera soportar el desafío mental de un grado en CS se daría por vencido, lo que era bueno, porque si piensas que los punteros son difíciles, espera hasta intentar probar cosas en teoría de punto fijo.

Todos esos chicos que lo habían hecho muy bien en la secundaria escribiendo juegos de “pong” en BASIC para su Apple II, iban a la universidad, tomaban el curso CompSci 101, sobre estructuras de datos, y cuando llegaban al asunto de los punteros, sus cerebros estallaban completamente; y lo próximo de lo que tenías noticias es que estaban especializándose en Ciencias Políticas, porque la escuela de leyes parecía ser una mejor idea. He visto todo tipo de de índices de deserción en CS y usualmente están entre el 40% y el 70%. Las universidades tienden a ver esto como un derroche; yo creo que es sólo la poda necesaria de gente que no va a ser feliz o exitosa en una carrera de programación.

El otro curso difícil para muchos jóvenes estudiantes de CS era el curso donde aprendías programación funcional, incluyendo programación recursiva. MIT puso una barrera muy alta en esos cursos, creando un curso obligatorio (6.001) y un libro de texto (Estructura e Interpretación de Programas de Computadora de Abelson y Sussman, el cual era usado en docenas o quizás cientos de carreras de CS prestigiosas como el estándar de facto para la introducción a las Ciencias de la Computación. (Puedes, y deberías echarle una ojeada a la antigua versión de las clases en línea).

La dificultad de esos cursos es asombrosa. En la primera clase has aprendido casi todo Scheme, y ya has sido introducido a la función de punto fijo que toma otra función como parámetro. Cuando me esforzaba en pasar un curso similar, CSE121 en Penn, observaba cómo muchos sino la mayoría de los estudiantes simplemente no lo lograba. La materia era muy difícil. Inclusive escribí un largo email de lloriqueando a mi profesor diciendo que “simplemente no era justo”. Alguien en Penn debe haberme escuchado (o a alguno de los otros llorones), porque ese curso se dicta ahora con Java.

Desearía que no hubiesen escuchado.

Aquí radica el quid del debate. Años de lloriqueo de estudiantes perezosos como yo, combinados con quejas de la industria acerca de cuan pocos graduados en CS salen de las universidades americanas, han pagado su precio, y en la ultima década un gran numero de otrora perfectamente buenas universidades se han vuelto 100% Java. Esta de moda, a los reclutadores que usan “grep” parece gustarles, y, lo mejor de todo, no hay nada lo suficientemente difícil en Java como para filtrar aquellos programadores sin la parte del cerebro que entiende punteros y recursión. Así es que la deserción es menor, y los departamentos de ciencias de la computación tienen mas alumnos y mayores presupuestos y todo está bien.

Los afortunados chicos de esas Universidades-Java nunca van a toparse con raros fallos de segmentación tratando de implementar tablas hash basadas en punteros. Nunca se van a volver locos tratando de empaquetar cosas en bits. Nunca tendrán que ocupar sus cabezas en cómo en un lenguaje puramente funcional, el valor de una variable nunca cambia, y aun así, ¡cambia todo el tiempo! ¡Una paradoja!

Ellos no necesitan esa parte del cerebro para obtener un 4 en la materia.

¿Soy sólo uno de esos viejos cascarrabias anticuados, vanagloriándose acerca de cuán duro era sobrevivir a todas esas dificultades?

Rayos, en 1900, el Latín y el Griego eran asignaturas requeridas en la universidad, no porque sirvieran de algún propósito, sino porque de alguna manera eran considerados un requisito obvio de la gente educada. De cierta manera mi argumento no es diferente del argumento expuesto por la gente pro-Latín: “[El Latín] entrena tu mente. Entrena tu memoria. Desembrollar una sentencia en Latín es un excelente ejercicio del pensamiento, un verdadero acertijo intelectual y una buena introducción al pensamiento lógico”, escribe Scout Barrer. Pero ya no puedo encontrar una sola universidad que requiera Latín. ¿Son los punteros y la recursión el Latín y el Griego de las ciencias de la computación?

Ahora, admito que programar con punteros no es necesario en el 90% del código escrito en la actualidad, y de hecho es totalmente peligroso en el código de producción. OK. Está bien. Y que la programación funcional no es muy empleada en la práctica. De acuerdo.

Pero todavía sigue siendo importante para algunos de las tareas más excitantes en programación. Sin punteros, por ejemplo, nunca serías capaz de trabajar en el Kernel de Linux. No puedes entender una sola línea del código de Linux, o de hecho, de cualquier sistema operativo, sin realmente entender punteros.

Sin entender programación funcional, no podrás inventar MapReduce, el algoritmo que hace Google tan masivamente escalable. Los términos Map y Reduce vienen de Lisp y la programación funcional. MapReduce es, en retrospectiva, obvio para cualquiera que recuerde de su clase equivalente a 6.001 que los programas puramente funcionales no tienen efectos colaterales y por ende son trivialmente paralelizables. El simple hecho que Google inventara MapReduce, y no Microsoft, dice algo del por qué Microsoft está aun jugando a lograr que funcionen algunas características básicas de búsqueda, mientras Google se ha movido ya al siguiente problema: construir Skynet^H^H^H^H^H^H, la mayor supercomputadora masivamente paralela del mundo. Simplemente no creo que Microsoft entienda completamente cuan retrasados están en ese campo.

Pero mas allá de la importancia a simple vista de los punteros y la recursión, su valor real radica en que construir grandes sistemas requiere del tipo de flexibilidad mental que adquieres aprendiéndolos, y de la actitud mental que necesitas para no huir de los cursos en donde son enseñados. Punteros y recursión requieren cierta habilidad para razonar, para pensar en abstracciones, y más importante, para ver un problema en diversos niveles de abstracción simultáneamente. Por lo tanto, la habilidad para entender punteros y recursión esta directamente correlacionada con la habilidad de ser un gran programador.

No hay nada en grado académico 100% Java que realmente descarte a los estudiantes que carecen de la agilidad mental para tratar con esos conceptos. Como empleador, he visto que las Universidades 100% Java han empezado a producir en serie una buena cantidad de graduados quienes simplemente no son lo suficientemente listos para trabajar como programadores en nada mas sofisticado que “Sólo Otra Aplicación Contable en Java”, aunque se las han arreglado para colarse a través de la (ahora simplificada) carrera. Esos estudiantes nunca sobrevivirían al 6.001 del MIT o al CS 323 en Yale y, francamente, esa es una razón por la cual, como empleador, un título en CS del MIT o Yale tiene más peso que uno de Duke, que recientemente se hizo 100%-Java, o de Penn, donde remplazaron Scheme y ML por Java tratando de enseñar la materia que casi nos mata a mis compañeros y a mi, CSE121. No es que no quiera contratar chicos listos de Duke o Penn, lo hago, es sólo que es mucho más difícil para mí darme cuenta de cuáles son. Yo estaba acostumbrado a decir que los chicos listos eran aquellos que podían desmenuzar un algoritmo recursivo en segundos, o implementar funciones de manipulación de listas enlazadas usando punteros tan rápido como podían escribir en la pizarra. Pero con graduado sde Universidades-Java, no puedo saber si padecen esos problemas a causa de haber sido mal educados o si los padecen porque realmente carecen de esa parte del cerebro que van a necesitar para ser buenos programadores en el trabajo. Paul Graham los llama “Blub Programmers“.

Ya es bastante malo que las Universidades-Java fallen en filtrar los chicos que nunca van a ser buenos programadores, algo que las universidades podrían justificablemente decir que no es su problema. Después de todo es la industria, o al menos los reclutadores-que-usan-grep, quien está pidiendo a gritos que se enseñe Java.

Pero las Universidades-Java fallan también en entrenar las mente de los chicos para ser hábiles, ágiles y lo suficientemente flexibles para lograr buen diseño de software (y no me refiero al “diseño” OO, donde gastas incontables horas acomodando tu jerarquía de objetos, o preocupándote de “problemas” superfluos como “tiene-un” vs. “es-un”). Necesitas entrenamiento para pensar en las cosas a varios niveles de abstracción simultáneamente, y ese tipo de pensamiento es exactamente lo que necesitas para diseñar excelentes arquitecturas de software.

Puedes estar preguntándote si la enseñanza de programación orientada a objetos (OOP) es un buen sustituto de los punteros y la recursión para el filtrado. La respuesta rápida: no. Sin debatir acerca de los meritos de la OOP, simplemente no es lo suficientemente difícil para filtrar a los programadores mediocres. OOP en las universidades consiste básicamente en memorizar un puñado de términos de vocabulario como “encapsulacion” y “herencia” y tomar exámenes del tipo “multiple-choice” acerca de las diferencias entre polimorfismo y sobrecarga. No más difícil que memorizar fechas destacadas y nombres en una clase de historia, la OOP tiene desafíos mentales inadecuados para espantar a los estudiantes de primer año. Cuando te enfrentas con un problema de OOP, tu programa aun funciona, sólo que es algo difícil de mantener. Supuestamente. Pero cuando te enfrentas a un problema con punteros, tu programa produce línea Fallo de segmentación y no tienes ni la menor idea de lo que está pasando, hasta que te paras, tomas una fuerte bocanada de aire y tratas de forzar tu mente a trabajar en dos diferentes niveles de abstracción simultáneamente.

Los reclutadores-que-usan-grep, de hecho, son ridiculizados aquí, y por un buen motivo. Nunca he conocido alguien que pueda usar Scheme, Haskell y punteros en C, que no pueda entender Java en dos días, y crear mejor código en Java que gente con cinco años de experiencia en Java. Pero trata de explicar eso al zombie de Recursos Humanos.

¿Pero que hay de la misión del compromiso con las CS de las facultades de CS? ¡Ellas no son escuelas vocacionales! No debería ser su trabajo entrenar gente para trabajar en la industria. Eso queda para los terciarios y los programas de capacitación del gobierno para trabajadores desplazados, dirán. Ellas se suponen que están para dar a los estudiantes las herramientas fundamentales para vivir sus vidas, no para prepararlos para sus primeras semanas de trabajo. ¿No es cierto?

Aun así, las CS son demostraciones (recursión), algoritmos (recursión), lenguajes (cálculo lambda), sistemas operativos (punteros), compiladores (cálculo lambda), y entonces la conclusión es que la Universidad-Java que no enseña C y no enseña Scheme, tampoco está enseñando realmente ciencias de la computación. Tan inútil como el concepto de currificación de funciones puede serle al mundo real, es un obvio prerrequisito para un graduado en CS. No puedo entender por qué los profesores en las comisiones curriculares de las facultades de CS han permitido que sus programas sean embrutecidos a tal punto que no sólo no pueden producir programadores operativos, sino que ya ni siquiera pueden producir graduados en CS que puedan obtener PhDs y puedan competir por sus puestos de trabajo. Oh, esperen. No importa. Quizás entienda.

Si volvemos en el tiempo y analizamos las discusiones que tomaron lugar en el mundo académico durante el “Gran Levantamiento Java”, encontraremos que la mayor preocupación fue que Java no era lo suficientemente simple para ser usado como un lenguaje de enseñanza.

Mi Dios, pensé, ¡están tratando de embrutecer la curricula aun mas! ¿Por que mejor no le llevamos la comida a la boca a los estudiantes? Dejemos que los ayudantes de cátedra den los exámenes por ellos también, entonces nadie se cambiara a Estudios Americanos. ¿Cómo se supone que alguien aprenderá algo si la curricula ha sido cuidadosamente diseñada para hacer todo más fácil de lo que ya es? Parece haber una comisión de trabajo (PDF) intentando idear un subconjunto simple de Java que pueda ser enseñado a estudiantes, produciendo documentación simplificada que esconde cuidadosamente toda esa basura EJB/J2EE de sus tiernas mentes, de manera tal que no tengan que preocupar sus cabecitas con otras clases que no necesiten para resolver sus aun más fáciles problemas de CS.

La interpretación mas compasiva de por qué las facultades CS son tan entusiastas en embrutecer sus clases es porque ello les dará más tiempo para enseñar verdaderos conceptos de CS, así no necesitaran dos clases enteras para esclarecer a los alumnos las diferencias entre, digamos, un int y un Integer en Java. Bueno pero si ese fuera el caso, 6.001 tiene la respuesta perfecta: Scheme, un lenguaje de enseñanza tan simple que el lenguaje entero puede enseñarse a estudiantes brillantes en unos 10 minutos; entonces puedes gastar el resto del semestre enseñando puntos fijos.

Fiu…

Voy a regresar a los unos y ceros.

(¿Te tocaron unos? ¡Bastardo suertudo! A nosotros nos tocaron todos ceros.)

Esta traducción está basada en la versión disponible en el Wiki de Joel Spolsky, corregida y adaptada por mí.

Dijkstra es reconocido como uno de los pioneros de las Ciencias de la Computación por sus abundantes aportes, tanto en el área teórica como en la práctica. Resulta ser que, además de un notable científico, también fue un gran visionario. Una muestra de ello es el artículo aquí reproducido, publicado originalmente en el año 1975.

Realmente es penoso ver que, aún 35 años después, muchos siguen sin caer en la cuenta de cuestiones que ya en aquella época resultaban evidentes.

¿Cómo decimos verdades que pueden lastimar?

A veces descubrimos verdades desagradables. Cada vez que lo hacemos, estamos en dificultades: suprimirlas es científicamente deshonesto, por lo que tenemos que decirlas; pero diciéndolas, sin embargo, se volverán en nuestra contra. Si las verdades son lo suficientemente desagradables, nuestro público será psíquicamente incapaz de aceptarlas y seremos tachados de irrealistas, idealistas sin remedio, peligrosamente revolucionarios, tontamente crédulos o lo que sea. (Además de eso, decir tales verdades es una forma segura de volverse impopular en muchos círculos, y como tal, es un hecho que en general no está exento de riesgos personales. Recordemos a Galileo Galilei…)

Las Ciencias de la Computación parecen sufrir gravemente este conflicto. En general, se mantienen silenciosas y tratan de escapar del mismo desviando la atención. (Por ejemplo: con respecto a COBOL se puede hacer sólo una de dos cosas: luchar contra la enfermedad o pretender que no existe. La mayoría de los departamentos de Ciencias de la Computación han optado por la última como una salida más fácil). Pero, hermanos, os pregunto: ¿es honesto? ¿No está nuestro prolongado silencio corrompiendo la integridad intelectual de las Ciencias de la Computación? ¿Es decente premanecer en silencio? Si no, ¿cómo podemos hablar?

Para que se haga una idea de la magnitud del problema, he enumerado una serie de tales verdades. (Casi todos los científicos de computación que conozco bien estarán de acuerdo sin dudarlo con casi todas ellas. Sin embargo, permitimos que el mundo se comporte como si no las conociéramos…)

• La programación es una de las ramas más difíciles de las matemáticas aplicadas, los pobres matemáticos mejor hubieran seguido siendo matemáticos puros.
• Las aplicaciones de computadora más fáciles son los cálculos técnicos/científicos.
• Las herramientas que usamos tienen una profunda (¡y retorcida!) influencia en nuestros hábitos de pensamiento y, por lo tanto, en nuestra habilidad de pensar.
• FORTRAN -”la enfermedad infantil”-, actualmente con casi 20 años de edad, es completamente inadecuado para cualquier aplicación informática que tenga en mente hoy: es demasiado torpe, demasiado arriesgado y demasiado costoso.
• PL / I -”la enfermedad fatal”- pertenece más al conjunto de los problemas que al de las soluciones.
• Es prácticamente imposible enseñar buena programación a estudiantes que han tenido exposición previa al BASIC: como programadores potenciales están mentalmente mutilados sin esperanza de regeneración.
• El uso de COBOL incapacita la mente, y su enseñanza debe, por tanto, ser considerada como un delito penal.
• APL es un error, llevado a cabo a la perfección. Es el lenguaje del futuro para técnicas de programación del pasado: crea una nueva generación de inútiles de la programación.
• Los problemas de administración de empresas en general y de gestión de bases de datos, en particular, resultan mucho más complicados para las personas que piensan en IBMés, compuesto con un Inglés desalineado.
• Sobre el uso del lenguaje: es imposible para afilar un lápiz con una cuchilla desafilada. Es igualmente inútil tratar de hacerlo con diez cuchillas desafiladas.
• Además de una inclinación matemática, un dominio excepcional de la lengua nativa es el activo más vital de un programador competente.
• Muchas compañías que se han vuelto dependientes de equipamiento IBM (y al hacerlo, han vendido su alma al diablo) se derrumbará bajo el peso de la complejidad incontrolada de sus sistemas de procesamiento de datos.
• No podemos encontrar ninguna disciplina científica, ni una profesión robusta, basada en los errores técnicos del Departamento de Defensa y, principalmente, un fabricante de computadoras.
• El uso de la terminología antropomórfica cuando se trabaja con sistemas de computación es un síntoma de inmadurez profesional.
• Afirmando que pueden contribuir a la ingeniería de software, los científicos blandos se vuelven aún más ridículos. (No menos peligrosos, ¡ay!). A pesar de su nombre, la ingeniería de software requiere (cruelmente) el soporte de la ciencia dura.
• En los buenos viejos tiempos los físicos repetían los experimentos de los demás, simplemente para estar seguros. Hoy se apegan a FORTRAN, de modo que puedan compartir los programas de cada uno, errores incluidos.
• Los proyectos que promueven la progamación en “lenguaje natural” están intrínsecamente condenados al fracaso.

¿No es esta lista suficiente para hacernos sentir incómodos? ¿Qué vamos a hacer? Volver a la orden del día, presumiblemente…

18 de junio 1975
Plataanstraat 5
Nuenen – 4565
Holanda

Prof. Dr. Edsger W. Dijkstra
Burroughs Research Fellow

PD: Si la conjetura “Usted hubiera preferido que no lo molestara enviándole esto” es correcta, puede añadirla a la lista de verdades incómodas.

Gracias, hija, por estos once años. ¡Feliz cumple!

Esta visión, lentamente, está cambiando. Por un lado, las historias de aquellos que hicieron una fortuna (o establecieron una posición económica) mediante la venta de licencias de un programa son, a la vez, cada vez más lejanas y menos frecuentes. Pero, si empezamos a vernos a nosotros mismos también como consumidores de software, el razonamiento cambia radicalmente.

Comparemos

Tomemos como ejemplo el desarrollo de un programa que le demande 5 años de trabajo a un programador altamente calificado y que requiera de las siguientes herramientas:

• Sistema Operativo.
• Compilador.
• Entorno de desarrollo: Depurador, editor de textos, etc.
• Herramientas de modelado: Herramientas para hacer diagramas de diseño, documentación, etc.
• Motor de base de datos.

El lapso de 5 años no es arbitrario: es una buena cota superior del tiempo pasado el cual un desarrollador debe renovar las herramientas que utiliza, si es que desea mantenerse actualizado. (Si lo prefiere, puede suponer la suma de varios desarrollos de menor envergadura, hasta llegar a cubrir dicho tiempo).

Comparemos entonces la cantidad de líneas de código “producidas” respecto de las “consumidas”. El cociente será seguramente bastante cercano a cero. Desde este punto de vista, aún cuando un programador sigue produciendo software, su rol de consumidor es, por mucho, más relevante.

Alguien dirá que al vender muchas licencias del programa producido, su valor se multiplicará. Esto no es así, teniendo en cuenta que, para poder ejecutarse el programa requerirá, nuevamente, de un sistema operativo y del motor de base de datos. No es poco común ver a un programador cobrar determinada suma de dinero por un desarrollo y a su cliente desembolsar bastante más por licencias del software requerido para que funcione.

Un mal negocio

Entre los programadores independientes (o pequeñas empresas de desarrollo) es práctica común usar software sin pagar por sus licencias, con lo cual parte del análisis anterior no los afecta demasiado. Pero sus clientes (y cada vez más) no tienen opción.

Por ejemplo, un sistema que requiera de un servidor con el sistema operativo Windows 2008 y el motor de bases de datos Microsoft SQL Server 2008 para su utilización en 25 puestos de trabajo, requerirá el pago de más de u$s 10.000 en concepto de licencia de uso de dichos productos (en la Argentina, marzo de 2010). ¿Cuánto deberá trabajar el programador para cobrar una suma de dinero similar?

Claramente, esta forma de ver el negocio no tiene mucho sentido (a no ser para aquellas empresas de desarrollo que además son agente de ventas de quienes proveen el software de base y se llevan una jugosa comisión).

Quizá sea por este motivo que las empresas proveedoras de herramientas de desarrollo y software de base invierten tanto dinero para que los programadores se pongan “su camiseta”, recurriendo para esto a discursos motivadores, aportes a instituciones educativas, descuentos, tazas de café, etc.

Asumir que esta es una situación natural es resignarse a ser, ya no un productor, sino un mero promotor de la venta de productos de otro (con un esfuerzo y un riesgo bastante altos).

Una buena alternativa

Debemos reconocernos a nosotros mismos, antes que como productores, como consumidores de software. De esta manera, la salida es clara: debemos reducir los costos de la “materia prima”. Debemos, en la medida de lo posible, utilizar software que no requiera el pago de licencias de uso. De esta manera disminuyen sensiblemente los costos para el desarrollador, como así también los costos extra del cliente. (Y cliente que gasta menos en licencias, tiene más dinero para pagarle al programador).

Si el sistema del ejemplo anterior pudiera correr en un servidor con GNU/Linux y el motor de bases de datos PostgreSQL tendría más de u$s 10.000 de “ventaja” en condiciones similares.

Otro punto importante es el ahorro en hardware, al utilizar productos que reduzcan los requerimientos en este aspecto (característica que distingue a muchos programas libres, respecto de sus contrapartes privativas), aunque dicho análisis escapa al objetivo del presente artículo.

¿Por qué no?

Existe una marcada reticencia en ciertos programadores a analizar seriamente esta alternativa. Dejaremos de lado, por supuesto, el caso de aquellos que actúan, además, como agentes de venta de los proveedores de software de base (su caso es más que claro: ellos se benefician por ambos lados). Analizaremos algunas de las objeciones más comunes:

El sistema operativo libre “X” es difícil de usar. No lo entiendo

En casi todos los casos, “X” se refiere al sistema operativo GNU/Linux (el sistema operativo libre más difundido). Quizás el programador en cuestión haya tenido una mala experiencia tratando de usar alguna versión mal configurada u obsoleta. Seguramente tampoco haya dedicado demasiado tiempo ni esfuerzo a aprender los conceptos básicos (que no son, precisamente, como usar los botones del mouse), y se alejó cual la zorra de Esopo murmurando “están verdes”.

De esto no se desprende que GNU/Linux sea tán fácil, cómodo o agradable de usar que Windows 7 (o más), pero tratándose de un profesional y habiendo tanto dinero de por medio, bien merece algún pequeño sacrificio.

En la empresa en donde se implanta mi sistema usan Windows

Aquí hay una amplia variedad de casos. ¿Usan Windows en los equipos de escritorio? Asumiendo que ya han pagado las licencias (por el tiempo que reste hasta la actualización de los equipos), de todas maneras podría significar un ahorro importante a nivel de los servidores. ¿Usan Windows en los servidores? Proveer una aplicación que no lo requiera, puede significar un valor agregado interesante.

En la mayoría de los casos en que la empresa “usa Windows” es porque las aplicaciones existentes lo requieren. No es, por lo tanto, una excusa para no proveer una alternativa que posibilite un ahorro importante (si no en lo inmediato, en el mediano plazo).

Estoy acostumbrado a desarrollar en (y para) Windows

Todos sabemos que los programadores disponemos de poco tiempo para mantenernos actualizados y lo costoso que resulta abordar el aprendizaje de una nueva tecnología. Cada quién sabrá si realmente se justifica el esfuerzo, poniendo en la balanza costos y beneficios (o, según el planteo de este artículo, costos y ahorros).

No hay un equivalente libre de la herramienta “Y”

Es cierto que en algunos casos (no tantos como se alegan) no hay equivalentes libres a ciertas herramientas privativas. ¿Y aquí termina el análisis? ¿No merece la pena indagar sobre alguna alternativa? ¿Tan útil es la herramienta “Y” que se hace imprescindible e indiscutible?

Si alguien depende exclusivamente de una determinada herramienta para desarrollar software, entonces se encuentra ante un problema bastante más grave que el gastar dinero en licencias de uso. (Preguntar a desarrolladores en Delphi, Visual Fox, Clarion, entre otros. Pero este tema también excede el alcance del presente artículo.).

No hay un equivalente libre del motor de bases de datos “Z”

Aquí “Z” suele tomar la forma de MS SQL Server, Oracle o DB/2. La afirmación suele hacerse seguida de alguna frase que parece extraída de una publicidad del proveedor correspondiente. La realidad es que existen numerosos motores de bases de datos libres, como por ejemplo MySQL para pequeños volúmenes de información, o PostgreSQL que no tiene ninguna característica importante que envidiarle a ningún otro producto.

En el caso de programas libres, nadie me ofrece el soporte que me da la empresa “W”

¿Enserio? Prácticamente todos los programas libres importantes, cuentan con ofertas de soporte incluso mejores que las que puedan conseguirse respecto de programas privativos. Por un lado, el soporte ofrecido es de mejor nivel, ya que se ofrece a nivel de reparación de errores en el código fuente y, por otro, muchas veces existen múltiples proveedores de soporte, que compiten entre si (en el mundo del software privativo el soporte es un monopolio del fabricante).

Porque no

Es cierto que hay algunos casos en donde no hay alternativa (la utilización de determinada tecnología puede ser impuesta como un requerimiento), pero en la mayoría de los casos la situación es que el programador se encuentra “atado” a sus herramientas.

En algunos casos, porque las han utilizado durante mucho tiempo (y tienen una gran cantidad de código desarrollado ligado a ellas) y en otros porque han “comprado” el discurso de su productor, muchos programadores se resisten a realizar cualquier análisis que tenga que ver con cambiar sus herramientas. El caso más grave (y lamentablemente no poco común) es cuando el programador simplemente no puede usar otra tecnología más que la que domina: es la única que conoce.

De más está decir, las inversiones en marketing dan resultado. Hoy nos encontramos a muchos programadores que han sido formados en un ambiente académico muy similar a un “monocultivo” (que, a pesar de ellos, ni siquiera ofrece los amplios márgenes de ganancia de la soja) o que se han entregado más tarde a determinada combinación de herramientas/tecnología y la han abrazado como dispuestos a envejecer (y quedar obsoletos) junto con ella.

Y así es que el negocio seguirá funcionando muy bien para los “grandes productores de software”, en tanto que los pequeños no reconozcan su rol de consumidores. Afortunadamente, la situación ya está cambiando: abundan los ejemplos de quienes, siendo conscientes de esto, están haciendo una diferencia económica significativa.

Adenda

Nótese que en este artículo no se hace alusión a la licencia bajo la cual el programador entrega su programa al cliente final. El término “libre” sólo se aplica a las herramientas utilizadas para el desarrollo y a las requeridas para su posterior ejecución.

El uso de herramientas de desarrollo libre no impone ninguna condición sobre la licencia que acompañará al programa resultante. (Distinta situación puede darse si se incorpora código de un programa libre en uno de producción propia).

Dicen que hay que exigir la tenencia de un título. Y luego formar un organismo regulador (en realidad, autorregulador) que decida quienes pueden o no “ser informáticos”. Que de esta manera, los usuarios tendrán mejores sistemas informáticos y, de paso, los profesionales serán mejor reconocidos (incluso en lo económico). Dicen que así se soluciona este asunto.

Nota del autor: Este es un artículo de opinión personal, basado solamente en mi experiencia e ideas. Para un análisis más completo (y muy probablemente, más objetivo), recomiendo leer este artículo.

Declamaciones

Pero… ¿quiénes dicen?

Los propios informáticos (por un momento, vamos a agrupar bajo este término a programadores de distinto tipo, analistas de sistemas y profesionales de otras tareas afines). Bueno, en rigor, no todos los informáticos. De hecho, parece ser un grupo bastante bien diferenciado el que levanta la voz para pedir la regulación por parte del Estado, de las tareas profesionales que desempeñan. Más adelante volveremos sobre este punto, tratando de indentificar las características comunes entre ellos.

Y… ¿qué es lo que dicen?

Dicen que la razón del desprestigio de la profesión (por la cual no son considerados por la sociedad de la misma manera que los médicos, arquitectos, abogados, etc.) es que hay mucho improvisado ejerciéndola. Que hay gente sin los conocimientos técnicos necesarios (y, más de una vez, sin la menor noción de la ética) que anda por ahí haciendo las cosas bastante mal (o sea, que no ofrecen soluciones de acuerdo al “estado del arte” y las “mejores prácticas” de la profesión).

Dicen también que no sólo es injusto para la sociedad, sino también para “ellos”. Ellos (que poseen algún título relacionado con la informática) se “quemaron las pestañas” y se “rompieron la cabeza” leyendo libros, asistiendo a clases, resolviendo ejercicios. En tanto que “los otros” entran por la ventana, provienen de otras disciplinas (cual invasores), poseen estudios incompletos (no hicieron el esfuerzo) o son directamente autodidactas.

¿Y qué proponen?

La solución propuesta es simple: que el Estado regule o limite el ejercicio de la informática (que, como ya dijimos, engloba a cosas bastante diferentes). La forma de implementar esta restricción sería mediante la creación de Consejos Profesionales (uno por cada provincia, en el caso de la Argentina) en los cuales deban matricularse obligatoriamente todos aquellos que deseen desempeñar profesionalmente alguna tarea relacionada con la informática. Por supuesto, la condición principal para poder pertenecer a tal entidad, sería la tenencia de un “título habilitante”.

En definitiva, proponen que la informática sólo pueda ser “ejercida” por los informáticos titulados. (De la misma manera que la medicina es ejercida por médicos, la arquitectura por arquitectos, el derecho por abogados, etc.)

Del dicho al hecho

¿Es necesario regular?

Todos sabemos que en el mundo de la informática se mueven muchas personas de dudosa calidad profesional, por lo cual los argumentos precedentes parecen tener cierto sustento. Cualquiera con experiencia previa, sabe que a la hora de contratar un desarrollo de software puede estar iniciando un camino más que tortuoso y de resultado incierto. La mayoría de los clientes de informáticos no están nada conformes con su proveedor. De manera que parece buena idea hacer algo al respecto, ¿no?

Un buen ejemplo

En la Provincia de Córdoba (Argentina) existe desde hace 23 años una ley que restringe el ejercicio profesional de la informática, mediante la creación del Consejo Provincial de Ciencias Informáticas. Sin embargo, nadie podrá decir que en esta provincia el nivel de los profesionales o la satisfacción de los clientes sea mayor que en otros lugares, en donde no se ha ensayado esta solución.

Claro que un único ejemplo no basta para sacar demasiadas conclusiones (el consejo cordobés bien podría ser un desastre de implementación o haber estado muy mal manejado durante todo este tiempo). Pero que la segunda provincia de la Argentina, contando con un marco regulatorio desde hace más de dos décadas, no haya logrado ni siquiera una mínima mejora cualitativa de la disciplina es, cuando menos, sugestivo.

¿Y en el resto del mundo?

En casi todos los países del mundo (excepto, por ejemplo, algunas comunas españolas) el ejercicio profesional de actividades relacionadas con la informática no tiene ningún tipo de restricción o regulación por parte del estado. Ejemplos notables de esto son países con un altísimo ingreso por exportación de software y servicios informáticos, como Irlanda y la India.

Hay de todo, como en botica

Muchos de los grandes gurús de la informática no han tenido título alguno, en tanto que muchos otros lo han tenido pero de disciplinas en algunos casos bastante lejanas a la computación (lingüística, física, etc.). Como bien sabemos, la informática es una actividad transversal a muchas áreas del conocimiento. Es ridículo, entonces, pensar en limitar la posibilidad de ejercerla exclusivamente a quienes tienen un título específico.

Esta situación se ha presentado desde el preciso instante del nacimiento de la informática y se ha acrecentado aún más con el tiempo, en tanto la programación de computadoras se ha simplificado y masificado (quien diseña una planilla de cálculo, de alguna manera está programando).

Nadie niega la utilidad y el valor de un título (aunque, como siempre, hay algunos que son casi una garantía de conocimiento, otros que nada dicen de las aptitudes de su poseedor y una amplia y variada escala de grises). Muy probablemente entre los “titulados” se encuentre la mayoría de los buenos profesionales, pero los hay muchos y de gran calidad fuera de esta categoría, así como también hay improvisados e ignorantes en ambos lados.

Claramente, establecer el punto de corte en la simple condición de poseer un “título habilitante” nada aporta a la hora de separar la paja del trigo.

Que poseer un título formal en informática no haya logrado hasta la fecha establecer una diferencia marcada y notoria respecto de quienes no lo tienen, no es más que una muestra evidente del estado actual de la disciplina. (Quienes se comparan con médicos, arquitectos y abogados bien podrían analizar este ejemplo.)

¿Y la libertad de elección?

El exigir condiciones (como la tenencia de determinado título) para el ejercicio de la informática tiene una consecuencia no siempre analizada por quienes impulsan este tipo de iniciativa: limita la capacidad de elección de las personas.

Esto significa que alguien que quiera contratar, por ejemplo, a un programador, sólo podrá escoger entre los “habilitados” por la ley (normalmente, los matriculados en el Consejo Profesional). Esta situación es aceptable cuando está en juego la vida humana pero, ¿por qué no puede elegir un empresario a quién contratar para que diriga la informática en su empresa o a quién encargar el desarollo de un programa que necesita? En tanto el informático no se atribuya títulos o afiliaciones que no tiene, no hay motivo (razonable) para impedir tal trato entre particulares.

En la Argentina tenemos la costumbre a ver este tipo de limitaciones como naturales, pero debemos tener en cuenta que aún regulaciones como la exigencia del título de Abogado o Contador Público Nacional para la realización de ciertas tareas, no son universales. En algunos estados de los EE.UU, por ejemplo, basta con ser “ciudadano estadounidense” para firmar un balance, y en muchas jurisdicciones se permite a una persona actuar en un proceso judicial sin requerir de un abogado. (Será el ciudadano quien libremente opte por recurrir al profesional titulado si es que realmente encuentra valor en él.)

¿Por qué no son reconocidos?

La gran mayoría de quienes se quejan de no contar con el reconocimiento de otros (abogados, médicos, arquitectos, etc.) parecen no darse cuenta de que tales profesiones están bien establecidas en la sociedad por varios motivos.

Quizás el primero de ellos sea que se trata en general de disciplinas bastante bien definidas y delimitadas. Como contraejemplo, basta ver la definición que intentan de la informática las leyes (o proyectos) de regulación, por ejemplo la ley 7642/87 de la Provincia de Córdoba (la misma contiene solo una enumeración, a modo de ejemplo, de lo que se consideran “profesiones en Ciencias Informáticas“).

Habría que preguntar a quienes reclaman el reconocimiento social si ellos ofrecen el mismo nivel de garantía a sus clientes que los profesionales con los que se comparan. En la informática no sólo no hay métricas bien establecidas (y confiables) para evaluar costos, riesgos ni calidad; sino que ni siquiera se dispone de un método serio para evaluar la productividad de un programador. (Si usted es un lego en la materia seguramente se sorprenderá al saber que la principal métrica utilizada es la “cantidad de líneas de código” producidas, sin poder decir demasiado de la calidad de las mismas.)

Profesionales e improvisados

Si observamos el perfil de quienes demandan regulaciones y la expulsión de los (según ellos dicen) usurpadores, en la mayoría de los casos podemos observar ciertas características comunes:

• Título mediocre. Salvo pocas excepciones, el profesional posee un título mediocre u otorgado por una institución mediocre (es casi imposible encontrarse con un título de Doctor de una universidad reconocida). Muchas veces puede observarse la asistencia a cursos de dudosa necesidad, denotando la incapacidad de aprender por si mismo.
• Conocimientos limitados de lenguajes de programación. Conocimiento de, a lo sumo, un par de lenguajes, por lo general obsoletos o en vías de obsolescencia.
• Ignorancia de conceptos. Pobre entendimiento, si acaso, de cuestiones relacionadas con el software de base (sistemas operativos, compiladores, etc.), fundamentos de las ciencias de la computación (matemática discreta, teoría de autómatas, complejidad y computabilidad, etc.), entre otras.
• Desconocimiento del idioma inglés, lingua franca de la informática.
• Aportes nulos o ínfimos a la disciplina, como la producción de textos técnicos, aportes en investigación, participación de desarrollos comunitarios, etc.

La experiencia del autor es que la mayoría de quienes reclaman “sacar a los improvisados” del campo profesional, generalmente reúnen al menos tres de las condiciones anteriores (sin duda, hay excepciones). La pregunta es, ¿qué es un “improvisado”, sino alguien con conocimientos endebles (más allá de un título que los refrende) y desactualizados, que ni siquiera posee los medios técnicos (formación de base y conocimiento del idioma) para mantenerse a sí mismo al corriente de la evolución tecnológica?

Aclarando, que hace falta…

Algunas aclaraciones que a esta hora suelen, por lo general, ser necesarias:

• Un título en informática es una característica deseable pero no necesaria en un informático.
• Atribuirse un título o una condición que no se posee, sí es una actitud censurable (como también lo es, por ejemplo, no pagar impuestos).
• No tener un título no implica no haber estudiado. Por otra parte, el sí tenerlo no es garantía de conocimientos (ni, mucho menos, de la vigencia de los mismos).
• Las asociaciones profesionales (como ACM a nivel internacional, o SADIO en la Argentina), de afiliación voluntaria (y que, a su vez, no tienen la obligación de aceptar a cualquier persona, en contraste con los Consejos de matriculación obligatoria) son altamente positivas. Es notable que dichas organizaciones en general son contrarias a la regulación de la profesión.
• No debe confundirse “matriculación obligatoria” con “certificación”. Muchas empresas (en ejercicio de su derecho) exigen determinadas certificaciones profesionales a sus proveedores. Es notable que en casi todos los casos, la certificación es provista por otra empresa.

Conclusiones

Una profesión no se “jerarquiza” mediante el simple dispositivo de una ley que obligue a la creación de un Consejo Profesional de matriculación obligatoria. La informática es suficientemente amplia y dinámica como para creer que la conditio sine qua non para ejercer una actividad relacionada con ella (con el debido nivel profesional) es poseer un título de tres años otorgado por una institución de nivel terciario.

Quienes intentan negar a otros derecho a ejercer actividades informáticas por creer que esto les quita oportunidades deberían mirarse introspectivamente y reconocer la amplitud de la disciplina, y que la diversidad de habilidades y conocimientos requeridos en cada una de sus áreas, no pueden ser englobados bajo el título de “informático”. Tampoco es exigible el reconocimiento de la comunidad a practicantes de una disciplina que ni siquiera dominan el cuerpo de conocimientos básicos de la misma (que, además, lejos está de establecerse por completo).

Tampoco debemos olvidar que muchos aspectos de la informática se han extendido a diversas disciplinas, de forma similar a lo ocurrido con la matemática. Esta expansión (que es una especie de democratización) es altamente deseable y beneficiosa, y las iniciativas de regulación conspiran en su contra.

La informática es una disciplina joven y endeble. Es el deber de los que nos dedicamos a ella lograr posicionarla como una disciplina confiable y reconocida. ¿La forma de lograrlo? No soy quién para conocerla, pero seguramente se basa en esfuerzo, dedicación y honestidad. La discriminación arbitraria lejos está de aportar a la solución.

Por lo pronto, la “profesión informática” tiene exactamente el reconocimiento que se ha sabido ganar. No se pondrá los “pantalones largos” por ley.

Ariel Álvarez Valdes no era un simple curita provinciano, sino que es un reconocido teólogo católico, formado en Israel y doctorado en España, que ha publicado numerosos artículos en revistas de varios países y en varios idiomas. Desde hace unos años cometió el “error” de escribir artículos de divulgación (a un nivel popular) analizando la Biblia católica. En virtud de esto, fue censurado por las autoridades eclesiásticas y finalmente ha dejado los hábitos.

Claramente, la Iglesia Católica sigue comportándose como en el siglo XVII, cuando exigió a Galileo Galilei que se retractase por contrariar -según entendían- los dichos de la Biblia. (En honor a la verdad, algo han evolucionado. A Álvarez Valdes no lo amenazaron con torturas ni lo condenaron a prisión de por vida.) Además, es notable que la autoridad Católica le esté exigiendo que mienta, en tanto su retractación no es sincera, sino que es impuesta (y no puede siquiera hacer referencia a tal imposición).

Vamos, que lo que dice este buen hombre, no es nada que mis hijos de 9 y 10 años no sepan ya a estas alturas: que el hombre no apareció a partir de un muñequito de barro, que nunca hubo un viejito que hizo un barco y juntó animales de todas las especies que existen, que los muertos no andan apareciéndose por ahi (por santos que sean), que no hay demonios que se metan adentro del cuerpo de las personas (aunque ciertos políticos hagan pensar que sí). En resumen: una persona puede creer en la existencia ser superior, si la deja más tranquila; hasta puede creer que ese ser superior se preocupa por ella y más aún, que la “escucha” cuando le habla; pero nada de eso es excusa para ser idiota. Y tal parece que los esfuerzos de la Iglesia Católica están enfocados en que sus seguidores sean idiotas (quizás por eso insiste en enseñarles sus cuentos de hadas, duendes y demonios desde temprana edad).

Con el objetivo de cumplir con las órdenes de cateo del gobierno sobre los datos de los usuarios, Google ha creado un sistema de acceso de puerta trasera a las cuentas de Gmail.

Si bien en el artículo no aporta ninguna prueba que avale sus dichos, hay que tener en cuenta que se trata de una autoridad reconocida en el mundo de la seguridad informática, y que dificilmente haría semejante declaración pública sin contar con evidencia al respecto.

En el mismo artículo, además, Schneier describe una serie de ejemplos sobre cómo ciertos fabricantes (entre ellos, Siemmens, Nokia y Ericsson) han incluido mecanismos de vigilancia y espionaje en sus productos, a pedido de agencias gubernamentales (y no sólo de los EE.UU.).

Asi es que parece ser que Google, cuyo lema sigue siendo “Don’t be evil” (No seas maligno), y que ya había colaborado con la censura gubernamental en China, ahora parece estar abriendo las puertas a (al menos) la NSA para que espíe a todos sus usuarios.

Parece que va llegando la hora de usar solamente el buscador de Google, y con mucho cuidado…

Aunque muchas veces los anuncios se encuentran disfrazados por una tupida cobertura marketinera, tanto Nokia, Motorola, Samsung, Sony-Ericsson, entre otros, están apostando a Linux como plataforma preferida (y en muchos casos, única) para sus nuevos dispositivos.

A continuación, un resumen de las tecnologías utilizadas por cada fabricante, a modo de “mapa” para tratar de entender el panorama que se presenta.

Nokia

Nokia fue el principal impulsor del uso del sistema operativo Symbian en sus dispositivos de gama alta. El mismo es utilizado actualmente por otros fabricantes, tales como Sony-Ericsson y Samsung. Ya se ha anunciado que Symbian pronto será distribuido bajo una licencia libre.

Sin embargo, recientemente Nokia ha anunciado que sus nuevos dispositivos de gama alta, se basarán en otro sistema operativo: Maemo, que se encuentra fuertemente basado en Debian GNU/Linux (¡hasta provee apt!).

El por qué es claro: Nokia forma parte de la Linux Foundation (que tiene como empleado, entre otros, al mismísimo creador de Linux, Linus Torvalds).

Motorola

Motorola, hace más de un año, decidió dejar de utilizar tanto su sistema operativo basado en Linux, como así también Symbian, para comenzar a utilizar Windows Mobile y el sistema operativo Android (desarrollado por Google y también basado en Linux).

Hoy, su apuesta por Windows Mobile parece haberse debilitado, para finalmente volcarse al uso de Android en sus últimos equipos (a partir del reciente Motorola Milestone, lanzado al mercado con un precio realmente sorprendente).

Motorola forma parte no solamente de la Linux Foundation, sino también de la Limo Foundation, fundación que promueve el uso de Linux en plataformas móviles y que agrupa, entre sus más de 50 miembros, a los principales operadores de telefonía móvil del mundo.

Sony Ericsson

Esta empresa comenzó a dejar de utilizar Symbian en favor de Windows Mobile. Recientemente, como puede observarse en su línea XPERIA, se ha movido hacia Linux, utilizando Android.

Ericsson también forma parte de la Limo Foundation.

Samsung

Samsung ha anunciado que descartará a Windows Mobile en sus equipos, lanzando una plataforma que intenta competir con Android, llamada “Bada“.

Aunque todavía se encuentra en desarrollo, ya se sabe que Bada también estará basado en Linux. Esto no debería sorprender, ya que Samsung es uno de los fundadores de la Limo Foundation.

Google

Google no sólo ha incursionado en el mercado de la telefonía móvil con su plataforma Android, sino que recientemente ha anunciado que lanzará su propio celular.

Además, hace unos días anunció que se encuentra desarrollando un “nuevo” sistema operativo: Chrome OS, también basado en Linux (y con cierta relación con Ubuntu). También se ha anunciado que en un futuro, Android y Chrome OS convergerán en un único producto.

Esta fuerte apuesta de Google por Linux tampoco debiera llamar la atención, ya que es otro de los miembros de la Linux Foundation.

Los fabricantes de CPUs

Intel

El otrora socio estratégico de Microsoft, también impulsa una plataforma para dispositivos móviles basada en Linux. Se trata de Moblin (Mobile Linux, optimizado para procesadores Atom), que fue inicialment desarrollado por Intel y luego traspasado a la Linux Foundation (de la cual Intel es uno de los principales miembros).

AMD

AMD también se ha sumado a la apuesta por Linux, integrando la Linux Foundation.

ARM y Texas Instrument

ARM (diseñador de las CPUs más utilizadas en celulares) y Texas Instrument (uno de sus principales fabricantes) pertenecen tanto a la Linux Foundation como a la Limo Foundation.

Conclusión

El panorama es claro: Linux se perfila como la principal opción no sólo en el mundo de los teléfonos celulares, sino también en los dispositivos móviles en general (algunos estudios afirman que el 33% de las netbooks vendidas durante el 2009 tienen Linux).

Más allá de las especulaciones sobre el futuro, la realidad nos indica que practicamente todos los fabricantes de dispositivos electrónicos y de software (a excepción de Microsoft), así como también los operadores de telefonía celular más importantes, se encuentran reunidos en la Linux Foundation y la Limo Foundation. Y, claro está, esta presencia no es sólo simbólica.

El listado de fin de este año trae unas cuantas sopresas: No solamente Linux se afianza como el Sistema Operativo más elegido, sino que un equipo con procesadores AMD desplaza del primer lugar a los tan renombrados procesadores Power de IBM.

A continuación, un extracto del Top 500:

En total, casi el 90% de las 500 computadoras más potentes usan Linux (si consideramos la suma de todos los derivados de Unix la cifra supera el 95%):

Nota: Los sistemas operativos que aparecen agrupados bajo la denominación de “Varios” son, en general, también basados en Linux.

Es claro entonces que Linux es el lider indiscutido en computación de alto rendimiento y que los procesadores AMD Opteron son más que una alternativa viable para este tipo de sistemas (aunque todavía haya quienes insistan en pagar fortunas por equipos basados en los Power de IBM).

¡Ah, me olvidaba! Windows logra ubicar un sistema en la posición 20 (pero lamentablemente sólo logra un 1% entre las quinientas computadoras más poderosas de la actualidad).

Para finalizar, les presento a la computadora más potente del mundo: una Cray XT5-HE bautizada “Jaguar“. ¡Quién lo diría hace una década: el tope de la computación logrado por un sistema basado en Linux con procesadores AMD!

Además de la profunda satisfacción personal que siento y sentí durante todo este tiempo, y de los grandes beneficios que obtuve de la libertad del software que utilizo (y de la comunidad a su alrededor), quería compartir con todos aquellos que leen este blog un resumen de mi historia como usuario de GNU/Linux.

Los comienzos

Mi primer contacto con GNU/Linux ocurrió a principios de 1996, de la mano de la meta distribución Infomagic Linux (5 CDs, $50) que incluía, entre otras, a Slackware, que fue la distribución que elegí en ese momento para mi computadora basada en un procesador Pentium de 166Mhz con 16 Mb de RAM. Por supuesto, mantuve en otra partición el sistema operativo que usaba por ese entonces: Microsoft Windows 95.

Voy a resumir esta etapa diciendo que, luego de varias horas de particionar, formatear, instalar y volver a empezar, logré loguearme como “root“, sólo para descubrir que no sabía hacer mucho más que listar las entradas de un directorio y moverme por el sistema de archivos. Leí en la escasa documentación impresa de Infomagic que había un entorno gráfico llamado “X” y que para configurarlo tenía que editar un archivo de texto. En ese momento descubrí que ni siquiera sabía hacer eso en mi nuevo sistema. Así de frustrado estaba. Además, la configuración de X parecía tan peligrosa que un apartado de la documentación se titulaba “Cómo configurar X sin llamar al departamento de bomberos” (no era chiste, existía el riesgo de que el monitor se incendiara).

Luego de aprender lo básico del editor “vi” (toda una complicación en ese momento), pasó casi un año hasta que pude tener un entorno gráfico usable. (El driver de mi placa de video, una SiS 6202, en X funcionaba realmente mal.)

El principio del cambio

Durante un par de años, fui aprendiendo cada vez más sobre el uso de GNU/Linux (por aquellos tiempos instalé mis primeros servidores con él) hasta que, en mayo de 1999 me compré un flamante Pentium II de 400Mhz con 64Mb de RAM. Decidí instalarle solamente GNU/Linux, eligiendo en esa oportunidad la distribución que venía utilizando desde hacía un tiempo: SuSE Linux.

En ese momento, mi viejo Pentium ya había mutado para tener 48Mb de RAM y Windows 98/SuSE Linux coexistiendo en el disco duro. Contaba entonces, con una computadora moderna, con GNU/Linux, y con otra más modesta, con ambos sistemas operativos.

Ya en ese momento había muchas cosas que no podía hacer sino en GNU/Linux (cuestiones relacionadas con programación, redes, etc.), pero todavía algunas tareas me requerían el uso de Windows (o alguna de sus aplicaciones). La situación era ahora más fácil, ya que podía tener una computadora con cada sistema operativo.

Así fue que en ese momento (1 de junio de 1999) decidí plantearme mi próximo objetivo: aprender a hacer en GNU/Linux todo lo que en ese momento me requería usar Windows. Esto implicaba desde aprender cosas “básicas” hasta buscar aplicaciones de reemplazo. El plazo que me fijé para lograrlo fue de 5 meses.

El “día D”

Y llegó el 1 de noviembre de 1999. Ese día, con un inmenso placer por haber alcanzado mi objetivo, eliminé la partición de Windows 98.

No todas fueron rosas. Más de una vez (y hasta el día de hoy) me encuentro con archivos en formatos privativos que no puedo “abrir” sin renegar un poco, con sitios web que no funcionan si no es con algún navegador privativo específico (léase “Microsoft Internet Explorer” versión 6 o superior) y algún otro inconveniente de ese tipo. Pero todos esos contratiempos no se comparan con la tranquilidad, la flexibilidad y la enorme ventaja competitiva de usar programas cuya licencia no limitan mi libertad y, más aún, que están hechos “para funcionar” (e interactuar, facilitar y progresar) y no “para impedir” (y limitar, forzar y detener).

La actualidad

Si bien todavía no he logrado erradicar algunos programas no libres (por ejemplo, el driver de la placa Wifi de mi notebook), o incluso me veo obligado a tener una máquina virtual con Windows XP (para poder asegurar la compatibilidad de mis desarrollos con esta plataforma), no he necesitado nunca más usar para mí mismo un sistema operativo no libre (al punto que ya no se que decir cuando algún amigo o colega me pregunta sobre alguna herramienta de remoción de troyanos y spyware).

Actualmente, utilizo Debian GNU/Linux en mis servidores y Ubuntu Linux en las máquinas de escritorio. Y con total sinceridad, debo decir que no solamente no extraño nada, sino que cada vez que me toca sentarme delante de un Windows “algo” me siento como si tratara de bailar estando adentro de una armadura.

Addendum

Como recién me han hecho notar (¡gracias, Marce!) hoy es el “día de todos los santos”. Quienes me conozcan sabrán sobre mis creencias pero, tratándose de semejante coincidencia, no puedo dejar de recordar a San Ignucio.

“GNU es el único sistema, y Linux es uno de sus kernels.”