The Cathedral and the Bazaar

El ensayo The Cathedral and the Bazaar es un documento escrito por Eric Raymond que expone y analiza métodos y procesos empleados durante la implementación del sistema operativo Linux; así como las experiencias obtenidas y lecciones aprendidas.

Este ensayo muestra un análisis para demostrar la diferencia entre los modelos de producción Cathedral y Bazaar, modelos que son utilizados durante el desarrollo del software libre. El modelo Cathedral, está enfocado en lo básico, pues es para un entorno cerrado y es para un grupo pequeño de desarrolladores, tal es el caso de GNU Emacs. Por otro lado, el modelo Bazaar es el modelo generado por Linus Torvalds, es un modelo abierto, puesto que casi cualquier persona puede ser partícipe de él y no tiene un límite respecto al número de desarrolladores que incluye, un ejemplo claro de este modelo es el sistema operativo Linux.

A lo largo del ensayo, Eric Raymond va mostrando 19 lecciones que aprendió durante el desarrollo de su software. Estas lecciones son:

1.    Every good work of software starts by scratching a developer's personal itch.

Esto quiere decir que un desarrollador puede pasar mucho de su tiempo en programas que realmente no necesitan; pero, en su caso, esa parte del proceso benefició la calidad que tienen el sistema Linux.

2.    Good programmers know what to write. Great ones know what to rewrite (and reuse).

Al momento de crear Linux, la creación no empezó desde cero, sino que Linus Torvalds tuvo como base a Minix y empezó a reescribir código para generar un sistema nuevo.

         3. Plan to throw one [version] away; you will, anyhow.

Siempre va a haber problemas al momento de la implementación, por lo que uno como desarrollador siempre debe estar preparado para volver a iniciar las cosas desde cero cuantas veces sea necesario.

4.    If you have the right attitude, interesting problems will find you.

Hay oportunidades que llegan a ti, pero que no son del todo perfectas ni como lo esperabas.

5.    When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

Si se piensa abandonar algún proyecto, se debe buscar a alguien que se encargue de continuar su desarrollo en un futuro. No se debe dejar el proyecto incompleto y al aire. Aunque en el mundo de sistemas, seguramente alguien lo encontrará y le dará continuación.

6.    Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

Ya que varios usuarios pueden resultar ser hackers, el proceso de debugging, así como el de arreglos y mejoras puede ser más eficiente con ayuda de tus compañeros.

7.    Release early. Releasy often. And listen to your customers.

El estar activo de manera continua, motiva a los desarrolladores a realizar su trabajo de manera correcta, pues así se pueden apreciar mejor sus logros y su trabajo.

8.    Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Cuando alguien encuentra alguna falla o problema, esa persona se lo pasa a otra persona para que lo intente comprender y lo pueda solucionar.

9.    Smart data structures and dumb code works a lot better than the other way around.

Al momento de leer código escrito por alguien más, el hecho de que sea simple y sencillo puede ayudar a la otra persona, la lectora, a comprenderlo mejor y más rápido.

10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

Incluir a todo el personal, escuchar sus inquietudes e ideas hará que trabajen de la misma manera en que tú los has apoyado.

11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

Escuchar a los usuarios siempre es bueno, pues puedes encontrarte con ideas y puntos de vista muy interesantes e importantes.

12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

Hay veces en que uno se encuentra con un problema, pero no encuentra su solución debido a que el problema está mal identificado y realmente el problema es otro.

13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.

Entre más sencillo y simple sean las cosas, ahí es cuando se puede decir que las cosas están bien, están en su punto.

14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

Hay herramientas que tienen cierta función y la cumplen a la perfección, pero también pueden satisfacer otras necesidades diferentes (multi-drop fetchmail).

15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!

Si estás trabajando para alguien, acepta sugerencias y no te resistas al cambio. Puede no gustarte pero esos cambios son importantes y más cuando son altamente demandados.

16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

Hay cambios que pueden verse como necesarios, pero realmente no lo son.

17. A security system is only as secure as its secret. Beware of pseudo-secrets.

El hecho de que un cambio sea altamente demandado no significa que sea la opción correcta. Siempre hay que analizar que se pide y si realmente valen la pena esos cambios.

18. To solve an interesting problem, start by finding a problem that is interesting to you.

Hay muchas maneras de ver los problemas y errores, pero si los ves como un reto, como algo divertido, la solución puede llegar a ser interesante y no preocupante.

19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Siempre es bueno compartir tus ideas al mundo y darlas a conocer, pues la parte colaborativa siempre será buena.

Las lecciones que da Eric Raymond, si uno las analiza detenidamente, no sirven únicamente para el desarrollo de software, sino que también sirven para proyectos personales que involucren a varias personas. Cabe mencionar que, mediante estos consejos, se puede ver el desarrollo de software, sea libre o no, trae muchos aspectos a considerar, desde identificación y solución de problemas hasta la interacción con los usuarios y el equipo de trabajo, elementos que muchas veces no tomamos en cuenta.

·        Raymond, E. S. (1998). The cathedral and the bazaar. Retrieved from http://webcem01.cem.itesm.mx:8005/s201611/tc2025/the_cathedral_and_the_bazar.pdf