La Catedral y el Bazar

"La Catedral y el Bazar", es un ensayo desarrollado por Eric S. Raymond, expuesto por el autor en el Linux Kongress 97, el Atlanta Linux Showcase, la primera Perl Conference, y en LinuxPro 97.

En este trabajo, Raymond analizó un proyecto de software de dominio público desarrollado con éxito, fetchmail, que se realizó como una prueba deliberada de algunas teorías sorprendentes sobre ingeniería de software sugeridas por la historia de Linux.

Raymond presenta estas teorías en términos de dos estilos de desarrollo completamente distintos, el modelo "Catedral'', aplicable a la mayor parte de los desarrollos realizados en el mundo del software comercial, donde se crea el software bajo un esquema bien definido y un grupo de programadores bien coordinado; frente al modelo "bazar'', más propio del mundo Linux, donde existe una aportación variada de software con propósitos dispares y liberada en cuando fuera posible.

De este modo, muestra que estos modelos se derivan de puntos de partida opuestos sobre la naturaleza del proceso de depuración del software.

Argumenta que en ambos casos existe una clara distribución de tareas y roles, destacando la existencia de un diseñador que está por encima de todo y que ha de controlar en todo momento el desarrollo de la actividad. Asimismo, la planificación está estrictamente controlada, dando lugar a unos procesos claramente detallados en los que idealmente cada participante en la actividad tiene un rol específico muy delimitado.

Dentro de lo que Raymond toma como el modelo de creación de catedrales no sólo tienen cabida los procesos pesados que podemos encontrar en la industria del software (el modelo en cascada clásico, las diferentes vertientes del Rational Unified Process, etc.), sino que también entran en él proyectos de software libre, como es el caso de GNU y NetBSD.

Para Raymond, estos proyectos se encuentran fuertemente centralizados, ya que unas pocas personas son las que realizan el diseño e implementación del software. Las tareas que desempeñan estas personas, así como sus roles están perfectamente definidos y alguien que quisiera ser parte del equipo necesitaría que se le asignara una tarea y un rol según las necesidades del proyecto. Por otra parte, las entregas de este tipo de programas se encuentran espaciadas en el tiempo siguiendo una planificación bastante estricta. Esto supone tener pocas entregas del software y ciclos entre las entregas largos y que constan de varias etapas.

El modelo antagónico al de la catedral es el bazar. Según Raymond, algunos de los programas de software libre, en especial el núcleo Linux, se han desarrollado siguiendo un esquema similar al de un bazar oriental. En un bazar no existe una máxima autoridad que controle los procesos que se están desarrollando ni que planifique estrictamente lo que ha de suceder. Por otro lado, los roles de los participantes pueden cambiar de manera continua (los vendedores pueden pasar a ser clientes) y sin indicación externa.

Un proyecto de software libre suele surgir a raíz de una acción puramente personal; la causa se ha de buscar en un desarrollador que vea limitada su capacidad de resolver un problema. El desarrollador ha de tener los conocimientos necesarios para, por lo menos, empezar a resolverlo. Una vez que haya conseguido tener algo usable, con algo de funcionalidad, sencillo y, a ser posible, bien diseñado o escrito, lo mejor que puede hacer es compartir esa solución con la comunidad del software libre. Es lo que se denomina “publicación prontía” (release early en inglés) y que permite llamar la atención de otras personas (generalmente desarrolladores) que tengan el mismo problema y que puedan estar interesados en la solución.

Uno de los principios básicos de este modelo de desarrollo es considerar a los usuarios como codesarrolladores. Ha de tratárseles con detalle por el hecho de que realizarán una de las tareas más costosas que existe en la generación de software: las pruebas. Al contrario que el codesarrollo, que es difícilmente escalable, la depuración y las pruebas tienen la propiedad de ser altamente paralelizables.

El usuario será el que tome el software y lo pruebe en su máquina bajo unas condiciones específicas (una arquitectura, unas herramientas, etc.), una tarea que multiplicada por un gran número de arquitecturas y entornos supondría un gran esfuerzo para el equipo de desarrollo.

Si se trata a los usuarios como desarrolladores puede darse el caso de que alguno de ellos encuentre un error y lo solucione, enviando un parche al desarrollador del proyecto para que el problema esté solucionado en la siguiente versión. También puede suceder, por ejemplo, que una persona diferente al que descubra un error sea la que finalmente lo entienda y corrija. En cualquier caso, todas estas circunstancias son muy provechosas para el desarrollo del software, por lo que es muy beneficioso entrar en una dinámica de esta índole.

Esta situación se torna más efectiva con entregas frecuentes, ya que la motivación para encontrar, notificar y corregir errores es alta debido a que se supone que va ser atendido inmediatamente. Además, se consiguen ventajas secundarias, como el hecho de que al integrar frecuentemente -idealmente una o más veces al día- no haga falta una última fase de integración de los módulos que componen el programa. Esto se ha denominado publicación frecuente (en la terminología anglosajona se conoce como release often) y posibilita una gran modularidad narduzzo:modularity:03 a la vez que maximiza el efecto propagandístico que tiene publicar una nueva versión del software.

Para evitar que la publicación frecuente asuste a usuarios que prioricen la estabilidad sobre la rapidez con la que el software evoluciona, algunos proyectos de software libre cuentan con varias ramas de desarrollo en paralelo. El caso más conocido es el del núcleo Linux, que tiene una rama estable -dirigida a aquellas personas que estiman su fiabilidad- y otra inestable -pensada para desarrolladores- con las últimas innovaciones y novedades

Lecciones enumeradas en La Catedral y el Bazar de Eric S. Raymond

1. Todos los trabajos buenos en software comienzan tratando de paliar un problema personal del que los programa.

2. Los buenos programadores saben qué escribir. Los mejores, qué reescribir (y reutilizar).

3. Piensa en desechar al menos uno: lo terminarás haciendo de todos modos.

4. Si tienes la actitud adecuada, los problemas interesantes te encontrarán.

5. Cuando un programa deja de interesarte, tu último deber es pasarlo a un sucesor competente.

6. Tratar a tus usuarios como colaboradores es el camino menos complicado para mejorar con rapidez y depurar eficazmente un programa.

7. Lánzalo pronto. Lánzalo a menudo. Y escucha a tus usuarios.

8. Dada una base lo suficientemente amplia de probadores y colaboradores, casi todos los problemas se identificarán con rapidez y su solución será obvia para alguien.

9. Estructuras de datos inteligentes asociadas a un código torpe funcionan mucho mejor que la alternativa opuesta.

10. Si tratas a la gente que te ayuda a depurar un programa como si fueran tu recurso más valioso, responderán convirtiéndose en eso precisamente.

11. La siguiente cosa mejor que tener buenas ideas consiste en reconocer las buenas ideas de tus usuarios. Y en ocasiones ésta última es la mejor en términos absolutos.

12. A menudo, las soluciones más sorprendentes e innovadoras surgen al darte cuenta de que la idea que se tenía del problema estaba equivocada.

13. La perfección (de un diseño) no se consigue cuando no queda nada por añadir, sino más bien cuando no resta nada por eliminar.

14. Toda herramienta debe resultar útil en la forma prevista, pero una gran herramienta te lleva a usarla para realizar cosas jamás pensadas.

15. Cuando escribas programas que actúen como pasarelas de datos (gateway software), ten cuidado de modificarlos lo menos posible; y nunca elimines información a menos que su destinatario te fuerce a hacerlo.

16. Si el lenguaje de tu programa no es Turing-completo ni por asomo, puede venir bien endulzar su sintaxis.
17. Un sistema es sólo tan seguro como su secreto. Cuidado con los falsos secretos.

18. Para resolver un problema interesante, comienza por encontrar uno que lo sea para tí.

19. Si el coordinador de un proyecto tiene a su disposición un medio de comunicación al menos tan potente como Internet, y sabe cómo conducir a la gente sin coaccionarla, muchas cabezas son inevitablemente mejor que una.