Yafray de la y a la y - Reflexiones sobre los proyectos de software libre.
cuando uno oye hablar del software libre por primera vez le asaltan un montón de dudas. ¿quién desarrolla ese software? ¿por qué se llama libre y no gratis? ¿gratis? ¿por qué se desarrolla y cómo? Si los roedores pudieran roerrobles, ¿cuántos robles roería un roedor? Intentaremos contestar a estas preguntas en el presente documento, siguiendo el ciclo de vida del proyecto en el que me he visto involucrado (en el sentido más amplio de la palabra) en los últimos años: Yafray.
Yafray. Bajo este nombre de lavavajillas se esconde yet another free raytracer, un raytracer gratuito y multiplataforma, creado por mi gran amigo Alejandro Conty Estévez. Un raytracer es un programa que se vale de una técnica llamada Raytracing para generar imágenes fotorrealistas con un computador, su desarrollo comenzó en Julio de 2002. Inicialmente se trataba de un raytracer básico para el sistema operativo GNU/Linux. Posteriormente se le fueron añadiendo funcionalidades, una de las más importantes fue el cargador de escenas en un formato propio utilizando xml. De este modo fue posible la exportación de escenas desde programas de modelado para la posterior generación de la imagen utilizando Yafray, este hecho produjo un gran interés en comunidades internacionales relacionadas con el mundo de los gráficos tridimensionales (elysiun -ahora Blender artists, Blender.org, Wings3d.org, entre otras), creándose programas que permitían la exportación de escenas desde los modeladores más importantes dentro del software libre como son Blender y Wings3d, como fruto de ese interés se amplió el desarrollo de Yafray a otros sistemas operativos aparte de GNU/Linux. Primero se llevó a cabo la traducción para sistemas operativos Windows. De manera casi simultanea se desarrollaron versiones para Mac OSX, actualmente, Yafray se basa en un modelo de plugins, en el cual el motor de render esta contenido en una librería separada del cargador xml. De esta manera, es relativamente sencillo construir cargadores o invocarlo desde otros programas. A su vez, el motor de render (librería principal) es el encargado de cargar, en tiempo de ejecución, los plugins relativos a los métodos de iluminación (Shaders, luces, etc). Esta modularidad ha facilitado su integración con Blender, en un principio todo el trabajo de desarrollo recaía sobre Alejandro Conty. A medida que pasaba el tiempo y el interés por Yafray aumentaba, aparecían nuevos desarrolladores y colaboradores. Lo que empezó como un proyecto personal para pasar las horas del verano de 2002, se acabó convirtiendo en un largo proyecto de software libre que involucra a programadores de todo el mundo y con una comunidad de cientos de usuarios, antes de entrar de lleno en el proyecto Yafray, me gustaría sentar las bases del modelo de software libre, sin pretender un análisis exhaustivo sobre el ciclo de vida del mismo. No hablaré aquí sobre herramientas de ingeniería.
O de desarrollo de una manera profunda. El objetivo de este documento, que es el apoyo a la charla del mismo nombre, es introducir al lector en la problemática del software libre, reflexionando sobre las motivaciones de sus desarrolladores, entendiendo el funcionamiento de las comunidades que orbitan alrededor de estos proyectos y sopesando las ventajas e inconvenientes de este modelo, existen multitud de estudios a este respecto mucho más precisos que este, en su mayoría elaborados con rigor científico por personas más capacitadas, pero no dejes de leer aún. Aunque no vayas a encontrar aquí una fuerte base teórica de ingeniería del software (libre), puede que te resulte interesante la experiencia del desarrollo del Yafray, ¿cómo se nutre de aportaciones desinteresadas y sobre todo, ¿cómo esta comunidad de desarrolladores y usuarios se apoya en otras comunidades mayores.
software libre.
Es de suponer que alguien que le sobre la evolución de proyectos de software libre sabe a qué se refiere ese tipo de software. Pero como todos hemos sido lectores despistados en alguna ocasión, hay que comentar una vez más que el software libre, según la definición del proyecto GNU, es aquel software que ofrece al usuario las siguientes libertades:libertad 0: la libertad de usar el programa, con cualquier propósito.
Libertad 1: la libertad de estudiar cómo funciona el programa, y adaptarlo a tus necesidades. El acceso al código fuente es una condición previa para esto.
Libertad 2: la libertad de distribuir copias, con lo que puedes ayudar a tu vecino.
Libertad 3: la libertad de mejorar el programa y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie. El acceso al código fuente es un requisito previo para esto.
en internet se puede encontrar una inmensa cantidad de literatura, documentación y faq sobre el esta filosofía. El lector que no esté familiarizado con el término debería detenerse en este punto y buscar información al respecto, no sólo para poder seguir con fluidez este documento, sino porque la idea que subyace bajo el concepto es digna de ser meditada. No hay que olvidar que dicha idea se ha convertido para muchos en toda una forma de vida, quizás el software libre parezca una idea actual, una vuelta de tuerca a las protestas contra el sistema. Incluso en EU han llegado a tachar de actitudes comunistas los principios en los que se basa. Pero realmente, aunque estemos acostumbrados al modelo de software propietario (comercial), en los inicios de la informática era imposible concebir el software como un producto aislado, susceptible de ser vendido.
Las licencias por el uso del software y las restricciones para ejecutarlo o copiarlo, sencillamente no existían, en aquellos tiempos los programas y las máquinas que los ejecutaban estaban íntimamente ligados. No existía el concepto de programa como pieza separada que se tiene hoy.
Tampoco había usuarios domésticos, sino que las personas que ejecutaban los programas solían tener muchos conocimientos de programación y por lo general eran científicos e ingenieros, entre estos usuarios expertos, lo normal era intercambiar y mejorar los programas, compartiendo sus modificaciones, que a veces recibían el nombre de hacks (de ahí la palabra hacker, tan mal utilizada en los últimos tiempos), uno de aquellos usuarios expertos era Richard Mathew Stallman (a veces nombrado por el acrónimo RMS, basado en su nombre de usuario en los computadores del mit), un personaje a la vez genial y controvertido, imprescindible para comprender el software libre, este físico, graduado en 1974 en Harvard, trabajaba en el laboratorio de inteligencia artificial del instituto de tecnología de Massachusetts (mit) desde 1971.
En su laboratorio disponían de una impresora que tenía ciertos problemas con la alimentación de papel, de manera que, se atascaba habitualmente y no había otra forma de descubrirlo que desplazarse hasta dónde estaba, Richard se puso en contacto con los fabricantes, con la idea de modificar el software que controlaba la impresora y hacer que enviase una señal al atascarse, de forma que no se perdiese tanto tiempo de trabajo, sin embargo, estos se negaron a facilitarle el código fuente, que son como los planos de un programa y que hace posible modificar su comportamiento.
Este episodio le contrarió mucho e hizo que terminase de consolidarse su idea de que el código fuente de los programas tenía que estar accesible para todo el mundo, movido por este deseo, abandonó el mit en enero de 1984, para iniciar el proyecto GNU.
GNU es un acrónimo recursivo qué significa GNU not Unix, GNU no es Unix, en referencia a que el proyecto busca desarrollar un sistema operativo de tipo Unix, pero libre, en sus comienzos, el proyecto GNU se concentró en desarrollar las herramientas necesarias para construir un sistema operativo, como editores y compiladores y en las utilidades básicas para la gestión del sistema.
Sobre 1985, Richard Stallman creó la licencia GPL (general public license) como mecanismo para proteger el software libre, sustentado sobre el concepto de copyleft. Mediante este concepto, se le da la vuelta a la idea de copyright, definiendo las cuatro libertades mencionadas anteriormente, uno de los conceptos que se suelen mezclar con el software libre (reconozco que me sucede habitualmente) es el de open source (código abierto). Podemos considerarlo como un error justificable, ya que en la práctica el software open source y el software libre comparten las mismas licencias. Aunque la FSF (free software foundation) opina que el movimiento open source es filosóficamente diferente del movimiento del software libre, apareció en 1998 con un grupo de personas, entre los que cabe destacar a Eric s. Raymond (autor de la catedral y el bazar y de fetchmail)y Bruce Perens (padre del proyecto Debian), que formaron la open source initiative (OSI). Buscaban darle mayor relevancia a los beneficios prácticos del compartir el código fuente, e interesar a las principales casas de software y otras empresas de la industria de la alta tecnología en el concepto.
Estos defensores ven que el término open source evita la ambigüedad del término inglés free en free software, mucha gente reconoce el beneficio cualitativo del proceso de desarrollo de software cuando cualquiera puede usar, modificar y redistribuir el código fuente de un programa. Esta es la idea subyacente de la obra de Raymond, la catedral y el bazar, que analizaremos más adelante. El movimiento del software libre hace especial énfasis en los aspectos morales o éticos del software, viendo la excelencia técnica como un producto secundario Richard se puso en contacto con los fabricantes, con la idea de modificar el software que controlaba la impresora y hacer que enviase una señal al atascarse, de forma que no se perdiese tanto tiempo de trabajo, sin embargo, estos se negaron a facilitarle el código fuente, que son como los planos de un programa y que hace posible modificar su comportamiento. Este episodio le contrarió mucho e hizo que terminase de consolidarse su idea de que el código fuente de los programas tenía que estar accesible para todo el mundo, movido por este deseo, abandonó el mit en enero de 1984, para iniciar el proyecto GNU.
GNU es un acrónimo recursivo qué significa GNU not Unix, GNU no es Unix, en referencia a que el proyecto busca desarrollar un sistema operativo de tipo Unix, pero libre, en sus comienzos, el proyecto GNU se concentró en desarrollar las herramientas necesarias para construir un sistema operativo, como editores y compiladores y en las utilidades básicas para la gestión del sistema. Sobre 1985, Richard Stallman creó la licencia GPL (general public license) como mecanismo para proteger el software libre, sustentado sobre el concepto de copyleft. Mediante este concepto, se le da la vuelta a la idea de copyright, definiendo las cuatro libertades mencionadas anteriormente, uno de los conceptos que se suelen mezclar con el software libre (reconozco que me sucede habitualmente) es el de open source (código abierto).
Podemos considerarlo como un error justificable, ya que en la práctica el software open source y el software libre comparten las mismas licencias. Aunque la FSF (free software foundation) opina que el movimiento open source es filosóficamente diferente del movimiento del software libre, apareció en 1998 con un grupo de personas, entre los que cabe destacar a Eric s. Raymond (autor de la catedral y el bazar y de fetchmail)y Bruce Perens (padre del proyecto Debian), que formaron la open source initiative (OSI). Buscaban darle mayor relevancia a los beneficios prácticos del compartir el código fuente, e interesar a las principales casas de software y otras empresas de la industria de la alta tecnología en el concepto. Estos defensores ven que el término open source evita la ambigüedad del término inglés free en free software, mucha gente reconoce el beneficio cualitativo del proceso de desarrollo de software cuando cualquiera puede usar, modificar y redistribuir el código fuente de un programa.
Esta es la idea subyacente de la obra de Raymond, la catedral y el bazar, que analizaremos más adelante. El movimiento del software libre hace especial énfasis en los aspectos morales o éticos del software, viendo la excelencia técnica como un producto secundario deseable de su estándar ético. El movimiento open source ve la excelencia técnica como el objetivo prioritario, siendo el compartir el código fuente un medio para dicho fin. Por dicho motivo, la FSF se distancia tanto del movimiento open source como del propio término.
ingeniería del software.
La ingeniería de software es la rama de la ingeniería que crea y mantiene las aplicaciones de software aplicando tecnologías y prácticas de las ciencias computacionales, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros campos, este término es relativamente nuevo, ya que no apareció hasta finales de los 60, cuando ya existían grandes compañías informáticas. En aquella época, una serie de estudios sobre desarrollo de software llegaron a la conclusión de que existía una crisis del software. Esta crisis tiene los siguientes síntomas:el software no es fiable y necesita de un mantenimiento permanente.
El software se entrega muy a menudo con retrasos y con unos costes superiores a los presupuestopuestados.
A menudo el software es imposible de mantener, carece de transparencia y no se puede modificar ni mejorar.
Como solución a esta crisis surge la idea de aplicar un proceso de ingeniería para el desarrollo de software. Según la definición del explorer, la ingeniería del software es un enfoque sistemático y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software: es decir, la aplicación de la ingeniera del software, la ingeniería, no sólo la del software, pretende aplicar con criterio el conocimiento matemático y científico obtenido a través del estudio, la experiencia, y la práctica. En la mayor parte de las ramas de la ingeniería es posible cuantificar con exactitud plazos, recursos humanos, costes y técnicas que lleven a cabo un determinado producto. Pero cuando ese producto se trata de software surgen los problemas, ya que aún no se han encontrado métodos de desarrollo y técnicas que permitan producir software de gran calidad con unos recursos limitados, a pesar de que la ingeniería del software ha conseguido notables éxitos, no es menos cierto que no ha sido capaz de superar la crisis del software. Hay quien piensa que más que de una crisis, estamos hablando de una enfermedad crónica. Es una reflexión plausible, más aun viendo como en los últimos años se han retomado viejos caminos bajo nuevas fórmulas de ingeniería. Quién sabe, quizás sean los nuevos modelos de desarrollos que permitan al software librarse de esta crisis, hasta hoy irresoluble.
ingeniería del software tradicional: software propietario.
Dentro del modelo propietario, la propia forma de desarrollar software ha sido quien ha llevado a la ingeniería del software a la crisis. No es una afirmación a la ligera ya que, como afirma Gregorio robles, el formato binario del software, la opacidad en los modelos de negocios, los secretos y barreras comerciales se encuentran entre las principales causas que han imposibilitado estudios cuantitativos y cualitativos a gran escala del software cuyos resultados pudieran ser verificados sistemáticamente por equipos de investigación independientes, es paradójico ver cómo el propio modelo de desarrollo destinado a evitar que un software robusto y potente pueda ser aprovechado por la competencia, impide la consecución del objetivo primordial: conseguir un software robusto y potente.
ingeniería del software libre.
No hay que entender al software libre como un competidor directo sobre el software propietario. Hay diferencias de base, como las razones motivacionales, casi filosóficas, de los desarrolladores. Tampoco se puede comparar a nivel económico, ya que el software libre sigue sus propias pautas de mercado y desde luego, no suele coincidir con el software propietario en la forma de obtener beneficios. Y lo que es más importante, la forma de producir software es totalmente diferente, la ingeniería del software no es ajena a todo esto y desde hace unos cinco años viene estudiando este nuevo modelo de desarrollo. En un principio podemos pensar que la propia naturaleza del desarrollo de software libre va a hacer fracasar cualquier intento de aplicación de ingeniería. Por ejemplo, si en el caso propietario la medición de costes es difícilmente cuantificable, en el caso del software libre tendremos que acudir a magos y hechiceros para que nos resuelvan la papeleta. Sin embargo, la transparencia en todos los procesos, la disponibilidad del código y en la mayor parte de los casos de todas las versiones de desarrollo, permiten que podamos analizar profundamente cualquier proyecto.
Enfermedad crónica. Es una reflexión plausible, más aun viendo como en los últimos años se han retomado viejos caminos bajo nuevas fórmulas de ingeniería. Quién sabe, quizás sean los nuevos modelos de desarrollos que permitan al software librarse de esta crisis, hasta hoy irresoluble, ingeniería del software tradicional: software.
Propietario.
Dentro del modelo propietario, la propia forma de desarrollar software ha sido quien ha llevado a la ingeniería del software a la crisis. No es una afirmación a la ligera ya que, como afirma Gregorio robles, el formato binario del software, la opacidad en los modelos de negocios, los secretos y barreras comerciales se encuentran entre las principales causas que han imposibilitado estudios cuantitativos y cualitativos a gran escala del software cuyos resultados pudieran ser verificados sistemáticamente por equipos de investigación independientes, es paradójico ver cómo el propio modelo de desarrollo destinado a evitar que un software robusto y potente pueda ser aprovechado por la competencia, impide la consecución del objetivo primordial: conseguir un software robusto y potente, ingeniería del software libre.
No hay que entender al software libre como un competidor directo sobre el software propietario. Hay diferencias de base, como las razones motivacionales, casi filosóficas, de los desarrolladores. Tampoco se puede comparar a nivel económico, ya que el software libre sigue sus propias pautas de mercado y desde luego, no suele coincidir con el software propietario en la forma de obtener beneficios. Y lo que es más importante, la forma de producir software es totalmente diferente, la ingeniería del software no es ajena a todo esto y desde hace unos cinco años viene estudiando este nuevo modelo de desarrollo. En un principio podemos pensar que la propia naturaleza del desarrollo de software libre va a hacer fracasar cualquier intento de aplicación de ingeniería. Por ejemplo, si en el caso propietario la medición de costes es difícilmente cuantificable, en el caso del software libre tendremos que acudir a magos y hechiceros para que nos resuelvan la papeleta. Sin embargo, la transparencia en todos los procesos, la disponibilidad del código y en la mayor parte de los casos de todas las versiones de desarrollo, permiten que podamos analizar profundamente cualquier proyecto.
Pero. ¿quienes son los miembros de las comunidades? Al hablar de comunidades de software libre nos suele venir a la cabeza un grupo de frikis discutiendo sobre Star Wars y las posibles consecuencias de enfrentar a Batman ya la masa. Es una injusticia que a las personas que amamos el software libre se nos encasille de esta manera, así que, es hora de desmitificar la leyenda. De todos modos, espero que quede claro que la masa patearía el culo a Batman, las comunidades de software libre son actualmente el objetivo de estudio de economistas, psicólogos y sociólogos. Se trata de una nueva forma de comunidad virtual, con reglas y jerarquías propias, y en muchos aspectos totalmente diferentes a las que conocemos en la sociedad tradicional. Saber quién forma parte de estas comunidades y cuáles son sus motivaciones es determinante para entender este movimiento.
En el caso de los desarrolladores las incógnitas son aún mayores, debido a que en una sociedad de consumo es difícil entender por que las personas dedican su tiempo libre a una actividad, aparentemente costos a y con beneficios directos prácticamente nulos, hay una gran cantidad de recientes estudios científicos que intentan definir el perfil del desarrollador de software libre. En el documento introducción al software libre de la UOC podemos leer:«los desarrolladores de software libre son generalmente personas jóvenes. La media de edad está situada en torno a los 27 años. La varianza de la edad es muy grande, ya que el grupo predominante se encuentra en una horquilla que va desde los 21 a los 24 años, siendo la mediana - El valor que aparece con mayor frecuencia - Los 23 años.
Es interesante observar cómo la edad de incorporación al movimiento de software libre tiene sus máximos entre los 18 y 25 años, siendo especialmente pronunciada entre los 21 y 23 años, lo que equivaldría a la edad universitaria. Esta evidencia contrasta con la afirmación de que el software libre es cosa principalmente de adolescentes, aunque su presencia es evidente (alrededor de un 20% de los desarrolladores tiene menos de 20 años). En definitiva, podemos ver cómo los desarrolladores suelen ser mayoritariamente veinteañeros (un 60%), mientras que los menores de 20 y los mayores de 30 se reparten apartes iguales el 40% restante.»
en el mismo texto se hace referencia a otros estudios, en los que se llega a la conclusión de que la mayor parte de los desarrolladores, el 60%, tienen pareja e incluso un 16% tiene hijos. Con esto se acaba de desmoronar el mito del desarrollador de software libre como una persona adolescente y aislada, sin más conocimientos ni relación con el mundo exterior que los que llegan a través de su ordenador. El hecho de que el perfil del desarrollador coincida con el del universitario medio no debería chocarnos, a fin de cuentas, el movimiento del software libre tiene sus orígenes en ambientes universitarios. Richard Stallman recuerda su trabajo en el artificial intelligence lab del mit en los años setenta, cuando el software compartido se consideraba parte fundamental del proceso:«a nuestro software no lo llamábamos software libre, porque ese término aún no existía, pero es exactamente lo que era. Cuando gente de otra universidad o una empresa querían un programa para hacerlo compatible y utilizarlo, se lo prestábamos con mucho gusto. Si veías a alguien usar un programa desconocido que te interesaba, siempre podías pedir que te dejaran ver el código fuente para así poder leerlo, cambiarlo o desmontarlo para crear un nuevo programa.»
sin embargo, otro de los grandes mitos se torna real en las encuestas. El software libre es desarrollado en su mayor parte por varones. La presencia de las mujeres en las comunidades varían entre el 1% y un 3%, compitiendo duramente por el protagonismo en las gráficas estadísticas con el error de muestreo, mientras que es relativamente sencillo saber la distribución de los desarrolladores según su edad, sexo y estatus social, averiguar las motivaciones por las cuales se emplea tiempo y, en ocasiones, dinero, resulta una tarea mucho más complicada. A veces los propios desarrolladores no tienen demasiado claras las motivaciones o, lo que es muy habitual, existe una conjunción de varios factores.
Desde luego las encuestas nos sirven para eliminar posibles causas de participación, la primera causa en ser descartada es la económica porque, aunque es totalmente factible obtener beneficios económicos con el software libre, estos beneficios nunca se podrán obtener de una forma directa por la venta de licencias, como en el caso del software propietario. Aun así, el 50% de los desarrolladores encuestados afirman haber obtenido recompensa económica como causa de su implicación en un proyecto de software libre. Sin embargo, hay muchos que no lo ven tan claro. El propio Richard Stallman, ante la pregunta de que debe hacer un desarrollador de software libre para ganar dinero, suele responder: puede trabajar de camarero. Personalmente opino que quitando la palabra libre a la pregunta, la respuesta no varía, al ser preguntados por su ocupación profesional, los desarrolladores se definen como ingenieros software (33%), estudiantes (21%), programadores (11%), consultores (10%), profesores de universidad (7%), etc. Es interesante observar cómo, a pesar de que en el software libre no se aplican técnicas clásicas de ingeniería del software, hay tres veces más de personas que se definen a sí mismos como ingenieros de software antes que programadores.
Una vez descartada la motivación económica se suele recurrir al ego de los desarrolladores. Si el lector estaba pensando en desarrollar software libre buscando la fama, puede ir olvidando la idea. En el documento: free/libre and open source software-ware: survey and study -part IV de Ghosh, Glatt, Krieger y robles (2002) se incluyó una pregunta, dirigida a los desarrolladores, para que indicaran a que colegas de una lista dada conocían, no necesariamente de manera personal. Los resultados fueron determinantes, la mayor parte de las personas conocían a pesos pesados del desarrollo, personas como Stallman, Icaza (Gnome)o Torvalds (Linux), eran conocidas por la práctica totalidad de los encuestados. Ni.
Que decir tiene que son personas que se dedican a algo más que al desarrollo y que tienen grandes connotaciones filosófico-históricas dentro del mundo del software libre. Lo curioso es que otros grandes desarrolladores que venían en la lista, como Jörg Schilling (Cdrecord), Marco Pressenti Gritti (Galeón), Guenther Bartsch (Xine)o Bryan Andrews (apache Toolbox) tenían el mismo grado de popularidad que Martín Hofstede o Ángelo Roulini, personas inexistentes y hábilmente añadidas por los encuestadores para averiguar el margen de error de las encuestas, así que, amigo lector, olvide el desarrollo del software libre como vehículo para obtener fama y fortuna.
A menos, claro está, que sea realmente bueno sirviendo copas y que su aspiración sea obtener la misma fama que las personas que no existen, aunque no sé han realizado estudios rigurosos, podemos afirmar que el proyecto Yafray encaja en los valores medios comentados anteriormente. Comparte una parte de su comunidad con Blender. Martine Albers de la Ámsterdam university realizó un estudio sociológico entre 746 personas de la comunidad de desarrolladores y usuarios de Blender, entre los que nos encontramos gran parte de los miembros del proyecto Yafray, se refrendaron algunos datos anteriormente comentados, como la baja participación femenina. No obstante, en el caso de Blender, la horquilla de edad es mayor (un 85% entre 15 y 35 años), sin duda debido a que existe una gran cantidad de usuarios adolescentes. Sin embargo, sólo un 21% de los encuestados reconocían haber desarrollado parte del software, un dato interesante es que el 91% de los encuestados se consideraban usuarios de Blender, lo cual supone que los desarrolladores son, además, usuarios del producto final, en cuanto a las motivaciones que llevan a las personas a formar parte de la comunidad de Blender, la respuesta obtenida fue la siguiente (ordenada de mayor a menor motivación):entretenimiento. Participar por diversión.
Altruismo. Querer ayudar a la gente sin obtener nada a cambio.
Ayuda a la comunidad. Participar porque estás comprometido con la comunidad.
Reciprocidad. Querer ayudar a la gente y esperar recibir algo a cambio.
Reputación. Participar para labrarse una reputación.
Mejoras en el software. Participar por querer o necesitar mejoras en el software.
Recompensa económica. Participar para ganar dinero.
Como se ve, las motivaciones que se pueden considerar más egoístas son las que están menos presentes. De hecho, en el propio estudio se resalta la inesperada posición del altruismo entre las motivaciones.
La catedral y el bazar.
En 1997 Eric s. Raymond escribió el primer documento que trataba de describir las características de los modelos de desarrollo de software libre, comparándolas con el modelo propietario. El artículo, como hemos mencionado antes, se titula la catedral y el bazar y se ha convertido en uno de los más conocidos y criticados del mundo del software libre, hasta el punto que para algunos supone el comienzo de la ingeniería del software libre, Raymond establece una analogía entre el modo de construir las catedrales medievales y la forma de clásica de producir software. En ambos casos existe una distribución de tareas diferenciada, en la que el diseñador está por encima de todo, controlando el desarrollo de la actividad. También la planificación está totalmente detallada desde el principio, marcando las funciones de cada uno de los participantes y las técnicas que han de utilizar para llevar a cabo su labor, dentro de esta idea de catedral no sólo esta incluido el desarrollo clásico de software propietario. Raymond encuentra que proyectos de software libre como GNU o NetBSD están fuertemente centralizados, ya que unas pocas personas son las que realizan el diseño e implementación del software. Si una persona quiere entrar a formar parte del equipo de desarrollo, los supervisores del proyecto le asignan un rol y una tarea. Además, este tipo de proyectos tiene unas entregas del software releases espaciadas en el tiempo siguiendo una planificación bastante estricta.
En contraposición al modelo de la catedral esta, según Raymond, el modelo del bazar. En un bazar no existe una autoridad que controle todos los procesos que se están desarrollando ni que realice una planificación de lo que ha de suceder. Los roles de los participantes son difusos, ya que los vendedores se pueden convertir en clientes, y viceversa, sin indicación externa, al contrario que en el modelo de la catedral, en el bazar hay entregas tempranas del software (reléase early). En el caso de Yafray, ¿cómo se ha dicho, se liberó desde prácticamente el primer momento. Esto suele motivar que aparezcan rápidamente personas que tenían el mismo problema (en el caso de Yafray, que querían desarrollar un raytracer)o que puedan estar interesadas en la solución (que necesitan lo que Yafray les puede ofrecer), las pruebas son, ¿cómo se ha comentado, una de las labores más pesadas en el desarrollo de software. Afortunadamente son un proceso altamente paralelizable. La reléase early de Yafray permitió que muchas personas se pusieran a probar el software simultáneamente, llevando así a cabo la fase de pruebas. Su uso aumentó drásticamente cuando Andrea carbone realizó la primera versión de Yable, un exportador de escenas desde Blender programado en Python. De este modo Andrea, usuario de Blender, se convirtió en desarrollador de parte del proyecto dentro del bazar Yafray, este tipo de relación en que todo el mundo puede aportar algo es altamente productiva. Los usuarios encuentran motivación en encontrar, notificar y corregir errores, ya que saben que su petición va a ser atendida casi inmediatamente. Además, existe cierta satisfacción personal por haber aportado algo, algo, así como un yo también he puesto mi granito de arena de cara al reconocimiento de la comunidad. De hecho, algunas comunidades se apoyan en una meritocracia, es decir, las decisiones más importantes las toman las personas que más aportan a la comunidad, el modelo del bazar, con frecuentes entregas del software, puede asustar a usuarios que buscan la estabilidad. Algunos proyectos, como Blender, mantienen ramas diferentes de desarrollo. Una más estable, en la que las nuevas funcionalidades sólo se añaden después de muchas pruebas, asegurándose que no repercuten en la estabilidad del producto final. Y otras experimentales como Tuhopou, The Evil Tree o la reciente rama orange, creada específicamente durante el desarrollo del corto Elephant dreams, pero el bazar no es solo aplicable a los desarrolladores. En ocasiones la vorágine del bazar intimida a nuevos usuarios, lo cuales pueden llegar a encontrar bruscos algunos comportamientos de los usuarios más antiguos. Este recelo de los veteranos de la comunidad suele ser debido a la repetición sistemática de los mismos errores por parte de los nuevos miembros.
Como ejemplo de esto, en la tristemente extinta comunidad de usuarios de Blender hispanos, nicodigital, los nuevos usuarios realizaban las mismas preguntas de novato una y otra vez. Los usuarios más veteranos se cansaban de repetir las mismas respuestas continuamente. Se llegó a hacer famosa la frase ¡usa el buscador, en relación al poco uso que daban los novatos al buscador del foro para encontrar posibles respuestas a sus preguntas. Con el doble fin de evitar preguntas innecesarias por parte de los nuevos y motivar a los veteranos a contestar, el administrador del foro (Nicolás morenas, alias Caronte) creó un sistema de créditos. Los créditos se obtenían, entre otras formas, por visitar la web y contestar preguntas, mientras que se perdían por realizarlas. A los pocos meses se creó toda una sociedad basada en el intercambio de créditos. Es una lástima no haber podido seguir la evolución de este experimento, ya que la imposibilidad de mantenerse económicamente, junto con una serie de desavenencias, precipitaron el cierre de la comunidad, a pesar de la buenas intenciones en el modelo del bazar, las decisiones tienen que estar controladas. Raymond supone que todo proyecto de software libre ha de contar con un dictador benevolente, una especie de líder que generalmente coincide con el fundador del proyecto, para guiarlo reservándose siempre la última palabra en la toma de decisiones. Sobre el papel, esa persona ha de saber motivar y coordinar un proyecto, entender a los usuarios y desarrolladores, buscar consensos e integrar a todo aquel que pueda aportar algo al proyecto. Pero la realidad es que esa persona, ¿cómo queda dicho, suele ser el propulsor original de la idea. Por tanto es un desarrollador al que le apasiona producir software, pero que, habitualmente, se preocupa poco por los usuarios y las relaciones dentro de la comunidad. Este tipo de desarrolladores suele ver cómo una perdida de tiempo las labores de ingeniería social organizativa.
Yafray: de la catedral al bazar organizado.
Yafray ha seguido desde un principio el modelo de procesos en el software libre. Surge como un proyecto personal y la persona que lanza el desarrollo es la que realiza las labores de dictador, considerado por todos benevolente porque si no, nos pegara, inicialmente, en la primera etapa de liberación del código (versión 0.0.1), la página web de Yafray era un simple documento html de fondo blanco con letras negras. Contenía una explicación del proyecto, un par de imágenes y un enlace al código. Si Yafray hubiese sido una empresa, esta presentación tan pobre habría desencadenado un suicidio colectivo del departamento de marketing. Desafortunadamente, Yafray no pudo hacer este favor a la humanidad ya que era un proyecto de un estudiante de informática. Aprovecho la ocasión para saludar a los chicos de marketing de mi empresa.
A pesar de esta puesta en escena tan austera, el proyecto tomó gran interés por parte de los usuarios de Blender, que, por aquel entonces no contaba con un motor de render de calidad. Este interés obligó a mejorar aquella web, incluyendo documentación extra y un foro para que los usuarios pudieran solventar sus dudas. Deberíamos reflexionar cómo una buena idea, en el momento adecuando, crece por si misma sin necesidad de envolverla en una nube de Bullshit dentro de extensas presentaciones de PowerPoint, ya hemos dado el primer paso de la catedral al bazar casi sin darnos cuenta. La necesidad de crear un foro de usuarios surge de la imposibilidad de Jandro para contestar a todos los correos de los usuarios, que emocionados con el nuevo raytracer no paraban de hacer preguntas. El arquitecto de la catedral pierde más tiempo en resolver dudas sobre el proyecto que en su desarrollo. La solución esta clara, permitir que la comunidad se comunique para que los usuarios más experimentados puedan ayudar a los nuevos, de manera casi simultanea al anuncio del proyecto, el hola Alfredo de Gref comenzó a aportar código, convirtiéndose en uno de los grandes impulsores del proyecto haciéndose responsable de la integración con Blender. Otros vinieron después, casi todas fueron pequeñas, pero importantes aportaciones. En poco más de un año Yafray contaba con una comunidad de usuarios grande, teniendo en cuenta el reducido ámbito del proyecto, en 2004, durante las jornadas boingboingblend, tuve la oportunidad de realizar una ponencia similar a esta. Entonces la situación de Yafray era bastante delicada. El proyecto estaba en crisis. Alejandro no tenía tiempo para dedicar al desarrollo, Alfredo estaba volcado en otros proyectos y no aparecían nuevos programadores. Por otra parte, la poca documentación que existía estaba desfasada y la web lleva años sin cambiar de aspecto. Mis conclusiones de entonces eran bastante pesimistas. El proyecto estaba en una situación de interbloqueo. Las pocas personas interesadas en colaborar, bien desarrollando código o documentando, no sabían cómo hacerlo porque la poca documentación existente era de mala calidad. Toda la información estaba en la cabeza de los desarrolladores, que precisamente carecían de tiempo para documentar. La pescadilla que se muerde la cola, el código no estaba libre de problemas. El diseño inicial, pensado para un pequeño raytracer ya no soportaba más parches para introducir las nuevas funcionalidades que los usuarios requerían. Eso llevó a Alejandro a pensar en empezar un nuevo diseño desde cero, mejor estructurado y con algoritmos de raytracer más avanzados. Para un programador interesado en colaborar era muy complicado ampliar el viejo código y el nuevo no era más que un esbozo.
Con este panorama, las pocas personas que intentaban ayudar, al poco tiempo escapaban del desastre organizativo que era el proyecto. Necesitábamos más compromiso y para ello optamos por un arma infalible: la vergüenza pública. Durante aquellas jornadas de Barcelona, en mitad de la ponencia pedimos a ciertas personas que colaborasen con el proyecto y que se comprometieran allí mismo, cara a cara con otros miembros de la comunidad. La jugada no salió mal: apenas recibimos amenazas de muerte y conseguimos que Javier galán diseñase una nueva imagen para Yafray y su web, mucho más profesional, en mi opinión aquello fue clave para el estado actual de Yafray. Dos años después, la documentación esta creciendo gracias al ingente trabajo de Álvaro luna. Mathias Wein ha tomado las riendas del proyecto, introduciendo grandes mejoras al código original, mientras el nuevo rediseño (llamado Fryrender) va madurando. Quiero agradecer desde aquí a estas personas y a tantas otras que con su trabajo, sus mensajes en los foros y sus trabajos artísticos de calidad profesional están consiguiendo que Yafray crezca cada día más.
desarrollo libre para el software libre.
Hemos hablado de la cooperación de las comunidades en el desarrollo de proyectos de software libre, pero ¿cómo se comunican sus miembros? ¿Qué herramientas se utilizan para coordinar los esfuerzos? Afortunadamente la comunidad de software libre se retroalimenta y existen multitud de herramientas libres útiles para el desarrollo de software y la cooperación entre personas de todo el mundo, los foros y las listas de correo son el epicentro de las comunidades. De hecho, son la parte visible de la comunidad. Ambas herramientas permiten la comunicación y las dos comparten la idea de facilitar el envío de mensajes a todos los miembros. Su diferencia fundamental el sentido en el que viaja la información. En las listas de correo la información llega pasivamente a los usuarios, los mensajes enviados a la lista llegan a toda la comunidad. Sin embargo, en los foros son los usuarios los que se acercan a la información. Por esto, las listas se deberían utilizar para intercambiar información útil para todos sus destinatarios. Un ejemplo clásico es una lista para los desarrolladores, donde cada miembro envía un registro de sus modificaciones, en los foros, sin embargo, el usuario es el que decide leer o no un mensaje. Se dividen en secciones y cada usuario le sólo la que le interesa. La información esta ahí, sólo hay que ir a buscarla. Son una herramienta útil tanto para usuarios como para desarrolladores. No sólo se utilizan para resolver dudas sobre el uso de un software, sino que sirven para poner en contacto a los desarrolladores y los usuarios, una de las herramientas que está invadiendo la escena del software libre es el wiki. Del hawaiano wiki wiki, rápido, es una forma de sitio web en donde se acepta que usuarios creen, editen, borren o modifiquen el contenido de una página web, de una forma interactiva, fácil y rápida. Dichas facilidades lo convierten una herramienta efectiva para la escritura colaborativa. En el proyecto Yafray, la instalación de un wiki (una wiki para algunos (algunas para algunos/as)) le ha permitido salir de la penosa situación documental que se encontraba durante el último año. Se está redondeando una documentación completa y actualizada. Además, la wiki ha permitido que los usuarios pudieran traducir por sí mismos la documentación a otros idiomas, como el español, portugués o chino, en cuanto al desarrollo en sí, hay que decir que Yafray empezó siendo desarrollado con herramientas libres, desde el compilador GNU hasta el VIM con el que Jandro tecleó las primeras líneas. Actualmente el único software propietario que se utiliza es el compilador visual c Toolkit (la versión gratuita del compilador de Microsoft para Windows). Aunque inicialmente se utilizó el Cygwin como herramienta de compilación para Windows, la idea se abandono ya que la integración con Blender, usando Yafray como plugin, requería el uso del compilador de los de Redmond, en el momento en el que más de una persona aportaba código al proyecto se hizo necesario el uso de una herramienta para el control de versiones, cvs en el caso de Yafray. El cvs (concurrent versións system), implementa un sistema de control de versiones: mantiene el registro de todo el trabajo y los cambios en la desarrollo de un proyecto (de programa) y permite que distintos programadores colaboren. La mayor parte de los proyectos de software libre utilizan esta herramienta o la más avanzada subversión, para terminar este pequeño repaso por las herramientas de desarrollo quiero hacer una mención a las utilidades de tipo BugTracker, literalmente rastreador de errores. Se trata de una especie de foro (en muchas ocasiones se utiliza como tal) en el que los usuarios dejan constancia de los fallos que van encontrando en el software, permitiendo en muchos casos añadir sugerencias sobre nuevas funcionalidades (feature requests). El BugTracker permite asignar programadores al problema, que serán los encargados de investigar las causas del error y subsanarlo. Es una herramienta muy potente y que recomiendo a todos aquellos proyectos que empiecen a tomar cierta relevancia.
conclusiones.
El ámbito de aplicación y desarrollo del software propietario suele (o debe) estar definido de antemano. Se puede realizar una predicción, más o menos acertada, sobre la envergadura del proyecto, así como del número y perfil de los usuarios finales, pero el software libre es totalmente impredecible. Un proyecto inicialmente pequeño, comenzado desde cero por una única persona puede volverse muy grande en muy poco tiempo, el desarrollador que empezó por diversión empieza a ver qué los usuarios demandan su ayuda y piden nuevas funcionalidades al software. Aparecen los primeros bugs que hay que resolver, lo que genera nuevas peticiones de los usuarios. Todo empieza a dejar de ser divertido. Usuarios curiosos inundan la cuenta de correo del programador. Aparecen nuevas personas intentando colaborar. En este caos organizativo el desarrollador debe asumir que su proyecto es de interés para la comunidad, utilizando parte de su tiempo en la organización de la comunidad que se ha formado alrededor de su software. Muchos lo verán como una perdida de tiempo, pero es necesario, ya que una buena planificación a tiempo favorecerá un desarrollo más fluido del proyecto, los desarrolladores han de tener en cuenta que afortunadamente no están solo, ya que existen una amplia gama de herramientas libres que permiten crear comunidades organizadas. Sabiendo el potencial de estas herramientas se podrá poner en las manos de los usuarios la oportunidad de colaborar. Conociendo las alternativas y eligiendo los instrumentos adecuados se puede formar una comunidad que se automantenga, haciendo que sean los usuarios los que contesten sus dudas y escriban la documentación, uno de los principales errores de Yafray fue descuidar estos aspectos y ha costado mucho levantar el vuelo. Si tú, amigo lector, estas empezando a desarrollar software libre ten en cuenta que deberás dedicar parte de tu tiempo al cuidado de las personas que se agrupan alrededor de tu proyecto. Si por el contrario lo tuyo no es programar y el menú del vídeo es todo un misterio para ti, no te preocupes. Hay mucha labor que hacer en el proyecto de tu software favorito. Cualquier aportación, como ayudar a los usuarios más inexpertos, puede hacer mejorar el software, no quiero terminar sin agradecer a Alejandro Conty la oportunidad de participar en un proyecto como Yafray. Mil gracias también a Alfredo de Gref, Javier galán, Mathias Wein, Álvaro luna y a toda la comunidad hispana e internacional de usuarios de Yafray, con especial cariño a los de Blender.
Llegados a este punto sólo queda contestar a una pregunta: ¿cuántos robles roería un roedor, si los roedores royesen robles? Bien, un roedor no roería robles, ya que los roedores no roen robles, pero si un roedor pudiera roer y royera alguna cantidad de robles, ¿cuántos robles roería un roedor? Aunque un roedor pudiera roer robles y, aunque un roedor royera robles, ¿debe un roedor roer robles? Un roedor debería roer si un roedor pudiera roer robles, siempre que el roedor royera robles.
Referencias[/SIZE]o Gregorio robles. ingeniería del software libre. Una visión alternativa a la ingeniería del software tradicional. 2002.
o Jesús González Barahona, Joaquín Seoane, Gregorio robles. introducción al software libre. 2003
o Eric s. Raymond. la catedral y el bazar. 1997
o Martine Albers, motivation for participating in an online open source software community. 2004
o
https://pulsar, unizar.es/gluz/manual-sl/c35.html
o
https://es.wikipediaorg
Tecnologías libres para sintesis de imagen digital tridimensional blendiberia 2006
quería comenzar esta charla sobre Creative Commons pidiendo disculpas.
Lo primero
+ Preguntar sobre
Citar
determinada, el valor de iluminación saliente lo es el resultado de sumar la iluminación emitida le y la luz reflejada. La luz reflejada (el segundo término de la suma de la ecuación anterior) viene dado por la suma de la luz entrante desde todas las direcciones, multiplicado por la reflexión de la superficie y el ángulo de incidencia.
la distancia entre p y la primera intersección con algún objeto en la dirección de?,?(d(p,?), es una función con valores entre 0 y 1 que nos indica la magnitud de iluminación ambiental que viene en la dirección de? Y? Es el ángulo formado entre la normal en p y la dirección de?
