La Catedral y el Bazar


Cuando hablamos de este ensayo, estamos también hablando de Eric S. Raymond. En 1997 se le consideró una figura líder del movimiento Open Source. Fue cofundador de la OSI (Open Source Initiative). Contribuyó a la liberación del navegador web Netscape. Como programador coordino el cliente de correo Fetchmail, colaboró en Emacs, y Ncurses.

Y gracias a la colaboaración de este software, lo que le llevo a escribir un ensayo sobre dos modelos opuestos de desarrollo, la catedral es el modelo que utilizaban la mayoría de fabricantes de software, y el bazaar, más parecido al Software Libre.

Durante el ensayo, analiza 19 lecciones sobre su experiencia en estos dos modelos de desarrollo.

  1. Todo buen proyecto de software comienza con la necesidad personal del programador.
    Comienzan como su proyecto mascota, que cuidan y miman, pues es su obra. Al contrario que ocurre con el software privativo, en el que el programador realiza una tarea impuesta guste o no. Esta motivación explica grandes proyectos como el núcleo Linux.

  2. Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).Absolutamente importante en el Software Libre, Linus Torvalds no empezó desde cero, cogió partes de Minix. Aunque finalmente reescribió el código, fue fundamental para comenzar con el proyecto.

  3. "Contemple desecharlo; de todos modos tendrá que hacerlo." (Fred Brooks, The Mythical Man-Month, Capítulo 11). No se entiende el problema hasta que lo implementas por primera vez, por eso es recomendable, empezar de nuevo alguna vez.

  4. Si tienes la actitud adecuada, encontrarás problemas interesantes.
    Eric se encontró con un cliente de correo popclient interesante escrito por Carl Harris, pero lo tenía abandonado. Eric debía tomar la decisión de cogerlo y empezar a coordinarlo por su cuenta.

  5. Cuando se pierde el interés en un programa, el último deber es heredarlo a un sucesor competente.
    Antes de abandonar un proyecto de Software Libre, hay que encontrar un sucesor, que lo trate como si fuera de la mascota que tratábamos en el primer punto. Como bien dice el eslogan "No los abandones, ellos no lo harían", siempre hay alguien dispuesto a asumir ese cargo.

  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.
    Y qué mejor ejemplo que el núcleo Linux. Cualquier persona tiene acceso al código y/o cambiarlo, encuentra fallos, y los puede arreglar, y en caso de no saber arreglar, lo puede comunicar al resto.
  7. Libere rápido y a menudo, y escuche a sus clientes.
    Totalmente necesario, y es fomentado gracias al sistema de canales de software. Se pueden mantener tres lineas de proceso, una estable, en la que se mantiene para implementar con gran cantidad de fallos testeados. Las nightly versiones previas a una estable para que los testeadores empiecen a probar posibles errores y corregirlos para la versión estable. Y un canal diario, en el que cambio que sea realice, cambio que está disponible al mundo. De esta manera estimulamos tanto a desarrolladores, usuarios entusiastas, y usuario s finales.
  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.
    O definir la Ley Linus "con muchas miradas, todos los errores saltarán a la vista". En este punto se diferencia la catedral, con meses de revisión exhaustivos para alcanzar el máximo número de errores. Por eso se tarda tanto en aparecer nuevas versiones.
    Por otro lado, el bazar, asume que los errores son evidentes cuando se muestra a desarrolladores entusiastas. Por consecuencia se libera más a menudo por incluir los cambios de estos.
  9. Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en el caso inverso.
    Un problema universal es la dificultad de entender el código que otra persona a escrito. Realizar diagramas o definir las estructuras de datos utilizadas, permiten comprender mejor el funcionamiento del programa.

  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.Tal y como cuenta Eric, en su experiencia con Fetchmail, creo una lista beta para todos los que le preguntaron por la implementación. Anunciaba nuevas releases para estimular a que la gente lo probara. Escuchaba las opiniones de estos usuarios primerizos. Como consecuencia, dar importancia a estos recurso hará que tu software sea más práctico al final.
  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. Obtener las opiniones de los usuarios es lo mas enriquecedor que debes tener en cuenta.
  12. Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.Esto me recuerda mucho al punto 3, en algún momento, gracias a haber atendido a las sugerencias de los usuarios, podemos encontrarnos que el camino o las soluciones que se proponen son erróneas. Parar, dar marcha atrás para coger otro camino, es duro, pero merece la pena.

  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."Cuando el código va mejorando y se va simplificando, es cuando se hace lo correcto. Respecto a la interfaz de usuario, creo que pasa lo mismo. Para mi un claro ejemplo es Gnome, pasó de un entorno de escritorio para hackers, ya que cada componente tenia gran cantidad de configuración, a pasar a ser un escritorio multidisciplinar, se fue aligerando la interfaz de usuario, quitando opciones innecesarias.

  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.Aquí juega un papel importante la innovación, dar al usuario esa manera de usar un programa que incluso mejora las expectativas.

  15. Cuándo 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!Puede parecer un comentario único para el proyecto en el que trabajaba Eric, pero creo que tiene importancia en la manera que si tienes un programa, que debe leer una entrada estandarizada, y después sacarla por pantalla o tratarla para una salida, debe mantener el mismo estándar.
  16. Cuando su lenguaje está lejos de un Turing completo, entonces el azúcar sintáctico puede ser su amigo.
  17. Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.

    Estas dos lecciones son propias del proyecto Fetchmail, habla sobre el sistema de seguridad  de la aplicación, cómo guardar y encriptar las contraseñas.
  18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.Es la única forma de no abandonar un proyecto, como le ocurrió a Carl Harris. Hay muchos motivos para motivar a un desarrollador, en el Software Libre, mayormente no es económico, es mas bien una satisfacción de su ego y su reputación entre desarrolladores.
  19. Si el coordinador de desarrollo tiene un medio al menos tan bueno como lo es Internet, y sabe dirigir sin coerción, muchas cabezas serán, inevitablemente, mejor que una.
    Cuando Eric escribió esto, aún estaban empezando a dar sus frutos el Software Libre como movimiento. Creo que hoy en día está claro el éxito de un producto libre.
Tras estas 19 lecciones, tengo que recordar que es un ensayo, carece de rigor. Trata de generalizar todos los proyectos de Software Libre, aplicándole un modelo de bazar. Esto puede ser confuso, pues proyectos cómo el núcleo Linux pueden aparentar más un modelo de catedral, con un dictador benevolente a la cabeza que es Linus Torvalds. Quizá el  bazar no es la definición mas correcta para definir un proyecto de Software Libre. Puede que el modelo de catedral y bazar de Eric se viera influenciado por los acontecimientos que se vivían por aquel entonces.

En cualquier caso, el mejor modelo que define el Software Libre es aquél que garantice las cuatro libertades.

0 comentarios:

Publicar un comentario