Caminando por Babel April 24, 2008
Posted by jguridi in : Eric S. Raymond, etica hacker , trackbackHoy voy a repetir personaje a tratar y no, no es Himanen. Voy a hablaros de Eric S. Raymond de nuevo, esta vez de su publicación “La Catedral y el Bazar” y para mi sorpresa (sobre todo después de lo comentado por Iñaki en la anterior entrada sobre Raymond), esta vez el tono es más correcto y ya no parece tan prepotente. Al lió.
Sigo tratando el tema de la ética hacker, y Raymond sigue poniendo el ejemplo del software libre para expresarla. Esta vez, nos viene a decir las ventajas que tiene el modelo Bazar frente al modelo Catedral en la creación de software, sobre todo en la de gran envergadura, como sistemas operativos o herramientas grandes. El modelo Catedral viene a representar a un grupo cerrado de unos pocos eruditos trabajando en un proyecto de la que no se publican versiones experimentales hasta tener más o menos un resultado. En contraposición, el modelo Bazar representa a un grupo “colmado de individuos con propósitos y enfoques dispares” que hacen público todo el proceso para ir enriqueciéndolo desde el principio.
Linus Torvalds dijo “libere rápido y a menudo, delegue todo lo que pueda, sea abierto hasta la promiscuidad” y esto sorprendió a Raymond, más aun cuando vio que el modelo Bazar parecía funcionar bien. Se animó a lanzar un proyecto de software libre para poder comprobar de manera consciente este modelo de creación, que empezó con un problema con el correo electrónico y terminó en un programa llamado Fetchmail. Este proyecto aparece estructurado en lecciones que Raymond nos imparte.
- Todo buen trabajo de software comienza a partir de las necesidades personales del programador.
- Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.
Aunque algunos trabajen a cambio de un salario en programas que no necesitan, la necesidad de solucionar problemas o hacer más fácil una tarea suele ser la causa más común de emprender un proyecto SCA (Software de Código Abierto), además de las ganas de saber más sobre cierto problema o tarea que ha creado curiosidad en el hacker. Me gustaría resaltar la palabra “personales” de la primera lección, ya que si nace de una necesidad o curiosidad personal la implicación de la persona en el trabajo será completa, mientras que si no existe esa necesidad, como en el caso del trabajador a cambio de un salario al que no le interesa lo que programa, tanto la implicación como la motivación serán menores, y por lo cual, la eficiencia se verá mermada.
- Los buenos programadores saben qué escribir. Los mejores, qué rescribir (y reutilizar).
- Lo más grande, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios. Esto ultimo a veces es mejor.
Siempre es más fácil coger algo que ya está hecho y modificarlo que empezar a construirlo desde el principio. Recuperamos la idea de que “Ningún problema tendría que resolverse dos veces” que escribió en “Cómo convertirse en hacker”. Deberíamos empezar reutilizando todas las partes que funcionan bien y modificar solo aquella que da problemas, aunque al final acabemos con algo completamente distinto en todos los aspectos. Es un método bastante utilizado entre los estudiantes en trabajos que se repiten año tras año en la universidad, coger trabajos de años anteriores y partir de ahí reutilizando todo aquello que se pueda.
- “Contemple desecharlo; de todos modos tendrá que hacerlo” (Fred Brooks, en Raymond)
- Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.
Aunque cueste hacerlo, habrá un punto en el que será necesario desechar al menos una parte de la solución inicial porque uno se habrá dado cuenta de la realidad del problema y que hay otra solución mejor que la que había empezado a construir, así que “disponte a empezar de nuevo al menos una vez”.
- Si tienes la actitud adecuada, encontrarás problemas interesantes.
- Cuando se pierde el interés en un programa, el ultimo deber es heredarlo a un sucesor competente.
Raymond tenía esta creencia y en el caso que cuenta en este texto, pasó de enviar una serie de mejoras de un programa (fetchpop) a identificar las partes que más interesantes le parecían de dos programas (fetchpop y popclient), hacerse cargo de una de ellas (popclient) y crear uno que integrase lo bueno de los dos con algunas mejoras adicionales (fetchmail). Este cambio explica el modo en el que los proyectos evolucionan en el software libre, pasando el control de una persona a otra cuando se ha perdido el interés e implementando mejoras a estos programas en la medida de lo posible.
- Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.
- 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.
Si consideras que el usuario también tiene esa necesidad y que puede ser una parte importante en la creación de software, en otras palabras, si eres consciente de que entre los usuarios hay otros hackers y si liberas código según lo vas generando, te darás cuenta que “pueden convertirse en magníficos asistentes”. Además, los usuarios pueden hacer que se produzca el cambio de rumbo en el proyecto que antes he citado.
- Libere rápido y a menudo, y escuche a sus clientes.
El modelo Catedral se basa en la creencia de que liberar código de primeras versiones era una “mala política”, ya que suelen tener muchos errores y pueden ser agotadores para los usuarios. Por eso, se libera poco y cuando la mayoría de los errores están ya depurados. En el modelo Bazar, pasa todo lo contrario. Torvalds le dio una intensidad de publicación acorde con la complejidad del proyecto (en su caso, el kernel de Linux), “manteniendo a sus usuarios-hackers-asistentes constantemente estimulados y recompensados con la exhibición y mejora constante, casi diaria, de su trabajo”. En lo relativo a escuchar a los clientes, Raymond defiende que aunque no le den dinero a cambio del software (por ser libre), debe de seguir escuchándoles, ya que programa para y con ellos.
- 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.
Si unos pocos tienen que revisar un programa, buscar los errores y depurarlos (modelo Catedral) lo más probable es que tarden mucho tiempo y además no aseguran que se encuentren todos los errores. Sin embargo, si hay muchos usuarios revisando un programa simultáneamente (modelo Bazar), detectaran más errores y en menos tiempo que los anteriores, dándose la posibilidad de que no sea la misma persona la que encuentre el error y la que lo resuelva. Esto ocurre gracias a que cada usuario tiene una forma distinta de evaluar el programa.
- 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.
Trata de definir a ese líder-coordinador y a las motivaciones que llevan a una comunidad a seguir a ese líder. El líder ha de ser capaz de atraer a los demás usuarios hacia su trabajo no por coerción, sino por sus hábitos de cooperación. Raymond pone un pasaje del anarquista Piotr Kropotkin en “Memorias de un revolucionario” como ejemplo:
“Habiendo sido criado en una familia que tenía siervos, me incorporé a la vida activa, como todos los jóvenes de mi época, con una gran confianza en la necesidad de mandar, ordena, regañar, castigar y cosas semejantes. Pero cuando en una etapa temprana, tuve que manejar empresas serias y tratar con hombres libres, y cuando cada error podría acarrear serias consecuencias, yo comencé a apreciar la diferencia entre actuar con base en el principio de orden y disciplina y actuar con base en el principio del entendimiento. El primero funciona admirablemente en un desfile militar, pero no sirve cuando está involucrada la vida real y el objetivo solo puede lograrse mediante el esfuerzo serio de muchas voluntades convergentes.”
De éste texto Raymond resalta el concepto de trabajar con “muchas voluntades convergentes”, distintos individuos con inquietudes distintas trabajando en el mismo proyecto y que solo consiguen un resultado satisfactorio mediante el entendimiento entre todos ellos. Además, señala que el hacker (sea líder o no) trabaja por una reputación entre los demás, por “satisfacción de su ego”. Un líder no debe imponer su proyecto a sus colaboradores, ya que así, se producirían resultados de menor calidad, sino que debe estimular el ego de los demás para que estos trabajen de manera voluntaria recibiendo el reconocimiento por parte de la comunidad como recompensa.
Después de todas estas lecciones (hay más pero he quitado las que me parecían más técnicas) Raymond se lanza a describir las condiciones necesarias para poder desarrollar el modelo Bazar.
- Nos dice que no es posible crear desde cero con este modelo, que se puede “probar, buscar errores, poner a punto y mejorar algo”.
- El proyecto puede ser incompleto y plagado de errores, pero tiene que tener un potencial capaz de convencer a los desarrolladores.
- El “líder-coordinador” del proyecto debe saber “reconocer las buenas ideas sobre el diseño de los demás, (…) tener don de gentes y una buena capacidad de comunicación.(…) Además, es importante la personalidad que uno proyecta”.
Y es que “si se tiene las miradas suficientes, todas las pulgas saltarán a la vista”.
Incoming Links (via Tecnorati):
- los sueños de la razón / blog de poca fe
, concretamente versa sobre la intervenci??n de Luis Mar??a Ullibarri. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante. Esas palabras son de Eric S. Raymond y nos las trae Lups desde su ??ltimo art??culo sobre ??tica hacker. Para ??ticas m??s trasnochadas, las de hace no tanto y que se reflejan en este cartel que encontr?? Luri en su Caf?? de Ocata. Tambi??n all?? le?? esta l??cida entrada que cierra el ciclo de cuatro reflexiones
Comments»
[...] palabras son de Eric S. Raymond y nos las trae Lups desde su último artículo sobre ética hacker. Para éticas más trasnochadas, las de hace no tanto y que se reflejan en este cartel que [...]