Evaluación de las comunidades del mundo open source / software libre

De Wiki REDDES

Espacio en construcción 



Liberar el código

Liberar el código implica que el programa sea usable, principalmente por el usuario final, ya que este será el que reporte incidencias, proponga mejoras y limitaciones de uso.

No se pretende que el programa sea un desarrollo monolítico y que su construcción pretenda buscar el “código perfecto”, sino comprender que el desarrollo "a muchos ojos" permite encontrar errores, nuevas maneras de plantear las cosas, nuevos usos y reusos del código. Esto también quiere decir que se debe buscar la extensibiliad de la aplicación, la modularidad y que el programa sea entendible, ya sea por la misma manera de programar, como de comentar muy bien el código y mantener una buena documentación de lo que se hace. Esto depende de las buenas prácticas que tenga la empresa.



Comunidad

La comunidad será la población que usará el programa y que de una u otra forma aportará al proyecto. Hay que diferenciar la comunidad en dos grandes grupos: el primero es el de usuarios no-desarrolladores; que pueden aportar al desarrollo del proyecto desde el punto de vista de usabilidad, limitaciones, aspectos que se deben mejorar, diseño e interfaz, etc. El otro gran grupo sería el de los usuarios desarrolladores, que aportarán lo mismo que el usuario no-desarrollador, pero con posibles soluciones a nivel de programación, es decir, con arreglos y propuestas al código. Este grupo también se puede diferenciar por la calidad de su código y de su aporte.

Tal vez un tercer grupo puede ser el de entusiastas que no solo prueban el código, sino que crean páginas web, propagandizan el software, hacen traducciones, traducen y participan en la documentación del código, testean los programas y aportan a la difusión y vida de la comunidad y, que sin ser programadores, ayudan enormemente a la comunidad. Según defiende Alan Cox (1998), tras separar a los participantes valiosos del ruido, hay también que tributar respecto a los no programadores, "esa gente a menudo olvidada que mantiene páginas web o cambia logs, las listas de correo y la documentación son igualmente importantes". Nosotros a la par proponemos, como estrategia de trabajo, la búsqueda activa de la comunidad de desarrollo, testeo y evaluación. No basta con que pongamos el código en un repositorio y esperemos a que este sea bajado por alguien y que otro más comente algo o aporte, también es necesario ubicar qué producto es usable por una comunidad que no sea la nuestra, y hasta qué nivel, y qué tan rentable sale modularizar o hacer extensible una aplicación para que sea usable por esta comunidad, para que sea ella la que nos ayude en su desarrollo. Puede ser que un producto no sea usable nada más que por nosotros y que tampoco sea rentable en términos tiempo/esfuerzo el que se haga extensible, esa aplicación tal vez no sea la más idónea para este modelo de desarrollo y debemos dejarla como consumo interno (sin descartar publicar este código). Las aplicaciones que entendamos pueden ser usables por esta comunidad serán aquellas que tengan un grado de extensibilidad alto y que su desarrollo pueda ser abarcado por la comunidad (la experiencia nos ayudará en esto). La búsqueda activa de la comunidad de desarrollo debería de ser estimulada constantemente con elementos morales (prestigio, reconocimiento, etc. y también con cuestiones materiales: cuentas de correo, navegación gratis, computadoras, software, etc.) y ambas con cursos de superación que a la larga redundan en mayor calidad al aporte que hagan. La parte de la comunidad que trabaja con un motor material puede ser más controlada que la otra y esta más comprometida con la obtención de resultados, necesitarán más control y una definición muy precisa de lo que se quiere con ella, porque el estímulo es distinto y la motivación otra. Se impone la figura del líder de proyecto, cómo dinamizar central en todo esto y que en primera instancia debería ser el desarrollador que crea la aplicación y que será el responsable de mantenerla a lo largo del tiempo de vida útil del programa. Cabría destacar el hecho de que los equipos de desarrollo están usualmente deslocalizados y compuestos por una población flotante de desarrolladores con un alto índice de rotación. En estas condiciones se impone la adopción de un proceso que permita fijar, atacar y evaluar objetivos en espacios breves de tiempo. Esta tarea le correspondería al líder de proyecto o al responsable de proyectos de la institución.

Esta dinámica depende de un sutil juego de capacitaciones, prestigio y autoridad regido por un sistema de roles, en que la figura del coordinador se torna imprescindible, el cual, entre otras funciones asignadas, actúa como dinamizador, filtro y supervisor del equipo cambiante y discontinuo de desarrolladores.

Herramientas personales