La Catedral Y El Bazar

"The cathedral and the bazaar" (PDF, 145KB) de Eric S. Raymond. Este ensayo -cuya primera versión data de 1997- se convirtió enseguida en una pieza de referencia para el movimiento Open Source ya que en él Eric analizaba las diferencias existentes entre el desarrollo tradicional de software en las grandes empresas, a las que comparaba con una catedral, con el desarrollo de aplicaciones Open Source a través de Internet con voluntarios, que comparaba con un bazar. Lo que lo inspiró a escribirlo fue la tremenda efectividad del desarrollo de Linux a principios de los años 90, que luego puso en marcha él mismo con el desarrollo de su conocido servidor de correo Fetchmail. En los últimos años Eric ha tenido sonadas disputas con el Free sSoftware Foundation y en especial con el grillado de Richard Stallman.

Por si alguien lo dudaba las "catedrales" son empresas como Microsoft (especialmente) y otros gigantes, que tienen una política de ocultar el código incluso internamente, mientras que los "bazares", donde hay mucho ruido y confusión pero se hacen muchos tratos todo el tiempo, son los grandes proyectos Open Source como los mencionados.

He decidido resumir aquí los puntos principales del documento (y traducirlos) tal cual él los expone, con algún comentario propio, por si le pueden servir a alguien y para tenerlos yo mismo resumidos para futura referencia. Espero que te gusten y te resulten útiles.

Ahora bien, aunque coincido con muchas de las cosas que dice Eric en su artículo, pienso que muchas de sus premisas no son aplicables en proyectos comerciales y menos en empresas pequeñas. Además estoy convencido de que Microsoft y otras grandes empresas han aprendido mucho del Open Source y, aparte de tener muchos proyectos OS propios, han modificado sus técnicas de trabajo y han abierto mucho sus productos y el código para ser más ágiles. ¿El mercado les ha obligado? Seguro, pero eso no quita que sea así.

LA CATEDRAL Y EL BAZAR - PUNTOS IMPORTANTES

I. Todo buen trabajo de software comienza por rascar el "picor" de un buen programador ---> Motivación

II. Los buenos programadores saben qué código escribir. Los grandes programadores saben qué código rescribir ---> Reutilización de código y no reinventar la rueda

III. Planea tirar al menos una vez el trabajo. Lo harás de todos modos ---> Las cosas no salen bien a la primera generalmente

IV. Si tienes la actitud correcta, los problemas interesantes te encontrarán ---> La curiosidad es buena y te llevará a crear proyectos interesantes

V. Cuando pierdes el interés en un programa, tu última obligación para con él es cedérselo a un sucesor competente ---> No tires el trabajo, dáselo a alguien que le interese y lo pueda seguir llevando

VI. Tratar a tus usuarios como co-desarrolladores es el camino con menos obstáculos hacia la mejora del código y la depuración efectiva ---> Involucra a otra gente en el desarrollo

VII. Libera pronto, libera a menudo y escucha a tus clientes ---> mejor liberar código que no sea perfecto muy a menudo que código muy probado de muy tarde en tarde (en un mundo donde los que lo reciben son programadores, claro)

VIII. Dada una base suficientemente grande de beta-testers y co-desarrolladores, casi cualquier problema será determinado rápido y la solución será obvia para alguien ---> Esta la clásica teoría de que muchos ojos pueden ver cualquier error, lo cual ya he comentado en otras ocasiones que

...