El Catedral y El Bazar - Procesos de Desarrollo del Software Libre

La Catedral y El Bazar

Este escrito fue presentado por Raymond en mayo de 1997, en un congreso sobre GNU/Linux en Bavaria. En el mismo se encarga de analizar el modelo de desarrollo creado y utilizado por Linus Torvalds para su proyecto Linux. El hacker dice que este modelo cambió su forma de pensar. Mucha gente dentro del mundo del software cree que hay un cierto nivel de complejidad a partir del cual es recomendable un desarrollo centralizado. Linus Torvalds demostró que estaban equivocados al desarrollar una pieza de software tan crítica como es el núcleo de un sistema operativo, de una manera abierta y completamente descentralizada.

Raymond sugiere que el mundo del Software Libre es como un bazar con muchos comerciantes diferentes que ofrecen sus mercancías. El desarrollo empresarial, por el contrario, esta estructurado como los sindicatos religiosos que construyeron las catedrales medievales. Los bazares ofrecen mucha competencia, pero sin orden alguno. Las catedrales estaban sometidas a la dirección de jerarquías sacerdotales, que aprovechaban la riqueza de la ciudad para construir el proyecto de un solo arquitecto.

Las diferencias entre ambos son evidentes. El equipo de la catedral puede producir una obra de arte si el arquitecto tiene talento, los encargados de la financiación tienen éxito y la dirección consigue que todo el mundo se concentre en su trabajo. El bazar, por otra parte, consiste en muchos mercaderes pequeños que tratan de competir unos con otros. Los mejores se quedan con los mejores clientes, y los otros pronto acaban sin trabajo.

El modelo ” Catedral”

Las principales ventajas del modelo Catedral son:

• Desarrollo ordenado. Todos saben qué tareas deben realizar y cuándo, dentro de un rango determinado de tiempo.
• Control del proyecto. Es posible evaluar porcentajes de avance y/o de retraso fácilmente, reflejando el trabajo realizado en un diagrama de Gantt o de Pert.
• Sencillez de manejo. En realidad, nunca es sencillo dirigir un proyecto; simplemente es más fácil cuando uno puede remitirse a los tiempos prefijados y no a las necesidades surgidas en el último momento.

Características:

1. El software de gran tamaño se construye como las catedrales, es decir, cuidadosamente planificado por equipos de expertos que se comunican lo justo entre sí.
2. Hay poco personal y bien escogido. Aumentar mucho el número de personas es caro y pasado cierto punto no acelera el desarrollo, sino que lo ralentiza.
3. No se publican versiones beta hasta poco antes de terminar.
4. El motivo de que las versiones se publiquen tarde en este modelo es que de lo contrario estarían plagadas de errores.
5. Los errores son difíciles de encontrar, requieren una fase de pruebas que se hace al final.
6. El código fuente se guarda a cal y canto.
7. Subyace a él una estructura organizativa piramidal.
8. El jefe de proyecto debe tener gran talento para el diseño.

El modelo "Bazar"

Algunas ventajas son:

• Tiempos de desarrollo mucho menores. Algunos proyectos –Linux, como el ejemplo más evidente- han avanzado tres o cuatro veces más rápido que si se hubieran desarrollado bajo otro esquema.
• Reporte de errores ("bugs") y/o su corrección en períodos mucho menores. Los beta-testers son a veces también desarrolladores, con la capacidad de corregir errores en el sistema.
• Retroalimentación. Es muy claro en estos proyectos cuáles son las características más deseadas y utilizadas, dado el número de personas involucradas en ellas.
• Gastos. Son prácticamente nulos, comparados con otros esquemas.
• Motivación. Quizás la ventaja más importante; el desarrollador siente que está siendo útil, sin sentirse aprisionado por las responsabilidades. Esto conduce, por supuesto, a menores tiempos de desarrollo, soluciones más brillantes, etc.

Algunas desventajas son:

• Si el proyecto no genera interés, puede no llevarse a cabo. Suele ocurrir que, igual que las películas malas, el sistema se quite de cartelera prematuramente.
• Patrocinio. En ocasiones, la falta de patrocinadores puede alentar el desarrollo. También, es común que tengan que comprarse licencias y/o especificaciones técnicas para la adaptación a ciertos ambientes.
• Credibilidad. El concepto de "software abierto" está cambiando en la mente de las mayorías; sin embargo, aún es posible atacar al movimiento con argumentos tales como "no se puede confiar en un montón de adolescentes con barros que decidieron hacer un programa".

Principios del bazar en el software libre
1. Todo trabajo de software comienza a partir de las necesidades personales del programador. No es lo mismo trabajar para un proyecto a cambio de un salario que trabajar gratis en algo en lo que se encuentra una satisfacción personal o se cubre una necesidad. Lo segundo motiva más.
2. Los buenos programadores saben que escribir. Los mejores que reescribir (y reutilizar). Es más fácil partir de una solución aunque sea incompleta y mala que de cero. Linus lo que hizo no fue construir un sistema operativo desde la primera línea de código hasta el final (probablemente aún estaría en ello), en lugar de eso, tomó como punto de partida Minix. Por tanto, una forma de iniciar un proyecto puede ser buscar un proyecto similar ya hecho y tomarlo como guía.
3. Contemple desecharlo, de todas formas tendrá que hacerlo. Al final todo el código de Minix fue reemplazado, pero mientras existió fue un armazón a partir del cual pudo ir cambiando partes. El código de partida no es importante, de hecho seguro que tiene un montón de errores y no es adecuado a nuestras necesidades, solo sirve para comprender el problema.
4. Si tienes la actitud adecuada, encontrarás problemas interesantes.
5. Cuando se pierde el interés en un programa, el último deber es dejarlo en herencia a un sucesor competente.
6. Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.
7. Publique rápido y a menudo, y escuche a sus clientes.
8. Dada una base suficiente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado rápidamente, y su solución ser obvia al menos para alguien.
9. Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en el caso inverso.
10. Si usted trata a sus analistas (beta-testers) como si fueran su recurso más valioso, ellos le responderán convirtiéndose en su recurso más valioso.
11. Lo más grande después de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor.
12. Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.
13. La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar.
14. Toda herramienta es útil empleándose de la forma prevista, pero una ``gran'' herramienta es la que se presta a ser utilizada de la manera menos esperada.
15. Cuando se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaución de alterar el flujo de datos lo menos posible, y nunca eliminar información a menos que los receptores obliguen a hacerlo.
16. Cuando su lenguaje esté lejos de uno Turing-completo, entonces las ``ayudas'' sintácticas pueden ser su mejor amigo.
17. Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.
18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.

PROCESOS EN EL DESARROLLO DE SOFTWARE LIBRE

En el proceso de desarrollo de un software propietario se realiza mediante análisis, diseño, pruebas, implementación e implantación y lo que diferencia sobre software libre es el uso de la palabra kernel que tienen dos significado como grupo o núcleo se utiliza núcleo por haber derivado del núcleo minix y grupo porque están integrados por una comunidad.

• Crear sitio web
Para elaborar un sitio web se deben seguir varios principios que se mencionan a contnuacion:
 En la web se plasmaran los avances, tareas pendientes, tareas asignadas, personas responsables y los cronogramas de actividades fijando para el desarrollo total del proyecto.
 Debe mostrar la constitución de los diferentes grupos de trabajo colaborativo, con su líder correspondiente quien será el responsable de la publicación de los diferentes hallazgos y productos que resultan del desarrollo de las actividades.
 El acceso para la comunidad libre los participantes será controlado para las actualizaciones, inserciones, modificaciones y otras actividades en el proceso de creación del producto.

• Nombramiento de los diferentes grupos o kerneles de trabajo
Kernel se define como un núcleo o un grupo de personas que estan encargados de realizar tareas o actvividades especificas y que estos grupos están dirigidos por un líder, el cual es nombrado por estos.
A continuación se mencionan los procesos en el desarrollo de software libre:
1. Análisis
2. Diseño
3. Planeación
4. Implementación
5. Implantación

Kernel de Análisis: Nombrado kernel o núcleo porque está compuesto por una o varias personas que conforman la comunidad. Su líder es el que los guiara acerca de las actividades de análisis que realizaran y será el encargado de publicar los productos generados en este grupo en el sitio web de la aplicación.

Funciones que se llevaran a cabo en el kernel de análisis son las siguientes:

• Recolectar información relevante para el proyecto, haciendo uso de las diferentes técnicas de levantamiento de información (entrevistas, encuestas, documentación histórica)
• Generar el documento de requerimiento del sistema.
• Crear los modelos o diagramas preliminares del análisis (diagrama de flujos de datos, diagrama de funciones, diagrama de actividades).
• Recolectar los aportes colocados en el sitio web de la aplicación, en cuanto a análisis del problema, con el fin de procesarlos y determinar cuales se tendrán en cuenta para su implementación.

Kernel de diseño: Debe estar compuesto por un número limitado de personas (dependiendo del volumen del proyecto); este grupo realizara las tareas de modelado físico lógico de la aplicación y tendrá la responsabilidad de obtener los mejores modelos, para asi ponerlos a consideración de la comunidad libre, para captar sus aportes y recomendaciones.

Funciones que se llevaran a cabo en este grupo son:

• Recolectar los aportes colocados en el sitio web de la aplicación en cuanto al diseño con el fin de procesarlos y determinar cuales se tendrán en cuenta para su aplicación.
• Generar los modelos físicos y lógicos
• Implementar el diseño inicial de la interfaz grafica de usuario.

Kernel de implementación: Este proceso de kernel esta divida por subkerneles, que están organizados según su distribución, con el objeto de tener mayor cooperación interna dentro de cada unos de ellos y así poder enviar sus aportaciones al grupo planeador.

Funciones que se llevaran a cabo son las siguientes:
• Crear los subgrupos de codificación, asignando políticas claras de desarrollo.
• Desarrollar y llevar a cabo el plan de pruebas alfa.
• Generar la codificación de los productos.

Kernel de implantación: Está compuesto por un grupo concreto de personas identificadas totalmente, por lo cual será encargado de poner a consideración del producto y capacitar al usuario final.

Funciones que se llevaran a cabo son los siguientes:
• Generar y llevar a cabo el plan de pruebas beta del producto.
• Capacitar a la comunidad que utilizara la aplicación.
• Documentar los procesos que se llevaron a cabo en esta etapa.

Todos estos grupos o kerneles serán coordinados por un grupo denominado:

kernel de planeación: Es el responsable de dar visto bueno para el arranque y finalización de las actividades de la comunidad de cooperación libre y de certificar la liberación al mundo del producto final.

Funciones que se llevaran a cabo en este grupo:
• Mantener el sitio web.
• Coodinar las tareas de inicio y finalización de las actividades.
• Elaborar el cronograma de actividades para el ciclo de desarrollo del producto.
• Llevar el control de versiones del producto.
• Crear políticas para actualizar el producto.
• Liberar el producto para su uso.