VELOCIDAD DE ESCAPE
Inicio > Historias > OPEN SOURCE, SEGÚN MICHELLE LAVESQUE
2004-04-15
RESUMEN
A pesar del creciente éxito del movimiento de Software Libre, la mayoría del público en general sigue viéndolo como algo inaccesible. Este artículo presenta cinco problemas fundamentales con la actuales tendencias de desarrollo del software libre, explora porqué dichas cuestiones están deteniendo su avance, y ofrece soluciones que pueden ayudar a vencer estos problemas.
La carencia de interés en el diseño de interfaces de usuario provoca que se prefieran los interfaces más intuitivos del software propietario.
El software de código abierto tiende a carecer de documentación completa y accesible para retener a los usuarios. Los desarrolladores se centran en las características de su software, más que en asegurarse de que tenga una base sólida . Los desarrolladores tienden también a programar para sí mismos como objetivo, en vez de hacerlo para el público general.
Por último, hay una comúnmente reconocida terquedad de los programadores "Open Source" en el rechazo a aprender las lecciones que el software propietario tiene que ofrecer. Si el software de código abierto desea llegar a ser extensamente utilizado y adoptado por el público en general, estos cinco problemas han de ser superados.
Contenidos:
Introducción
Diseño de interfaz de usuario
Documentación
Desarrollo no centrado en cliente
Programación para programadores
Ceguera religiosa
Conclusiones
Sobre la Autora
Notas al Pie
Referencias
INTRODUCCIÓN
"Es mi proyecto Open Source y hago lo que quiero con él"
En los últimos meses, me he visto en la responsabilidad de coger un proyecto de Open Source (para no señalar a nadie, lo llamaremos Proyecto X) y adaptarlo para uso académico.
Aunque no voy a presumir de ser una experta en el reino de todas las tendencias de programación Open Source, tengo bastante experiencia con él: lo uso constantemente siempre que me es posible (apoyo totalmente la corriente sociológica que hay detrás del movimiento), he sido jugadora importante en algunos pequeños proyectos de código abierto todavía en desarrollo, y ahora tengo la experiencia de unos cuantos meses trabajando con el proyecto X.
Así, que a pesar de no ser una experta, creo que mi opinión puede considerarse como relativamente bien fundamentada.
Tengo cinco quejas fundamentales sobre el "Open Source"1 pero me gustaría aclarar un par de cosas. Primero, siempre hay excepciones a cualquier regla. Por ejemplo, creo que relativamente pocas de estas quejas se aplican al navegador FireFox2 , el cual continúa sobrepasando mis expectativas. Estoy tratando tendencias generales que he advertido, no casos específicos. En segundo lugar, no creo que estos sean problemas irresolubles. El propósito de este documento es despertar conciencias -no quejarse sin tino- en la esperanza de que la comunidad de código abierto cambie sus esquemas mentales sobre estas cuestiones y trabaje para mejorar.
Dicho esto, he encontrado que los cinco defectos más importantes del software libre son los siguientes:
1. Diseño de Interfaz de usuario
2. Documentación
3. Desarrollo no centrado en el cliente
4. Programación para programadores
5. Ceguera Religiosa
DISEÑO DE LA INTERFAZ DE USUARIO
El proyecto X viene con un limpio calendario interactivo. Justo como se podría esperar, puedes programar acontecimientos, compartir acontecimientos con otros, y resolver conflictos. Sin embargo, nadie lo sabrá nunca, porque para ver el módulo del calendario, tienes que conocer la dirección URL del Módulo previamente: no hay vínculos, aparte de uno enterrado a varias páginas de profundidad. La interfaz del Proyecto X es una pesadilla. Hay montones de pestañitas coloreadas y la disposición estética es ciertamente agradable, pero es extraordinariamente difícil descubrir cómo hacer aún las más sencillas tareas.
Solamente una parte muy pequeña de la interfaz es intuitiva, y algunas tareas no pueden ser realizadas a través del entorno gráfico : tienes que editar la base de datos a mano.
Por alguna razón, los proyectos libres parece que tienen muchos problemas con el diseño de interfaz. Un buen ejemplo de esto es la situación del entorno Mac OS. He visto gente con una experiencia en computadoras relativamente pequeña navegar por entre el escritorio OS X durante pocos minutos, y entonces, girarse y decirme "fluye muy agradablemente" y "lo veo más agradable que el que uso habitualmente". Si pongo a las mismas personas con KDE o GNOME, probablemente perderán la mitad del tiempo luchando contra su propia intuición, y la otra mitad preguntándose porqué fueron obligados a sentarse en frente de semejante escritorio patoso cuando su computadora con Windows XP funciona bastante mejor. Independientemente de si piensas o no que KDE y GNOME son interfaces pobres (ver ceguera religiosa) Mac OS X ha probado ser mucho más usable, amistoso, intuitivo que cualquier otro interfaz Unix que la comunidad libre haya ofrecido.
Sospecho que no hay una sola razón para la pobre calidad de las interfaces pero hay algunas explicaciones que he oído vagando por los círculos del software libre: los "geeks" valoran la integridad por encima de la belleza; las diferencias entre grupos dentro de las comunidades de software libre; es intuitivo para los programadores así que ¿porqué habría que arreglarlo? (ver Programación para programadores), la creencia de que un bonito interfaz puede ser siempre programado más tarde una vez se ha hecho el trabajo "real", la creencia de que el diseño de interfaz no es un trabajo "real", y muchas otras.
Muchas de estas causas suenan muy plausibles, y sospecho que la verdadera razón para la negligencia en el caso de las interfaces de usuario es una combinación de muchas de ellas. Sin embargo, si la comunidad de software libre desea realmente prosperar y que sus herramientas las use el público en general , es fundamentalmente necesario reconocer que la mayoría de los usuarios nunca inventarán un algoritmo particularmente inteligente para sincronizar la edición multihilo de su compleja estructura de datos. Lo que el usuario verá -y por lo que juzgará el proyecto- es su interfaz. Si es inadecuado, nadie aparte de los Geeks tocará el programa.
LA DOCUMENTACIÓN
El Proyecto X tiene una documentación bastante extensa, lo cual no es siempre el caso en los proyectos de software libre. Desafortunadamente, la documentación es para una versión desechada del Proyecto y apenas han incluido el número de versión más reciente en el título. También, se asume que el sistema del usuario está configurado exactamente de la misma manera que el sistema del escritor de la documentación . También debes de ser experto en la administración del sistema, y saber cómo manipular el lenguaje de programación en el que está escrito el programa, porque los errores que van a ocurrir no están mencionados en la documentación, y vas a necesitar saber cómo depurarlos.
Los proyectos libres, suelen tener un gran problema para aportar una documentación decente, y eso si tienen documentación alguna. Debido a que no tienen obligación contractual de proveer de dicha documentación suele ser más bien una guia general de uso más que un manual completo que puedas entregar a un novato.
Imagina lo que le debe parecer la siguiente frase a alguien que sabe poco de Unix y lo está instalando por primera vez: "necesitarás una lista de los Checksums MD5 para los archivos binarios. Si tienes el programa md5sum, puedes comprobar que tus archivos no están corruptos ejecutando md5sum -v -c md5sum.txt" 3. La más común respuesta a esta queja es "si no puede comprenderlo, entonces no está preparado para instalarlo", pero entonces, ¿cómo se espera que aprendan?. La documentación debería siempre acercarse al común denominador más bajo.
También, cualquiera que ha tenido alguna vez que depurar un problema en el software libre sabe que las respuestas no están en la documentación: se encuentran el los artículos de Usenet, boletines electrónicos e históricos de chats. Los usuarios que no pueden imaginarse cómo hacer algo corren al grupo de news alt.proyectoX.desarrollo y preguntan la misma pregunta que cientos de usuarios han hecho ya antes. Cuando algún experto se compadece de sus apuros, responde a su cuestión pero nunca documenta su respuesta. Así que cuando el próximo usuario se encuentra con el mismo problema, todo el proceso ha de ser repetido. Además, estoy haciendo la suposición fundamentalmente errónea de que los usuarios son capaces de encontrar estas fuentes alternativas de documentación 4 , o son lo suficientemente pacientes y les preocupa el producto para molestarse. Sin la documentación adecuada, los proyectos "Open Source" están, por definición, en desventaja.
DESARROLLO NO ORIENTADO AL CLIENTE
Una vez instalado el Proyecto X, tienes un poderoso conjunto de herramientas al alcance de tus dedos para realizar una amplia variedad de tareas con docenas de impresionantes opciones asociadas a cada una de estas herramientas. Desgraciadamente, tras instalar el proyecto X, el grupo Unix se divide. Durante mis numerosas correspondencias con los desarrolladores de la rama principal, me mostraron dónde podía descargar parches para los muchos problemas que existían en el proyecto liberado y me recordaron que aunque había todavía algunos problemas, el proyecto X tenía ciertamente multitud de "molonas" opciones, ¿o no?.
En la primera clase sobre Herramientas de Software y Programación de Sistemas a la que asistí, se nos instruyó cuidadosamente en que las mejores herramientas de software eran pequeños programas que hacían una cosa bien e interactuaban limpiamente con otras herramientas. Esto suena como la filosofía que es perfectamente adoptada por el movimiento de Software Libre: si tienes muchos colaboradores y todos ellos crean uno (o muchos) pequeños programas que hacen una sola cosa bien e interactúan limpiamente con otros programas, un limpio y poderoso sistema surge de todo ello. Y creo que esto ha sido demostrado por la durabilidad y longevidad del sistema operativo Unix.
Pero en algún momento a lo largo del camino, creo que los programadores de software libre olvidaron estos conceptos fundamentales. La obsesión por las opciones (Features) comenzó a establecerse (y por una vez no fue debido a que hubiera clientes pidiendo más características). Es el programador individual que quiere añadir la opción al proyecto que permita que el actual gráfico en 2D se muestre en 3D (accediendo por teléfono móvil, navegador y mensajería instantánea), y entonces lo hace funcionar con cualquier combinación de teclas, clicks de botones, gestos de ratón, comandos de voz, y sensor del puntero láser. No hay nada excitante en ser un programador que se dedica a limpiar algunas de las librerías convirtiendo bloques de código comunes en funciones.
Con demasiado énfasis en las opciones añadidas y "chorraditas" de Geeks, los aspectos fundamentales de la programación del proyecto se pierden. No siempre ocurre en funcionalidades centrales del proyecto X. A menudo es una deficiencia en centrarse en el interfaz de usuario (ver Diseño de interfaz de usuario), la documentación, los estándares de codificación, la seguridad, dirección del proyecto, especificación de la audiencia objetivo, (ver programación para programadores), etc. Es altamente improbable que todo esto ocurra dentro de un solo proyecto, pero sospecho que al menos algunos de estos errores ocurren en la mayoría de los proyectos de software libre. Y creo firmemente que esto se debe a las ventajas personales de ignorar el trabajo mundano y dedicar más tiempo construyendo "el material divertido".5
PROGRAMACIÓN PARA PROGRAMADORES
La primera vez que instalé el Proyecto X, me topé con un obstáculo que no pude sortear, así que me dí una vuelta por el canal IRC del Proyexto X. Después de explicar mi problema a los programadores del Proyecto, ellos me dieron una serie de útiles comandos y cambios de archivos que inmediatamente resolvieron mi problema. Sin embargo, nunca hubiera sido capaz de encontrar esos trucos por mi cuenta, aunque semanas más tarde llegué a ser mucho más hábil con el código fuente del Proyecto X. Cuando pregunté cómo esperaban que los nuevos usuarios descubrieran por sí solos estos ajustes, fruncieron el entrecejo y respondieron que eso siempre había sido bastante intuitivo para ellos
Un problema muy común entre los desarrolladores de software (no exclusivamente de los que trabajan en proyectos de software libre) es la falacia de que la falta de intuitividad es más bien específico de un problema determinado que específico de la audiencia: lo que es fácil para ellos será naturalmente fácil para cualquier otro.6
Por tanto, no se molestan en simplificar cualquier cosa que ellos categoricen como intuitivo. Este problema es particularmente fuerte en los proyectos de Software libre creados por miembros de la comunidad que invierten tiempo solamente en construir las características que a ellos les gustaría tener (ver desarrollo no centrado en el cliente), y en el hecho de que las audiencias a menudo no están tan bien definidas como en el software comercial (porque literalmente no has de vender a un grupo específico). También, porque los proyectos de Software libre no tienen los expertos en usabilidad que los proyectos de software comercial pueden contratar.
El resultado es que los proyectos de software libre están hechos por programadores para programadores, los cuales no pueden comprender porqué el público en general debería molestarse en usar software propietario cuando el software libre funciona tan bien para ellos. Mientras tanto, el resto del mundo comienza a asociar "Open Source" con software que solamente es accesible para la Élite Tecnocrática.
Antes de comenzar cualquier proyecto de software libre, una decisión consciente debería ser tomada acerca de si la audiencia objetivo son otros programadores o el público común. Si es este último, debería de haber un esfuerzo sostenido para asegurarse de que todos los elementos del proyecto son accesibles para dicha audiencia objetivo. Programar para uno mismo es una trampa en la que se cae fácilmente pero que necesita ser evitada a cualquier coste cuando no es procedente.
CEGUERA RELIGIOSA
"demasiado a menudo, la gente muestra sus filias tecnológicas en sus mangas (o incluso en sus camisetas)" - Tim O'Reilly 7
Desde el comienzo de la era Hacker, programadores de todo tipo han sido "desafortunadamente intolerantes y fanáticos sobre aspectos técnicos" 8. Así que cuando se trata de devotos desarrolladores de software libre hay una fuerte tendencia a rechazar inmediatamente todo el software propietario y cualquier cosa que se pueda hacer con software no-libre. Debido a las características filosóficas y sociológicas que subyacen al movimiento de Software Libre, esta resistencia es particularmente cerril.
Mientras esto ha tenido la ventaja de incrementar el uso del software libre entre los propios programadores, desafortunadamente ha tenido el efecto secundario de apartar a la comunidad libre del aprendizaje de lo que el software propietario tiene para enseñar.
Conceptos inventados en el contexto del software propietario son automáticamente rechazados asumiendo que no es posible aprender nada proveniente de los competidores del movimiento libre.
Hay todavía muchas cosas que el software disponible para Windows hace mejor que cualquier actual sistema basado en Unix. En vez de admitir que Windows va por delante en algunas áreas, la tendencia es simplemente ignorar esas áreas. Del mismo modo, desde el momento en que Apple tuvo éxito con Mac OS X, la comunidad del software libre debería estar invirtiendo cantidades significativas de esfuerzo y tiempo para clonar el buen trabajo de Apple, en vez de insistir en que GNOME y KDE son igualmente útiles.
Pelear por defender una idea es una acción honorable, pero negarse a reconocer que puede haber debilidades en la propia posición -para identificarlas y remediarlas- es un problema lo suficientemente grande en el movimiento de software libre para que merezca estar el primero en la lista de los más importantes cinco problemas.
CONCLUSIONES
Creo que el movimiento libre ha producido ingentes cantidades de valioso software, además de haber despertado en la sociedad las ideas del acceso libre y el contenido abierto. La idea de libertad de información ha sido mantenida por la cultura hacker desde los comienzos en los laboratorios del MIT 9, y aún permanece como motivo de discusión hoy.
El software libre está incrementando su uso en las naciones en desarrollo, donde el coste del software propietario es demasiado alto, y por los gobiernos alrededor del mundo que se resisten a depender de una compañía propietaria.
Sin embargo, la tecnología libre continúa permaneciendo fuera de la gran mayoría de los usuarios de ordenadores. Con el objetivo de atraer a estos usuarios, creo que estas cinco cuestiones que he mencionado deben ser seriamente tomadas en cuenta y resueltas activamente. Debido a los incrementos en el uso de de software libre, estos cambios deberían tener lugar tan pronto como sea posible. Deberían ser resueltos antes de que lo que tiene que mostrar el software libre se vuelva atrás.
Algunas de estas cuestiones requieren simplemente un cambio de esquemas mentales, y algunas de ellas conllevan más trabajo, pero al final lo que deberían producir es lo que siempre debió ser el primer objetivo en cualquier caso: software de alta calidad.
SOBRE LA AUTORA
Michelle Lavesque es una investigadora del Citizen lab en el centro Munk de estudios internacionales y estudiante del departamento de Ciencias de la Computación de la Universidad de Toronto. Su trabajo incluye diseñar e implementar programas para identificar y evitar los filtros impuestos por entidades estatales a Internet. El pasado verano ella y dos colegas viajaron a Guatemala y Chiapas, México, para estudiar cómo la tecnología informática -especialmente la tecnología libre- puede ser usada para beneficiar a la sociedad civil en las naciones en vías de desarrollo. Del viaje se realizó un documental titulado "Hacktivista".
Los errores e imprecisiones que pudiere haber en este texto en español son exclusivamente debidos al traductor.
Puedes contactar con Michelle en: ml(-arroba-)cs.toronto.edu
Puedes contactar con el autor de la traducción al español en : jomaweb(-arroba-)yahoo.es
NOTAS AL PIE
1. En este artículo, uso el termino general de Open Source aunque a menudo estoy exclusivamente refiriéndome al software libre. Así mismo, cuando uso el término "Proyecto Open Source", me refiero usualmente a proyectos que tienen una base superior a uno o dos colaboradores. También soy consciente de que algunas compañías liberan versiones �libres� de su software, y aunque ciertamente aprecio su donación, excluyo estos proyectos de la definición que uso en este artículo para �Open Source�, pues muchas de mis afirmaciones no se pueden aplicar a ellos. Hago estas generalizaciones en aras de la simplificación y sin motivación ideológica ninguna. (N. del T.: En mi caso, he elegido utilizar el equivalente español: �software libre� o �código abierto�, atendiendo a la misma significación que la autora quiere darle al concepto �Open Source�.)
2. Mozilla FireFox http://www.mozilla.org/products/firefox/, enlace activo el 20 Febrero 2004
3. Manual de Instalación de Debian, Capítulo 3
4. �recibir reportes de muchos usuarios es algo inusual; mi estimación es que tan solo el 10% de los usuarios tienen alguna idea de dónde están los grupos de news (y la mayoría de ellos merodean sin sentido el 90% del tiempo), y de estos, menos del 1% de usuarios de Mozilla han encontrado alguna vez un bug." Nakakoji et al., 2002.
5. �Simplemente no les gusta hacer cosas aburridas para gente estúpida!� - Bruce Sterling, 2002
6. "Mientras los hackers pueden ser muy buenos diseñando interfaces para otros hackerss, tienden a ser pobres en el modelado de los procesos de pensamientos del otro 95% de la población lo suficiente como para escribir interfaces que �Juan Cualquiera Usuario� y su tia Tillie pagarian por tener." - Eric S. Raymond, 1999.
7. O�Reilly, p. xii.
8. A Portrait of J. Random Hacker.
9. Levy, p. 7.
REFERENCIAS EN EL TEXTO
"Debian Installation Manual," at http://www.debian.org/releases/stable/i386/ch-preparing.en.html, accessed 20 February 2004.
Steven Levy, 1984. Hackers. New York: Penguin.
K. Nakakoji, Y. Yamamoto, Y. Nishinaka, K. Kishida and Y. Ye, 2002. "Evolution Patterns of Open-Source Software Systems and Communities," Proceedings of International Workshop on Principles of Software Evolution, at http://www.kid.rcast.u-tokyo.ac.jp/~kumiyo/mypapers/IWPSE2002.pdf, accessed 22 March 2004.
Tim O?Reilly, 1999. "Forward," In: Jon Udell. Practical Internet Groupware. Sebastopol, Calif.: O?Reilly Associates.
"Portrait of J. Random Hacker," at http://info.astrian.net/jargon/A_Portrait_of_J._Random_Hacker/Weaknesses_of_the_Hacker_Personality.html, accessed 20 February 2004.
Eric S. Raymond, 1999. "The Revenge of the Hackers," at http://www.oreilly.com/catalog/opensources/book/raymond2.html, accessed 20 February 2004.
Bruce Sterling, 2002. "A Contrarian Position on Open Source," at Http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html, accessed 20 February 2004.
HISTORIA EDITORIAL
Paper recibido el 1 de Marzo de 2004; aceptado para publicación el 15 de Marzo de 2004.
OPEN SOURCE, SEGÚN MICHELLE LAVESQUE
Leí este artículo en inglés y me pareció que daba en el clavo de una manera tan contundente que solicité permiso escrito a su autora para traducirlo y colgarlo aquí. Estoy totalmente de acuerdo con lo que su autora dice y su visión del software libre es la mia.CUESTIONES FUNDAMENTALES DEL DESARROLLO DE SOFTWARE "OPEN SOURCE"
, por Michelle Levesque.RESUMEN
A pesar del creciente éxito del movimiento de Software Libre, la mayoría del público en general sigue viéndolo como algo inaccesible. Este artículo presenta cinco problemas fundamentales con la actuales tendencias de desarrollo del software libre, explora porqué dichas cuestiones están deteniendo su avance, y ofrece soluciones que pueden ayudar a vencer estos problemas.
La carencia de interés en el diseño de interfaces de usuario provoca que se prefieran los interfaces más intuitivos del software propietario.
El software de código abierto tiende a carecer de documentación completa y accesible para retener a los usuarios. Los desarrolladores se centran en las características de su software, más que en asegurarse de que tenga una base sólida . Los desarrolladores tienden también a programar para sí mismos como objetivo, en vez de hacerlo para el público general.
Por último, hay una comúnmente reconocida terquedad de los programadores "Open Source" en el rechazo a aprender las lecciones que el software propietario tiene que ofrecer. Si el software de código abierto desea llegar a ser extensamente utilizado y adoptado por el público en general, estos cinco problemas han de ser superados.
Contenidos:
Introducción
Diseño de interfaz de usuario
Documentación
Desarrollo no centrado en cliente
Programación para programadores
Ceguera religiosa
Conclusiones
Sobre la Autora
Notas al Pie
Referencias
INTRODUCCIÓN
"Es mi proyecto Open Source y hago lo que quiero con él"
En los últimos meses, me he visto en la responsabilidad de coger un proyecto de Open Source (para no señalar a nadie, lo llamaremos Proyecto X) y adaptarlo para uso académico.
Aunque no voy a presumir de ser una experta en el reino de todas las tendencias de programación Open Source, tengo bastante experiencia con él: lo uso constantemente siempre que me es posible (apoyo totalmente la corriente sociológica que hay detrás del movimiento), he sido jugadora importante en algunos pequeños proyectos de código abierto todavía en desarrollo, y ahora tengo la experiencia de unos cuantos meses trabajando con el proyecto X.
Así, que a pesar de no ser una experta, creo que mi opinión puede considerarse como relativamente bien fundamentada.
Tengo cinco quejas fundamentales sobre el "Open Source"1 pero me gustaría aclarar un par de cosas. Primero, siempre hay excepciones a cualquier regla. Por ejemplo, creo que relativamente pocas de estas quejas se aplican al navegador FireFox2 , el cual continúa sobrepasando mis expectativas. Estoy tratando tendencias generales que he advertido, no casos específicos. En segundo lugar, no creo que estos sean problemas irresolubles. El propósito de este documento es despertar conciencias -no quejarse sin tino- en la esperanza de que la comunidad de código abierto cambie sus esquemas mentales sobre estas cuestiones y trabaje para mejorar.
Dicho esto, he encontrado que los cinco defectos más importantes del software libre son los siguientes:
1. Diseño de Interfaz de usuario
2. Documentación
3. Desarrollo no centrado en el cliente
4. Programación para programadores
5. Ceguera Religiosa
DISEÑO DE LA INTERFAZ DE USUARIO
El proyecto X viene con un limpio calendario interactivo. Justo como se podría esperar, puedes programar acontecimientos, compartir acontecimientos con otros, y resolver conflictos. Sin embargo, nadie lo sabrá nunca, porque para ver el módulo del calendario, tienes que conocer la dirección URL del Módulo previamente: no hay vínculos, aparte de uno enterrado a varias páginas de profundidad. La interfaz del Proyecto X es una pesadilla. Hay montones de pestañitas coloreadas y la disposición estética es ciertamente agradable, pero es extraordinariamente difícil descubrir cómo hacer aún las más sencillas tareas.
Solamente una parte muy pequeña de la interfaz es intuitiva, y algunas tareas no pueden ser realizadas a través del entorno gráfico : tienes que editar la base de datos a mano.
Por alguna razón, los proyectos libres parece que tienen muchos problemas con el diseño de interfaz. Un buen ejemplo de esto es la situación del entorno Mac OS. He visto gente con una experiencia en computadoras relativamente pequeña navegar por entre el escritorio OS X durante pocos minutos, y entonces, girarse y decirme "fluye muy agradablemente" y "lo veo más agradable que el que uso habitualmente". Si pongo a las mismas personas con KDE o GNOME, probablemente perderán la mitad del tiempo luchando contra su propia intuición, y la otra mitad preguntándose porqué fueron obligados a sentarse en frente de semejante escritorio patoso cuando su computadora con Windows XP funciona bastante mejor. Independientemente de si piensas o no que KDE y GNOME son interfaces pobres (ver ceguera religiosa) Mac OS X ha probado ser mucho más usable, amistoso, intuitivo que cualquier otro interfaz Unix que la comunidad libre haya ofrecido.
Sospecho que no hay una sola razón para la pobre calidad de las interfaces pero hay algunas explicaciones que he oído vagando por los círculos del software libre: los "geeks" valoran la integridad por encima de la belleza; las diferencias entre grupos dentro de las comunidades de software libre; es intuitivo para los programadores así que ¿porqué habría que arreglarlo? (ver Programación para programadores), la creencia de que un bonito interfaz puede ser siempre programado más tarde una vez se ha hecho el trabajo "real", la creencia de que el diseño de interfaz no es un trabajo "real", y muchas otras.
Muchas de estas causas suenan muy plausibles, y sospecho que la verdadera razón para la negligencia en el caso de las interfaces de usuario es una combinación de muchas de ellas. Sin embargo, si la comunidad de software libre desea realmente prosperar y que sus herramientas las use el público en general , es fundamentalmente necesario reconocer que la mayoría de los usuarios nunca inventarán un algoritmo particularmente inteligente para sincronizar la edición multihilo de su compleja estructura de datos. Lo que el usuario verá -y por lo que juzgará el proyecto- es su interfaz. Si es inadecuado, nadie aparte de los Geeks tocará el programa.
LA DOCUMENTACIÓN
El Proyecto X tiene una documentación bastante extensa, lo cual no es siempre el caso en los proyectos de software libre. Desafortunadamente, la documentación es para una versión desechada del Proyecto y apenas han incluido el número de versión más reciente en el título. También, se asume que el sistema del usuario está configurado exactamente de la misma manera que el sistema del escritor de la documentación . También debes de ser experto en la administración del sistema, y saber cómo manipular el lenguaje de programación en el que está escrito el programa, porque los errores que van a ocurrir no están mencionados en la documentación, y vas a necesitar saber cómo depurarlos.
Los proyectos libres, suelen tener un gran problema para aportar una documentación decente, y eso si tienen documentación alguna. Debido a que no tienen obligación contractual de proveer de dicha documentación suele ser más bien una guia general de uso más que un manual completo que puedas entregar a un novato.
Imagina lo que le debe parecer la siguiente frase a alguien que sabe poco de Unix y lo está instalando por primera vez: "necesitarás una lista de los Checksums MD5 para los archivos binarios. Si tienes el programa md5sum, puedes comprobar que tus archivos no están corruptos ejecutando md5sum -v -c md5sum.txt" 3. La más común respuesta a esta queja es "si no puede comprenderlo, entonces no está preparado para instalarlo", pero entonces, ¿cómo se espera que aprendan?. La documentación debería siempre acercarse al común denominador más bajo.
También, cualquiera que ha tenido alguna vez que depurar un problema en el software libre sabe que las respuestas no están en la documentación: se encuentran el los artículos de Usenet, boletines electrónicos e históricos de chats. Los usuarios que no pueden imaginarse cómo hacer algo corren al grupo de news alt.proyectoX.desarrollo y preguntan la misma pregunta que cientos de usuarios han hecho ya antes. Cuando algún experto se compadece de sus apuros, responde a su cuestión pero nunca documenta su respuesta. Así que cuando el próximo usuario se encuentra con el mismo problema, todo el proceso ha de ser repetido. Además, estoy haciendo la suposición fundamentalmente errónea de que los usuarios son capaces de encontrar estas fuentes alternativas de documentación 4 , o son lo suficientemente pacientes y les preocupa el producto para molestarse. Sin la documentación adecuada, los proyectos "Open Source" están, por definición, en desventaja.
DESARROLLO NO ORIENTADO AL CLIENTE
Una vez instalado el Proyecto X, tienes un poderoso conjunto de herramientas al alcance de tus dedos para realizar una amplia variedad de tareas con docenas de impresionantes opciones asociadas a cada una de estas herramientas. Desgraciadamente, tras instalar el proyecto X, el grupo Unix se divide. Durante mis numerosas correspondencias con los desarrolladores de la rama principal, me mostraron dónde podía descargar parches para los muchos problemas que existían en el proyecto liberado y me recordaron que aunque había todavía algunos problemas, el proyecto X tenía ciertamente multitud de "molonas" opciones, ¿o no?.
En la primera clase sobre Herramientas de Software y Programación de Sistemas a la que asistí, se nos instruyó cuidadosamente en que las mejores herramientas de software eran pequeños programas que hacían una cosa bien e interactuaban limpiamente con otras herramientas. Esto suena como la filosofía que es perfectamente adoptada por el movimiento de Software Libre: si tienes muchos colaboradores y todos ellos crean uno (o muchos) pequeños programas que hacen una sola cosa bien e interactúan limpiamente con otros programas, un limpio y poderoso sistema surge de todo ello. Y creo que esto ha sido demostrado por la durabilidad y longevidad del sistema operativo Unix.
Pero en algún momento a lo largo del camino, creo que los programadores de software libre olvidaron estos conceptos fundamentales. La obsesión por las opciones (Features) comenzó a establecerse (y por una vez no fue debido a que hubiera clientes pidiendo más características). Es el programador individual que quiere añadir la opción al proyecto que permita que el actual gráfico en 2D se muestre en 3D (accediendo por teléfono móvil, navegador y mensajería instantánea), y entonces lo hace funcionar con cualquier combinación de teclas, clicks de botones, gestos de ratón, comandos de voz, y sensor del puntero láser. No hay nada excitante en ser un programador que se dedica a limpiar algunas de las librerías convirtiendo bloques de código comunes en funciones.
Con demasiado énfasis en las opciones añadidas y "chorraditas" de Geeks, los aspectos fundamentales de la programación del proyecto se pierden. No siempre ocurre en funcionalidades centrales del proyecto X. A menudo es una deficiencia en centrarse en el interfaz de usuario (ver Diseño de interfaz de usuario), la documentación, los estándares de codificación, la seguridad, dirección del proyecto, especificación de la audiencia objetivo, (ver programación para programadores), etc. Es altamente improbable que todo esto ocurra dentro de un solo proyecto, pero sospecho que al menos algunos de estos errores ocurren en la mayoría de los proyectos de software libre. Y creo firmemente que esto se debe a las ventajas personales de ignorar el trabajo mundano y dedicar más tiempo construyendo "el material divertido".5
PROGRAMACIÓN PARA PROGRAMADORES
La primera vez que instalé el Proyecto X, me topé con un obstáculo que no pude sortear, así que me dí una vuelta por el canal IRC del Proyexto X. Después de explicar mi problema a los programadores del Proyecto, ellos me dieron una serie de útiles comandos y cambios de archivos que inmediatamente resolvieron mi problema. Sin embargo, nunca hubiera sido capaz de encontrar esos trucos por mi cuenta, aunque semanas más tarde llegué a ser mucho más hábil con el código fuente del Proyecto X. Cuando pregunté cómo esperaban que los nuevos usuarios descubrieran por sí solos estos ajustes, fruncieron el entrecejo y respondieron que eso siempre había sido bastante intuitivo para ellos
Un problema muy común entre los desarrolladores de software (no exclusivamente de los que trabajan en proyectos de software libre) es la falacia de que la falta de intuitividad es más bien específico de un problema determinado que específico de la audiencia: lo que es fácil para ellos será naturalmente fácil para cualquier otro.6
Por tanto, no se molestan en simplificar cualquier cosa que ellos categoricen como intuitivo. Este problema es particularmente fuerte en los proyectos de Software libre creados por miembros de la comunidad que invierten tiempo solamente en construir las características que a ellos les gustaría tener (ver desarrollo no centrado en el cliente), y en el hecho de que las audiencias a menudo no están tan bien definidas como en el software comercial (porque literalmente no has de vender a un grupo específico). También, porque los proyectos de Software libre no tienen los expertos en usabilidad que los proyectos de software comercial pueden contratar.
El resultado es que los proyectos de software libre están hechos por programadores para programadores, los cuales no pueden comprender porqué el público en general debería molestarse en usar software propietario cuando el software libre funciona tan bien para ellos. Mientras tanto, el resto del mundo comienza a asociar "Open Source" con software que solamente es accesible para la Élite Tecnocrática.
Antes de comenzar cualquier proyecto de software libre, una decisión consciente debería ser tomada acerca de si la audiencia objetivo son otros programadores o el público común. Si es este último, debería de haber un esfuerzo sostenido para asegurarse de que todos los elementos del proyecto son accesibles para dicha audiencia objetivo. Programar para uno mismo es una trampa en la que se cae fácilmente pero que necesita ser evitada a cualquier coste cuando no es procedente.
CEGUERA RELIGIOSA
"demasiado a menudo, la gente muestra sus filias tecnológicas en sus mangas (o incluso en sus camisetas)" - Tim O'Reilly 7
Desde el comienzo de la era Hacker, programadores de todo tipo han sido "desafortunadamente intolerantes y fanáticos sobre aspectos técnicos" 8. Así que cuando se trata de devotos desarrolladores de software libre hay una fuerte tendencia a rechazar inmediatamente todo el software propietario y cualquier cosa que se pueda hacer con software no-libre. Debido a las características filosóficas y sociológicas que subyacen al movimiento de Software Libre, esta resistencia es particularmente cerril.
Mientras esto ha tenido la ventaja de incrementar el uso del software libre entre los propios programadores, desafortunadamente ha tenido el efecto secundario de apartar a la comunidad libre del aprendizaje de lo que el software propietario tiene para enseñar.
Conceptos inventados en el contexto del software propietario son automáticamente rechazados asumiendo que no es posible aprender nada proveniente de los competidores del movimiento libre.
Hay todavía muchas cosas que el software disponible para Windows hace mejor que cualquier actual sistema basado en Unix. En vez de admitir que Windows va por delante en algunas áreas, la tendencia es simplemente ignorar esas áreas. Del mismo modo, desde el momento en que Apple tuvo éxito con Mac OS X, la comunidad del software libre debería estar invirtiendo cantidades significativas de esfuerzo y tiempo para clonar el buen trabajo de Apple, en vez de insistir en que GNOME y KDE son igualmente útiles.
Pelear por defender una idea es una acción honorable, pero negarse a reconocer que puede haber debilidades en la propia posición -para identificarlas y remediarlas- es un problema lo suficientemente grande en el movimiento de software libre para que merezca estar el primero en la lista de los más importantes cinco problemas.
CONCLUSIONES
Creo que el movimiento libre ha producido ingentes cantidades de valioso software, además de haber despertado en la sociedad las ideas del acceso libre y el contenido abierto. La idea de libertad de información ha sido mantenida por la cultura hacker desde los comienzos en los laboratorios del MIT 9, y aún permanece como motivo de discusión hoy.
El software libre está incrementando su uso en las naciones en desarrollo, donde el coste del software propietario es demasiado alto, y por los gobiernos alrededor del mundo que se resisten a depender de una compañía propietaria.
Sin embargo, la tecnología libre continúa permaneciendo fuera de la gran mayoría de los usuarios de ordenadores. Con el objetivo de atraer a estos usuarios, creo que estas cinco cuestiones que he mencionado deben ser seriamente tomadas en cuenta y resueltas activamente. Debido a los incrementos en el uso de de software libre, estos cambios deberían tener lugar tan pronto como sea posible. Deberían ser resueltos antes de que lo que tiene que mostrar el software libre se vuelva atrás.
Algunas de estas cuestiones requieren simplemente un cambio de esquemas mentales, y algunas de ellas conllevan más trabajo, pero al final lo que deberían producir es lo que siempre debió ser el primer objetivo en cualquier caso: software de alta calidad.
SOBRE LA AUTORA
Michelle Lavesque es una investigadora del Citizen lab en el centro Munk de estudios internacionales y estudiante del departamento de Ciencias de la Computación de la Universidad de Toronto. Su trabajo incluye diseñar e implementar programas para identificar y evitar los filtros impuestos por entidades estatales a Internet. El pasado verano ella y dos colegas viajaron a Guatemala y Chiapas, México, para estudiar cómo la tecnología informática -especialmente la tecnología libre- puede ser usada para beneficiar a la sociedad civil en las naciones en vías de desarrollo. Del viaje se realizó un documental titulado "Hacktivista".
Los errores e imprecisiones que pudiere haber en este texto en español son exclusivamente debidos al traductor.
Puedes contactar con Michelle en: ml(-arroba-)cs.toronto.edu
Puedes contactar con el autor de la traducción al español en : jomaweb(-arroba-)yahoo.es
NOTAS AL PIE
1. En este artículo, uso el termino general de Open Source aunque a menudo estoy exclusivamente refiriéndome al software libre. Así mismo, cuando uso el término "Proyecto Open Source", me refiero usualmente a proyectos que tienen una base superior a uno o dos colaboradores. También soy consciente de que algunas compañías liberan versiones �libres� de su software, y aunque ciertamente aprecio su donación, excluyo estos proyectos de la definición que uso en este artículo para �Open Source�, pues muchas de mis afirmaciones no se pueden aplicar a ellos. Hago estas generalizaciones en aras de la simplificación y sin motivación ideológica ninguna. (N. del T.: En mi caso, he elegido utilizar el equivalente español: �software libre� o �código abierto�, atendiendo a la misma significación que la autora quiere darle al concepto �Open Source�.)
2. Mozilla FireFox http://www.mozilla.org/products/firefox/, enlace activo el 20 Febrero 2004
3. Manual de Instalación de Debian, Capítulo 3
4. �recibir reportes de muchos usuarios es algo inusual; mi estimación es que tan solo el 10% de los usuarios tienen alguna idea de dónde están los grupos de news (y la mayoría de ellos merodean sin sentido el 90% del tiempo), y de estos, menos del 1% de usuarios de Mozilla han encontrado alguna vez un bug." Nakakoji et al., 2002.
5. �Simplemente no les gusta hacer cosas aburridas para gente estúpida!� - Bruce Sterling, 2002
6. "Mientras los hackers pueden ser muy buenos diseñando interfaces para otros hackerss, tienden a ser pobres en el modelado de los procesos de pensamientos del otro 95% de la población lo suficiente como para escribir interfaces que �Juan Cualquiera Usuario� y su tia Tillie pagarian por tener." - Eric S. Raymond, 1999.
7. O�Reilly, p. xii.
8. A Portrait of J. Random Hacker.
9. Levy, p. 7.
REFERENCIAS EN EL TEXTO
"Debian Installation Manual," at http://www.debian.org/releases/stable/i386/ch-preparing.en.html, accessed 20 February 2004.
Steven Levy, 1984. Hackers. New York: Penguin.
K. Nakakoji, Y. Yamamoto, Y. Nishinaka, K. Kishida and Y. Ye, 2002. "Evolution Patterns of Open-Source Software Systems and Communities," Proceedings of International Workshop on Principles of Software Evolution, at http://www.kid.rcast.u-tokyo.ac.jp/~kumiyo/mypapers/IWPSE2002.pdf, accessed 22 March 2004.
Tim O?Reilly, 1999. "Forward," In: Jon Udell. Practical Internet Groupware. Sebastopol, Calif.: O?Reilly Associates.
"Portrait of J. Random Hacker," at http://info.astrian.net/jargon/A_Portrait_of_J._Random_Hacker/Weaknesses_of_the_Hacker_Personality.html, accessed 20 February 2004.
Eric S. Raymond, 1999. "The Revenge of the Hackers," at http://www.oreilly.com/catalog/opensources/book/raymond2.html, accessed 20 February 2004.
Bruce Sterling, 2002. "A Contrarian Position on Open Source," at Http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html, accessed 20 February 2004.
HISTORIA EDITORIAL
Paper recibido el 1 de Marzo de 2004; aceptado para publicación el 15 de Marzo de 2004.
Programación | jomaweb | 7 Comentarios | Enlace
Referencias (TrackBacks)
URL de trackback de esta historia http://jomaweb.blogalia.com//trackbacks/17644
Comentarios
| 1 |
|
||
|
Comentario puesto para poder leer el artículo sin que se salga del navegador... |
|||
| 2 |
|
||
|
Pues no ha funcionado... |
|||
| 3 |
|
||
|
Borra los dos comentarios anteriores si te da la gana... para lo que sirven. |
|||
| 4 |
|
||
|
Yo he trabajado durante dos años con open source, concretamente RedHat, ZOPE y PostgreSQL, y la experiencia fue muy gratificante.
|
|||
| 5 |
|
||
|
Me parece un articulo en extremo interesante. Llevo algun tiempo desarrollando proyectos de empresas privadas y sigo muy de cerca el movimiento Open Source. Creo que la autora ha dado en el clavo en muchas de las cosas que pensaba acerca del desarrollo bajo esa filosofia, y aun cuando parti siendo un correligionario de dicha filosofia, puedo decir que el tiempo me ha dado la capacidad de analizarlo friamente, concuerdo con el analisis.
|
|||
| 6 |
|
||
|
Tranquilos... todo llegará. Hace poco lei que el guru de la usabilidad iba diciendo por ahí que había que crear unos estandares de usabilidad, por ahí se empieza, de momento yo sigo observando de cerca a Google. |
|||