8.5 Métodos de software libre: ``cathedral'' vs. ``bazaar''

Internet ha supuesto una revolución, no sólo en el mundo de la informática, sino en todos los campos del conocimiento. Nunca antes la información había estado disponible como lo está ahora para todos. Internet es algo así como el sistema nervioso del mundo. Una de las consecuencias es que hay formas nuevas de trabajar, por ejemplo, ahora una persona puede colaborar con otras que no conoce en un proyecto. La información compartida se puede dejar en un almacén común y se definen políticas poco o nada restrictivas acerca de quien puede leer esa información o a quien se acepta como colaborador.

El inicio del movimiento del desarrollo de Software Libre a través de Internet ha supuesto también la aparición de nuevos métodos y la adaptación de otros a esta nueva forma de desarrollo. Las metodologías tradicionales presuponen una organización del reparto de tareas gestionado mediante responsables que distribuyen y supervisan el trabajo. Cuando se trata de trabajo cooperativo voluntario a través de la Red ese esquema ya no es válido y se plantean nuevas formas de coordinación distribuida del trabajo. Los términos ``catedral'' y ``bazar'' hacen referencia a una metáfora de ambos enfoques que propuso Eric S. Raymond en su famoso libro titulado precisamente así, ``The Cathedral & the Bazaar'' [Ray99]. Donde comparaba las metodologías tradicionales de desarrollo con la construcción y desarrollo de una catedral, en contraposición de la forma de crecimiento y expansión aparentemente caótica de un bazar.

Los métodos de desarrollo de software libre, realizados por programadores muy variados y con distintas formas de codificar, funcionan en la práctica porque todo el producto está disponible desde el primer momento públicamente para su revisión y comprobación. Se logran resultados extensos a base de pequeñas contribuciones individuales pero muy numerosas. Para poder aportar alguna contribución es necesario haber visto y comprendido el trabajo que ya está realizado y por tanto se produce una sinergia con los programadores predecesores que resulta en un desarrollo armonioso. Evidentemente en estos proyectos es necesario algún tipo de coordinación mínima que es llevada a cabo por el desarrollador más reconocido que habitualmente es el que más ha contribuido. Nos extenderemos más en el método ``bazar'' por ser la parte novedosa.

8.5.1 La catedral

Es el método tradicional y seguido por la mayor parte de los fabricantes de software hoy en día. 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.

8.5.2 El bazar

Es diferente al anterior en todos los puntos anteriores:

1. En un principio hay una idea, pero no se tiene una imagen clara de en que se convertirá al final.
2. Existe una ingente cantidad de personas en su elaboración y cuantos más mejor.
3. En el momento en el que se puede publicar una versión se hace, aunque esté muy incompleta.
4. Los errores se encuentran con facilidad porque hay muchas personas trabajando simultáneamente en ello. Su descubrimiento se pone en marcha desde el principio.
5. El código es abierto, o lo que es lo mismo, cualquiera puede leerlo y modificarlo.
6. La estructura organizativa es difusa, hay una serie de normas para participar pero no una jerarquía claramente definida. Una persona puede contribuir durante toda la vida del proyecto o de un modo fugaz.
7. El coordinador del proyecto más que tener talento tiene que tener olfato para ver cuando una idea de otro es buena e incorporarla.

El kernel de Linux es el paradigma número uno que sigue la filosofía del bazar. Es un software de gran tamaño y complejidad, iniciado en principio como un pequeño proyecto por Linus Torvalds tomando como base el sistema operativo Minix (un antiguo UNIX para clónicos de IBM-PC). El proyecto sigue en la actualidad mas vivo que nunca y cada día va ganando cuota de mercado a sus competidores (a algunos los ha dejado atrás ya, p. ej: SCO-Unix. Según Eric S. Raymond en su libro [Ray99]: ``La Catedral y el Bazar'', las conclusiones que se sacan del método bazar son:

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.