La Maison de la Vierge

Sensaciones

Post post-examen. Valga la redundancia. Post de una noche de verano (según el año de la amalurra ya estamos en verano) que se presenta como otra noche de insomnio, más. Día de sobredosis de cafeína, examen, presentación y otro post. Casi nada. Post de reflexión, cosa que no hice ayer. Post sobre negociación (sí, ya dije que el de ayer era el último y todo lo que queráis, pero otro más). Seré breve, no son horas.

Solo quiero hablar de dos cosas. Del observador y del binomio proponer/indagar. De como me siento en una negociación.

Sobre el observador, me he dado cuenta de que lo soy, me gusta mirar, escuchar, reflexionar y después hablar en las negociaciones. Hablo lo justo, no me gusta cuando hay que hablar mucho, por eso me gusta más que las negociaciones sean por grupos que individuales. No sé si soy bueno o malo observando, solo sé que me gusta y que he aprendido ciertas técnicas que permitirán que mis observaciones sean más válidas. Muchas veces parece que no estoy participando en las conversaciones, pero estoy ahí, no estoy ausente. La gente me suele decir que en esas ocasiones hablo poco pero hablo en momentos precisos con palabras precisas. Es un juicio que hacen, sus razones tendrán. Me gusta intentar saber lo que piensan los demás, que es lo que quieren conseguir y cual sería la mejor propuesta que pueda hacer para que los dos salgamos satisfechos.

Pero tengo un problema en esto del proponer/indagar. No soy una persona ni indagativa ni propositiva, por así decirlo. No pregunto, ni expongo, usualmente. Me limito a mirar y escuchar. Muchas veces he pensado que mi papel en las negociaciones no es ser ninguna de las dos partes, siempre me he sentido más cómodo en el papel de moderador que en el de negociador. Siempre en medio, sin interferir demasiado, escuchando a una y otra parte e intentando que lleguen a un acuerdo. Quizás, el transcurso de mi vida ha hecho que haya adoptado esta posición. Por eso, no propongo ni indago, espero a que me cuenten lo que me quieran contar. Hay veces que sí que pregunto, pero no es buscando saber, sino comprender. No busco los intereses ajenos, sino la comprensión propia, entender bien cual es la situación y qué es lo que ha llevado hasta ella.

No sé si soy un buen observador, repito, pero sí sé que no soy un buen negociador. Dejo la iniciativa en manos de los demás e intento ver cuál es la manera de la que yo pueda salir menos perjudicado de lo que me propone, no la manera de la que pueda salir beneficiado. Las negociaciones me tensan e intento salir lo más rápidamente posible de esta tensión. Por eso me gusta escribir, porque desaparece toda tensión ajena cuando expones las cosas. No hay nadie mirandote, ni hablandote en un tono mayor que el tuyo, ni gesticulando. Solo uno mismo y una hoja en blanco. Se puede pensar, repensar, leer, releer, escribir y reescribir. Rectificar. Y es explícito, en la mayoría de los casos. Directo. Aunque haya mucha prosa escrita y una sola idea, puedes sintetizar la idea y quedarte con ello.

Me ha servido este taller, he aprendido muchas cosas que no he puesto en práctica pero que poco a poco puede que las vaya probando en la vida real. Aunque todavía no he aprendido a quitarme esa tensión de encima cuando hablo. En la vida real, en negociaciones orales, la mayoría de las veces no tienes oportunidad de preparar las negociaciones, porque son de generación espontánea y de solución instantánea.

Caminando por Babel

Hoy 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”.

Cómo hacer de uno mismo un hacker

Después de haber estado un tiempo ausente del barrio, voy a seguir hablando de hackers. He dejado de lado a Himanen (de momento) para coger un artículo de Eric Steven Raymond, titulado “Cómo convertirse en hacker”. Es un texto que habla básicamente sobre hackers informáticos pero como el mismo Raymond dice, “La mentalidad hacker no está confinada a esta cultura del software. Hay gente que aplica la actitud de hacker a otras cosas”. Sobre esto ya hablé cuando comente a Himanen.

Lo interesante de este texto es que ofrece unas directrices con las cuales uno puede llegar a ser un hacker, algo así como el camino que nos llevará a la iluminación. Según Raymond, la mejor manera de aprender un arte creativo es por imitación y nos invita a imitar la mentalidad (intelectual y emocionalmente) de un hacker.

• El mundo esta lleno de problemas fascinantes que esperan ser resueltos

Y deberíamos experimentar cierto placer o felicidad (“estremecimiento de tipo primitivo”, textualmente) cuando hayamos resuelto un problema, ya que solucionar problemas requiere esfuerzo y este a su vez requiere motivación. Aun así, es divertido ser un hacker, pero es una clase de entretenimiento que solo se consigue mediante el esfuerzo.

• Ningún problema tendría que resolverse dos veces

He aquí la razón por la que hay que compartir la información. El tiempo es cada vez un bien más valorado y se ahorraría mucho si nadie tuviese que resolver un problema ya resuelto anteriormente. De esta manera, se dedica todo el esfuerzo en resolver nuevos problemas que surgen continuamente.

• El aburrimiento y el trabajo rutinario son perniciosos

El trabajo repetitivo impide al hacker utilizar su creatividad para resolver problemas. Por lo tanto, el hacker debe “automatizar las tareas rutinarias todo lo que se pueda” para poder dedicarse de pleno a aquello que le apasiona.

• La libertad es buena

“Cualquiera que pueda darte ordenes, puede obligarte a dejar de resolver ese problema que te esta fascinando. (…) Por eso, la actitud autoritaria debe ser combatida donde sea que se la encuentre, pues si se deja te asfixiara, tanto a ti como a otros hackers”. Los autoritarios no suelen ser propensos a compartir la información ni a cooperar en sus proyectos con otras personas, lo cual puede impedir al hacker realizar su tarea.

• La actitud no es sustituto para la competencia

Deberíamos desarrollar las actitudes antes citadas pero no basta solo con la actitud para ser un hacker, hace falta “inteligencia, práctica, dedicación y trabajo duro”. Con esto conseguiremos desarrollar cierta competencia en las áreas de nuestro trabajo. Raymond destaca como buenas las competencias en habilidades que domina poca gente y las que exigen “agudeza mental, destreza y concentración”.

Aparte de estas directrices para desarrollar la actitud, un hacker debe desarrollar ciertas habilidades en el campo que este trabajando. Para ello necesita dominar herramientas que, no hace ni falta decirlo, irán cambiando con el tiempo. Esto obliga al hacker a tener capacidad para aprender a utilizar diferentes herramientas sin especializarse en una sola. Este aprendizaje no tiene que ser teórico, sino practico, para poder aprender directamente de la experiencia.

Otro concepto que desarrolla Raymond en este texto es el del estatus o reputación, que se consigue mediante la valoración que los demás hacen sobre nuestro trabajo y cuanto más compartamos nuestro trabajo adquiriremos mayor estatus. Él lo llama “donar” (“al donar tu tiempo, tu creatividad y el resultado de tu destreza”) y da otra serie de directrices para poder obtener “el respeto de los hackers”, de las que se pueden extraer las siguientes ideas:

• Hacer cosas que sean útiles y donarlos para que puedan utilizarlo los demás.
• Probar y depurar errores del trabajo de otros.
• Publicar información útil.
• Ayudar a mantener en funcionamiento la infraestructura que utiliza la comunidad
• Hacer algo por la cultura hacker en si misma.

Por último, nos ofrece unos consejos muy poco ortodoxos para poder desarrollar habilidades, sobre todo de estilo o forma, que nos pueden ayudar en la correcta comunicación de ideas. Cosas muy básicas que a veces olvidamos.

• Aprender a escribir correctamente en tu lengua.
• Lee ciencia-ficción.
• Estudia zen y/o practica artes marciales.
• Desarrolla un oído analítico para la música.
• Desarrolla inclinación por los dobles sentidos y los juegos de palabras.

Personalmente no le veo mucho sentido a alguna de las actividades propuestas, se supone que son dirigidos a aquellos que se quieran convertir en hackers informáticos pero aparte de escribir correctamente no veo que utilidad pueden tener. “Por que estas cosas en particular y no otras es algo que no está completamente claro, pero todas están conectadas con una mezcla de la parte izquierda y la derecha de las habilidades de tu cerebro”. Parece ser que ayuda a utilizar la parte racional e irracional de nuestro ser.

Y otras muchas cosas son las que he encontrado en este “Como convertirse en hacker” de Eric S. Raymond, pero considero que no son relevantes por ser específicos de hackers informáticos (los lenguajes de programación mas sencillos, etcétera). Dos cosas me han llamado la atención considerablemente, que no tienen que ver con el tema: el tono prepotente que impera durante todo el texto y el FAQ (con preguntas como “¿Necesito odiar y golpear a Microsoft?”). Me ha recordado al personaje del Rey Xerxes en el film “300”, no se porque…