Este fin de semana largo que tenemos en España he aprovechado para releer el clásico de la literatura del Open Source, "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
-
Todo buen trabajo de software comienza por rascar el "picor" de un buen programador ---> Motivación
-
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
-
Planea tirar al menos una vez el trabajo. Lo harás de todos modos ---> Las cosas no salen bien a la primera generalmente
-
Si tienes la actitud correcta, los problemas interesantes te encontrarán ---> La curiosidad es buena y te llevará a crear proyectos interesantes
-
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
-
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
-
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)
-
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 no me convence nada.
Para muestra un botón, 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: cuánto más lo use la gente más errores van a aparecer.
-
Es mejor tener estructuras de datos bien pensadas y mal código que al revés ---> Piensa bien antes de desarrollar. serás más efectivo.
-
Si tratas a tus beta-testers como si fueran tu recurso más valioso, responderán convirtiéndose en tu recurso más valioso ---> Esto lo lleva haciendo Microsoft muchos años aunque sin cóigo fuente la mayor parte de las veces.
-
Lo segundo mejor después 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 más impactantes e innovadoras vienen al darte cuenta de que tu concepto del problema estaba equivocado ---> Rectificar es de sabios.
-
La perfección (en diseño) se consigue no cuando no hay nada más que añadir, sino más bien cuando ya no hay nada más 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 habías esperado.
-
Cuando escribas software de pasarela del tipo que sea, esfuérzate por entorpecer el flujo de datos lo menos posible, y nunca deseches ninguna información 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 sintáctico puede ser tu amigo ---> vamos que justifica la exitencia de construcciones en los lenguajes que faciliten el trabajo.
-
Un sistema de seguridad es sólo tan seguro como sus secretos. Ten cuidado con los pseudo-secretos ---> con esto estoy totalmente de acuerdo: no bases la seguridad de tus sistemas en la ofuscación o el que no se conozca tus algoritmos. Esto es ley en programación.
-
Para resolver un problema interesante, comienza por buscar un problema que te interese ---> nuevamente la cuestión de la motivación 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 párrafo en el que compara la catedral y el bazar con las leyes físicas 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 disposición un medio de comunicación al menos tan bueno como Internet y que sabe como dirigir sin coerción, muchas cabezas son inevitablemente mejores que una sola ---> Amén.
-----
El ensayo es todo un clásico y, a pesar de lo que pueda parecer por mi resumen, es bastante interesante y cualquier programador debería leerlo, sobre todo si debe coordinar equipos de desarrolladores. Eric tiene otros ensayos interesantes sobre Open Source que quizá comente en otra ocasión.
En fin, cada uno que saque sus conclusiones...