"The cathedral and the bazaar" (PDF, 145KB) de Eric S. Raymond.

Este ensayo -cuya primera versin 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 travs 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 aos 90, que luego puso en marcha l mismo con el desarrollo de su conocido servidor de correo Fetchmail. En los ltimos aos 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 poltica de ocultar el cdigo incluso internamente, mientras que los "bazares", donde hay mucho ruido y confusin 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 algn 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 artculo, pienso que muchas de sus premisas no son aplicables en proyectos comerciales y menos en empresas pequeas. Adems 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 tcnicas de trabajo y han abierto mucho sus productos y el cdigo para ser ms 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 ---> Motivacin II. Los buenos programadores saben qu cdigo escribir. Los grandes programadores saben qu cdigo rescribir ---> Reutilizacin de cdigo y no reinventar la rueda III. Planea tirar al menos una vez el trabajo. Lo hars de todos modos ---> Las cosas no salen bien a la primera generalmente IV. Si tienes la actitud correcta, los problemas interesantes te encontrarn ---> La curiosidad es buena y te llevar a crear proyectos interesantes V. Cuando pierdes el inters en un programa, tu ltima obligacin para con l es cedrselo a un sucesor competente ---> No tires el trabajo, dselo a alguien que le interese y lo pueda seguir llevando VI. Tratar a tus usuarios como co-desarrolladores es el camino con menos obstculos hacia la mejora del cdigo y la depuracin efectiva ---> Involucra a otra gente en el desarrollo VII. Libera pronto, libera a menudo y escucha a tus clientes ---> mejor liberar cdigo que no sea perfecto muy a menudo que cdigo 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 rpido y la solucin ser obvia para alguien ---> Esta la clsica teora de que muchos ojos pueden ver cualquier error, lo cual ya he comentado en otras ocasiones

IX. X.

XI. XII. XIII. XIV. XV.

XVI.

XVII.

XVIII.

XIX.

que no me convence nada. Para muestra un botn, pero hay muchos ejemplos en el mundo Linux y OS engeneral. Est claro que cuatro ojos ven mejor que dos y as sucesivamente pero basar la calidad y seguridad del Open Source en que hay muchos ojos mirando es una falacia. Me gusta un corolario que sale de aqu, y que dice: "The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly this cost is strongly affected by the number of users. More users find more bugs". Est claro: cunto ms lo use la gente ms errores van a aparecer. Es mejor tener estructuras de datos bien pensadas y mal cdigo que al revs ---> Piensa bien antes de desarrollar. sers ms efectivo. Si tratas a tus beta-testers como si fueran tu recurso ms valioso, respondern convirtindose en tu recurso ms valioso ---> Esto lo lleva haciendo Microsoft muchos aos aunque sin cigo fuente la mayor parte de las veces. Lo segundo mejor despus de tener buenas ideas es reconocer las buenas ideas de tus usuarios. A veces esto ltimo es incluso mejor ---> No comments. A menudo las soluciones ms impactantes e innovadoras vienen al darte cuenta de que tu concepto del problema estaba equivocado ---> Rectificar es de sabios. La perfeccin (en diseo) se consigue no cuando no hay nada ms que aadir, sino ms bien cuando ya no hay nada ms que quitar ---> Totalmente de acuerdo. Es el principio KISS. Una herramienta debe ser til en el modo esperado, pero una herramienta realmente buena suele dar usos que nunca habas esperado. Cuando escribas software de pasarela del tipo que sea, esfurzate por entorpecer el flujo de datos lo menos posible, y nunca deseches ninguna informacin a menos que el destinatario te fuerce a ello ---> De esto poco tengo que decir, est relacionado con su programa de e-mail, y como dice un amiguete: "Cuando tienes un martillo todo te parecen clavos" ;-) Cuando tu lenguaje no es ni de lejos Turing-completo, el azucar sintctico puede ser tu amigo ---> vamos que justifica la exitencia de construcciones en los lenguajes que faciliten el trabajo. Un sistema de seguridad es slo tan seguro como sus secretos. Ten cuidado con los pseudosecretos ---> con esto estoy totalmente de acuerdo: no bases la seguridad de tus sistemas en la ofuscacin o el que no se conozca tus algoritmos. Esto es ley en programacin. Para resolver un problema interesante, comienza por buscar un problema que te interese ---> nuevamente la cuestin de la motivacin y que los grandes programadores suelen trabajar en cosas que les interesan y motivan. Muy bonito y est bien participar en ello en un proyecto Open Source, pero en la cruda realidad hay que comer y el trabajo no siempre es tan interesante o motivador. De esta parte me gusta un prrafo en el que compara la catedral y el bazar con las leyes fsicas Newtonianas y de la relatividad especial respectivamente, y dice: "This resembles the relationship between Newtonian and Einsteinian physics-the older system is still valid at low energies, but if you push mass and velocity high enough you get surprises like nuclear explosions or Linux." Partiendo de la base de que el coordinador del desarrollo (Open Source) tiene a su disposicin un medio de comunicacin al menos tan bueno como Internet y que sabe como dirigir sin coercin, muchas cabezas son inevitablemente mejores que una sola ---> Amn.