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.
