La catedral y el bazar resume
Páginas: 15 (3636 palabras)
Publicado: 2 de noviembre de 2011
LA CATEDRAL Y EL BAZAR
Linux es subversivo. ¿Quién habría pensado hace trece años (1991) que un sistema operativo de clase-mundial podría unirse como por arte de magia a partir del trabajo aficionado y parcial de miles de programadores dispersos por todo el planeta, conectados solamente por los filamentos tenues del Internet?
Linux volcó mucho de lo que se pensaba. Se había predicado duranteaños el evangelio Unix de herramientas pequeñas, de prototipos rápidos y de la programación evolutiva. Pero también se creía que existía una cierta complejidad crítica por encima de la cual era preciso recurrir a un enfoque más centralizado y planificado desde el principio. Se creía que el software más importante (los sistemas operativos o las herramientas realmente grandes tales como Emacs)necesitaban ser construidas al modo de las catedrales, ser cuidadosamente ensamblados por magos o pequeñas bandas de hechiceros trabajando en un espléndido aislamiento, sin que hubiera lugar al lanzamiento de versiones de prueba antes de que hubiera llegado el momento.
El estilo de desarrollo de Linus Torvalds - lanzar versiones de prueba enseguida y a menudo, delegar cuanto sea posible, estar abiertohasta el punto de resultar promiscuo - resultó una verdadera sorpresa. Nada que ver con la silenciosa y reverente construcción de una catedral - la comunidad Linux, por contra, parecía semejarse a un gran bazar bullicioso con diferentes agendas y enfoques (adecuadamente reflejado por los depósitos de software Linux, que admitían contribuciones de cualquiera) del cual solo parecía posible queemergiera un sistema coherente y estable mediante una sucesión de milagros.
El hecho de que este estilo bazar parecía funcionar, y bien, produjo una auténtica conmoción y era difícil comprender porqué el mundo Linux no solo no se desmoronaba en medio de una colosal confusión sino que parecía ir de logro en logro a una velocidad difícil de imaginar para los constructores de catedrales.
El correodebe pasar
Supongamos que alguien llamado `joe' en "locke" me envía un mensaje. Si lo recojo y lo envío a "snark" e intento contestar, mi programa de correo intentará enviarlo alegremente a un inexistente 'joe' en "snark". Editar a mano las direcciones de las respuestas para restaurar el original '@ccil.org' se convirtió pronto en una considerable molestia.
Era claramente algo que el ordenadordebía hacer en mi lugar. (De hecho, según RFC1123 sección 5.2.18, sendmail debería estar haciéndolo.) ¡Pero ninguno de los clientes POP sabía como!. Y esto nos lleva a la primera lección:
1. Todos los trabajos buenos en software comienzan tratando de paliar un problema personal del que los programas.
Quizá esto hubiera debido resultar evidente (se sabe desde hace tiempo que "La necesidad esla madre de la invención") pero los programadores desperdician demasiado a menudo sus días peleando por dinero con programas que no necesitan y a los que no aman. No así en el mundo Linux - lo que puede explicar porqué la calidad media del software desarrollado por dicha comunidad es tan alta.
2. Los buenos programadores saben qué escribir. Los grandes saben qué reescribir (y reutilizar).Aunque no pretendo ser un gran programador, trato de imitarlos. Una característica importante de los grandes de verdad es la vagancia constructiva. Saben que te dan un diez no por tu esfuerzo, sino por los resultados, y es casi siempre más fácil empezar a partir de una buena solución parcial que desde la nada más absoluta.
Linus, sin ir más lejos, no intentó en realidad escribir Linux partiendode cero.
En vez de eso, comenzó reutilizando código e ideas de Minix, un minúsculo símil de Unix para máquinas 386. Al final, todo el código Minix fue desechado o se reescribió por completo - pero mientras estuvo allí, proporcionó el andamiaje necesario para la criatura que eventualmente llegaría a ser Linux.
3. “Piensa en desechar al menos uno; lo terminarás haciendo de todos modos. ‘‘...
Linux es subversivo. ¿Quién habría pensado hace trece años (1991) que un sistema operativo de clase-mundial podría unirse como por arte de magia a partir del trabajo aficionado y parcial de miles de programadores dispersos por todo el planeta, conectados solamente por los filamentos tenues del Internet?
Linux volcó mucho de lo que se pensaba. Se había predicado duranteaños el evangelio Unix de herramientas pequeñas, de prototipos rápidos y de la programación evolutiva. Pero también se creía que existía una cierta complejidad crítica por encima de la cual era preciso recurrir a un enfoque más centralizado y planificado desde el principio. Se creía que el software más importante (los sistemas operativos o las herramientas realmente grandes tales como Emacs)necesitaban ser construidas al modo de las catedrales, ser cuidadosamente ensamblados por magos o pequeñas bandas de hechiceros trabajando en un espléndido aislamiento, sin que hubiera lugar al lanzamiento de versiones de prueba antes de que hubiera llegado el momento.
El estilo de desarrollo de Linus Torvalds - lanzar versiones de prueba enseguida y a menudo, delegar cuanto sea posible, estar abiertohasta el punto de resultar promiscuo - resultó una verdadera sorpresa. Nada que ver con la silenciosa y reverente construcción de una catedral - la comunidad Linux, por contra, parecía semejarse a un gran bazar bullicioso con diferentes agendas y enfoques (adecuadamente reflejado por los depósitos de software Linux, que admitían contribuciones de cualquiera) del cual solo parecía posible queemergiera un sistema coherente y estable mediante una sucesión de milagros.
El hecho de que este estilo bazar parecía funcionar, y bien, produjo una auténtica conmoción y era difícil comprender porqué el mundo Linux no solo no se desmoronaba en medio de una colosal confusión sino que parecía ir de logro en logro a una velocidad difícil de imaginar para los constructores de catedrales.
El correodebe pasar
Supongamos que alguien llamado `joe' en "locke" me envía un mensaje. Si lo recojo y lo envío a "snark" e intento contestar, mi programa de correo intentará enviarlo alegremente a un inexistente 'joe' en "snark". Editar a mano las direcciones de las respuestas para restaurar el original '@ccil.org' se convirtió pronto en una considerable molestia.
Era claramente algo que el ordenadordebía hacer en mi lugar. (De hecho, según RFC1123 sección 5.2.18, sendmail debería estar haciéndolo.) ¡Pero ninguno de los clientes POP sabía como!. Y esto nos lleva a la primera lección:
1. Todos los trabajos buenos en software comienzan tratando de paliar un problema personal del que los programas.
Quizá esto hubiera debido resultar evidente (se sabe desde hace tiempo que "La necesidad esla madre de la invención") pero los programadores desperdician demasiado a menudo sus días peleando por dinero con programas que no necesitan y a los que no aman. No así en el mundo Linux - lo que puede explicar porqué la calidad media del software desarrollado por dicha comunidad es tan alta.
2. Los buenos programadores saben qué escribir. Los grandes saben qué reescribir (y reutilizar).Aunque no pretendo ser un gran programador, trato de imitarlos. Una característica importante de los grandes de verdad es la vagancia constructiva. Saben que te dan un diez no por tu esfuerzo, sino por los resultados, y es casi siempre más fácil empezar a partir de una buena solución parcial que desde la nada más absoluta.
Linus, sin ir más lejos, no intentó en realidad escribir Linux partiendode cero.
En vez de eso, comenzó reutilizando código e ideas de Minix, un minúsculo símil de Unix para máquinas 386. Al final, todo el código Minix fue desechado o se reescribió por completo - pero mientras estuvo allí, proporcionó el andamiaje necesario para la criatura que eventualmente llegaría a ser Linux.
3. “Piensa en desechar al menos uno; lo terminarás haciendo de todos modos. ‘‘...
Leer documento completo
Regístrate para leer el documento completo.