sábado, 24 de noviembre de 2012

Sobre medios y objetivos

¿Qué guía el desarrollo de un proyecto de software libre? Esta es para mí una pregunta muy interesante, donde hay muchas respuestas válidas. Con ella apunto a analizar cómo se decide hacia dónde debe ir el futuro de un proyecto, cuáles son sus objetivos a corto, mediano y largo plazo, en qué aspectos del proyecto se deben centrar los mayores esfuerzos, o cómo descubrir los puntos fuertes y débiles del mismo, entre otras cosas. En general se distinguen muy fácilmente los casos extremos. Por un lado, proyectos respaldados por grandes organizaciones que toman decisiones en grupo, luego de discusiones (que pueden ser formales y protocolares, o simples encuentros en una sala de chat o mediante envío de mails informales en listas dedicadas). Estos proyectos suelen tener una buena estructura jerárquica, objetivos claros en varios frentes a largo plazo bien documentados, a veces intereses políticos, etc. Por otro lado están los proyectos pequeños, que empiezan una o unas pocas personas, y que básicamente suelen seguir los caprichos de esas pocas personas, o guiarse por sus necesidades e intereses particulares. En el medio de todo esto, está la gran mayoría de los proyectos, y hay tantas y tan diversas variantes que no se me ocurre ni cómo agruparlas.

Los del medio son para mí los más interesantes, por varios motivos. Por un lado, no siempre cuentan con grandes recursos como para tener especialistas dedicando buen tiempo en cada área, sino que en general son mayormente programadores. El programador puede ser un genio implementando algoritmos complicados, o exprimiendo tarjetas gráficas, pero no tener idea o sentido común acerca del diseño de interfaces usables y estéticas, las estrategias de marketing, la generación de buena documentación para el usuario final, y el desarrollo de un sitio web decente y atractivo, por dar algunos ejemplos. Por otro lado, si el proyecto no es tan chico, puede tener una buena cantidad de usuarios y, como ya mencioné antes, estos son su mayor recurso. Son fuente de ideas nuevas, mano de obra para testing, sus preguntas generan documentación casi sin pretenderlo, etc.

Y el tipo de usuario que un proyecto tiene depende mucho del objetivo del proyecto. Herramientas para cosas muy técnicas o específicas suelen atraer a usuarios formados, mientras que herramientas para tareas cotidianas o herramientas didácticas por ejemplo suelen atraer a usuarios con menor grado de conocimiento o experiencia, ya sea en el area de aplicación de la herramienta, como de sus tareas y posibilidades como usuario dentro del proceso de desarrollo de software libre en general. Con PSeInt y ZinjaI, me ocurre algo muy particular (o no, tal vez sea más común de lo que pienso), que es que conviven ambos tipos de usuario. En PSeInt, tengo por usuarios tanto a los profesores (usuarios que supongo tendrán un muy buen conocimiento acerca de programación y desarrollo de software), como a los alumnos (usuarios que probablemente están haciendo sus primeras armas en la informática). Con ZinjaI, pasa algo similiar; y aún hay en este caso un nivel más, que son los programadores ya formados (ni alumnos ni docentes) que quieren hacer cosas con C++ y eligen ZinjaI como IDE para ello. PSeInt tiene un perfil exclusivamente didáctico (y es mi objetivo mantener ese límite), pero ZinjaI espero que pueda utilizarse tanto en el aula, como en, digamos, ambientes productivos, donde aparece ese tercer grupo. Y es en ese tercer grupo donde me quiero centrar hoy. Porque además es donde estoy parado la mayor parte del tiempo. Utilizo ZinjaI en el aula, pero más lo utilizo para desarrollar todo tipo de productos, tanto libres (ZinjaI, MotoGT, PSeInt, etc) como privados, cerrados y/o comerciales. Y entonces, estoy pensando en usuarios con buenos conocimientos de programación, tal vez experiencia con otros IDEs o conjuntos de herramientas, y que necesitan desarrollar cómodamente.

Y aquí me quiero detener para comentar un caso que me parece icónico, que es el de Blender. Blender es un software libre para creación de contenido 3D (mayormente animaciones), con una calidad tanto en el proceso de desarrollo como en el producto final altísima. Claro está que es un caso donde hay un gran grupo de personas involucrado, muy organizado, y que se las arregla para conseguir buen financiamiento y otros recursos principalmente a través de una fundación ad-hoc (la Blender Foundation). Pero hay algo muy interesante respecto a su estrategia, tanto para conseguir fondos y publicitarse, como para mejorar el producto. La Blender Foundation desarrolla cada tanto (usualmente entre uno y dos años), a través de el Blender Institute un proyecto, no de software, sino un producto 3D a generar con Blender, usualmente un cortometraje (aunque una vez fue un juego). Este producto requiere que con Blender se puedan hacer ciertas cosas, y que los artistas contratados para llevarlo a cabo se sientan cómodos haciendolas. Por ejemplo, para Big Buck Bunny, querían mejorar la forma en que Blender permitía hacer pelaje y pasto, manejar y renderizar ambientes abiertos, animar movimientos y expresiones en personajes, etc. Los desarrolladores de Blender trabajaron en todo momento codo a codo con los artistas involucrados. Entonces, durante el proceso de desarrollo de la película, se identificaron puntos flojos y carencias en las funcionalidades de Blender relacionadas a este tipo de animaciones y, como resultado de experimentar con Blender para un proyecto real y de gran complejidad, se mejoraron todas esas características, se pulieron detalles de usabilidad y agilizó el workflow para ese tipo de proyectos, se probaron los cambios y nuevos desarrollos en un ambiente productivo, se obtuvo un producto con el cual promocionar Blender y obtener además alguna ganancia para cubrir los gastos, y muchas otras muy buenas consecuencias más. En general, lo mismo sucedió con los otros proyectos: había algo que mejorar, se organizó un grupo de artistas para trabajar con eso y de programadores para trabajar en eso, y se obtuvo al final un Blender mejorado y un producto 3D de gran calidad para mostrar. Desde  mi punto de vista es un gran modelo de desarrollo que muchos otros proyectos deberían imitar.

(imágen original en http://peach.blender.org/wp-content/uploads/evil-frank.png)

Obviamente no pretendo poner a ZinjaI ni a su proceso de desarrollo a la altura de Blender. No hay mucha gente, ni fundación, ni instituto, ni tanta calidad en el producto. Pero sí puedo intentar reducir algunas de estas ideas a una microescala y pensar cómo aplicarlas a bajo nivel. Salvando las distancias, es lo que ya he hecho con ZinjaI personalmente. Cuando empecé a desarrollar ZinjaI con el mismísimo ZinjaI tuve que mejorar la gestión de proyectos y los perfiles de configuración. Cuando en el trabajo tuve que implementar cosas sobre un código de mi director que utilizaba QT y que requería algunos pasos especiales en la compilación (llamadas al moc) tuve que agregar la pestaña "Secuencia" a las opciones de compliación de proyecto y unos cuantos detalles más para detectar cambios en los fuentes producidos por herramientas externas. Cuando quise que mis alumnos utilizaran alguna biblioteca libre para la parte visual de sus proyectos finales y decidí armar un ejemplo desarrollé la integración con wxFormBuilder. Cuando empecé a programar un generador de mallas paralelizable agregué la gestión de hilos en la interfaz de depuración (y pronto voy a tener que agregar una opción para ejecutar remótamente, para programar en mi notebook y mandar a ejecutar en un cluster por ejemplo). Y así hay muchos ejemplos de funcionalidades que se desarrollaron y probaron como efecto colateral de otro desarrollo.

Sin perder la premisa original de ZinjaI, que indica entre otras cosas que debe ser simple para el estudiante, y relativamente liviano, espero seguir mejorando su potencial en ambientes productivos. La idea es entonces, agregar todo lo necesario para que nadie diga que no puede usar ZinjaI en su trabajo, o para proyectos complejos, porque no le permite hacer tal o cual cosa; pero agregar esa posibilidad no debe significar agregar complejidad al flujo de trabajo del estudiante (no debe confundirlo, ni obligarlo a dar un paso más en sus tareas en el aula), sino que debe ser un opcional que el usuario avanzado pueda aprovechar cuando lo necesite. Entonces, para ir cerrando el post, quiero alentar a los usuarios de ZinjaI que hayan pasado la etapa de aprendizaje y estén dispuestos a hacer desarrollos reales (ya no ejercicios de libro), a continuar utilizando ZinjaI, para descubrir su potencia, para detectar sus falencias, y por qué no, para promocionarlo si finalmente logran llevar adelante el desarrollo exitosamente. De quienes tengan confianza en este IDE, me gustaría escuchar sus feedbacks, proporcionarles asistencia, y trabajar codo a codo desarrollando y probando las nuevas funcionalidades que sus proyectos requieran, y otras interacciones similares de forma que ambos resultemos beneficiados.

No hay comentarios:

Publicar un comentario