Catedral Y Bazar/Procesos en el Software Libre

La catedral y el bazar

Eric Raymond, es una especie de filósofo del mundo del Software Libre. Aunque no solo es famoso por sus escritos, ya que varios paquetes de software de su autoría forman parte de las distribuciones de GNU/Linux.

Entre sus aportes se puede destacar:
• Emacs VC (Version Control) Un Front End para CVS, o sea control de versiones.
• Fetchmail: una solución para la obtención de correo para máquinas UNIX, especialmente para aquellos con conexión intermitente al servidor de correo (PPP, SLIP). Recupera los mensajes usando alguna variante de POP o de IMAP.
• Participó del desarrollo de las bibliotecas ncurses .

Se precia de ser uno de los primeros voluntarios en sumarse al proyecto GNU de Stallman ( a mediados de la década del 80). Y aunque luego fue uno de los creadores del movimiento Open Source, asegura que continúan siendo amigos con Stallman.

A los efectos de estudiar el movimiento del software libre, es esencial tener en cuenta los escritos publicados por Raymond. Consiguió resumir de forma magistral el fenómeno y crear un mito en su artículo "La catedral y el bazar". Trató de destacar las diferencias entre varios campos del mundo de código fuente abierto. Se dio cuenta de que los que lideraban proyectos de código libre tenían distintas formas de compartir y quería explicar cuál de todas es la que mejor funciona.

La Catedral y el Bazar

Este famoso 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 Linux30. 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.

Para explicar este fenómeno emplea una metáfora bien descriptiva. 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.

Aunque parezca que la comparación apunta a separar el desarrollo comercial/cerrado del mundo Open Source, Raymond señala que la FSF es como la catedral del Software Libre. Obviamente con esto no quiere decir que la FSF sea lo mismo que Microsoft, pero sí que su modelo de desarrollo es por lo general centralizado.
A lo largo del escrito, Raymond redacta su experiencia personal durante el desarrollo de fetchmail. Expresa de manera clara y explicativa, cómo fue que se decidió a aplicar un modelo similar al utilizado en el proyecto Linux para llevar adelante su propio desafío. A medida que avanza en detalles va definiendo algunos axiomas que son interesantes de discutir.

Lo que nos deja el escrito de La Catedral y el Bazar:

1. Todo buen trabajo de software comienza a partir de las necesidades personales del programador. (Todo buen trabajo empieza cuando uno tiene que rascarse su propia comezón)
2. Los buenos programadores saben qué escribir. Los mejores, qué reescribir (y reutilizar).
3. "Considere desecharlo; de todos modos tendrá que hacerlo." (Fred Brooks, The Mythical Man-Month, Capítulo 11)
4. Si tienes la actitud adecuada, encontrarás problemas interesantes.
5. Cuando se pierde el interés en un programa, el último deber es heredarlo 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. Libere 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. O, dicho de manera menos formal, "con muchas miradas, todos los errores saltarán a la vista". A esto lo he bautizado como la Ley de Linus.
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 mejor 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 nada 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. Cuándo 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 un Turing completo, entonces el azúcar sintáctico puede ser su 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.
19. Si el coordinador de desarrollo tiene un medio al menos tan bueno como lo es Internet, y sabe dirigir sin coerción, muchas cabezas serán, inevitablemente, mejor que una.

El interés en desarrollo de software de fuente abierta ha crecido enormemente en el último año. Con su claro y eficaz estilo de escritura Raymond describe con exactitud los beneficios del software de código abierto ha sido clave para su éxito.

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.

Básicamente nos apoyamos acerca de las definiciones de kernel para los procesos en el desarrollo de software libre que a continuación describiremos.Kernel se define como núcleo o grupos su visión de kernel está dada en que es u grupo el que lo conforma para la colaboración para el trabajo o actividades. Se analizan los ciclos de vida para el proceso de desarrollo de software.
 Analisis
 Diseño
 Implementacion
 Implantacion
 Planeacion

• Crear sitio web
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. Mediante un líder quien será el responsable de la publicación, el acceso para la comunidad libre los participantes será controlado y sus aportes serán recibidos en un espacio designado.

• Nombramiento y funciones de los diferentes grupos o kerneles de trabajo

Los kerneles que se integraran tendrán funciones específicas y serán dirigidos por un líder.

Kernel de Análisis: nombrado kernel o núcleo porque está compuesto por una o varias personas que conforman la comunidad. Pero lo cual tiene un líder que guiara a las actividades de análisis y será quien publique los productos generados en este grupo en el sitio web de la aplicación. Sus funciones de 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 o en orientación a objetos casos de uso).
• 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 miembros (dependiendo del volumen del proyecto); y la responsabilidad de obtener los mejores modelos, poniendo a consideración de la comunidad libre, para captar sus aportes y recomendaciones. Sus funciones de kernel de diseño son:
• Generar los modelos físicos y lógicos
• Implementar el diseño inicial de la interfaz grafica de usuario.
• 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.

Kernel de implementación: en este proceso de kernel esta divida por subkerneles, por lo cual 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 de kernel de implementación son las siguientes:
• Crear los subgrupos de codificación, asignando de codificación por módulos, por formularios u otros métodos de división del trabajo de programación de la aplicación.
• Desarrollar y llevar a cabo el plan de pruebas alfa.

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. Sus funciones de desarrollos 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, 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.