dingofanmadrid

10. 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.

Una medida interesante del éxito de fetchmail fue el tamaño de la lista de analistas beta del proyecto, los amigos de fetchmail. Cuando escribí esto, tenía 249 miembros, y se sumaban entre dos y tres semanalmente.

Revisandola hoy, finales de mayo de 1997, la lista ha comenzando a perder miembros debido a una razón sumamente interesante. ¡Varias personas me han pedido que los dé de baja debido a que el fetchmail les está funcionando tan bien que ya no necesitan ver todo el tráfico de de la lista! A lo mejor esto es parte del ciclo vital normal de un proyecto maduro realizado por el método de construcción estilo bazar.
6 Popclient se convierte en Fetchmail

El momento crucial para el proyecto fue cuando Harry Hochheiser me mandó su código fuente para incorporar la remisión del correo recibido a la máquina cliente a través del puerto SMTP. Comprendí casi inmediatamente que una implementación adecuada de esta característica iba a dejar a todos los demás métodos a un paso de ser obsoletos.

Durante muchas semanas habí estado perfeccionando fetchmail, agregándole características, a pesar de que sentía que el diseño de la interfaz era útil pero algo burdo, poco elegante y con demasiadas opciones insignificantes colgando fuera de lugar. La facilidad de vaciar el correo recibido a un archivo-buzón de correos o la salida estándar me incomodaba de cierta manera, pero no alcanzaba a comprender por qué.

Lo que advertí cuando me puse a pensar sobre la expedición del correo por el SMTP fue que el popclient estaba intentando hacer demasiadas cosas juntas. Había sido diseñado para funcionar al mismo tiempo como un agente de transporte (MTA) y un agente de entrega (MDA). Con la remisión del correo por el SMTP podría abandonar la función de MDA y centrarme solamente en la de MTA, mandando el correo a otros programas para su entrega local, justo como lo hace sendmail.

¿Por qué sufrir con toda la complejidad que encierra ya sea configurar el agente de entrega o realizar un bloqueo y luego un añadido al final del archivo-buzón de correos, cuando el puerto 25 está casi garantizado casi en toda plataforma con soporte TCP/IP? Especialmente cuando esto significa que el correo obtenido de esta manera tiene garantizado verse como un correo que ha sido transferido de manera normal, por el SMTP, que es lo que realmente queremos.

De aquí se extraen varias lecciones. Primero, la idea de enviar por el puerto SMTP fue la mayor recompensa individual que obtuve al tratar de emular conscientemente los métodos de Linus. Un usuario me proporcionó una fabulosa idea, y lo único que restaba era comprender sus implicaciones.

11. Lo más grande, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor.

Lo que resulta muy interesante es que usted rápidamente encontrará que cuando esta absolutamente convencido y seguro de lo que le debe a los demás, entonces el mundo lo tratará como si usted hubiera realizado cada parte de la invención por si mismo, y esto le hará apreciar con modestia su ingenio natural. ¡Todos podemos ver lo bien que funcionó esto para el propio Linus!

(Cuando leía este documento en la Conferencia de Perl de agosto de 1997, Larry Wall estaba en la fila del frente. Cuando llegué a lo que acabo de decir, Larry dijo con voz alta: "¡Anda, di eso, díselos, hermano!" Todos los presentes rieron porque sabían que eso también le había funcionado muy bien al inventor de Perl)

Y a unas cuantas semanas de haber echado a andar el proyecto con el mismo espíritu, comencé a recibir adulaciones similares, no sólo de parte de mis usuarios, sino de otra gente que se había enterado por terceras personas. He puesto a buen recaudo parte de ese correo. Lo volveréa a leer en alguna ocasión, si es que me llego a preguntar si mi vida ha valido la pena :-).

Pero hay otras dos lecciones más fundamentales, que no tienen que ver con las políticas, que son generales para todos los tipos de diseño:

12. Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.

Había estado intentando resolver el problema equivocado al continuar desarrollando el popclient como un agente de entrega y de transporte combinados, con toda clase de modos medio raros de entrega local. El diseño de fetchmail requería ser repensado de arriba abajo como un agente de transporte puro, como eslabón, si se habla de SMTP, de la ruta normal que sigue el correo en Internet.

Cuando usted se topa con un muro durante el desarrollo -cuando la encuentra difícil como para pensar mas allá de la corrección que sigue- es, a menudo, la hora de preguntarse no si usted realmente tiene la respuesta correcta, sino si se está planteando la pregunta correcta. Quizás el problema requiere ser replanteado.

Bien, yo ya había replanteado mi problema. Evidentemente, lo que tenía que hacer ahora era (1) programar el soporte de envío por SMTP en el controlador genérico, (2) hacerlo el modo por omisión, y (3) eliminar eventualmente todas las demás modalidades de entrega, especialmente las de envío a un archivo-buzón y la de vaciado a la salida estándar.

Estuve, durante algún tiempo, titubeando en dar el paso 3; temiendo trastornar a los viejos usuarios de poclient, quienes dependían de estos mecanismos alternativos de entrega. En teoría, ellos podían cambiar inmediatamente a archivos .forward, o sus equivalentes en otro esuema que no fuera sendmail, para obtener los mismos resultados. Pero, en la práctica, la transición podría complicarse demasiado.

Cuando por fin lo hice, empero, los beneficios fueron inmensos. Las partes más intrincadas del código del controlador desaparecieron. La configuración se volvió radicalmente más simple: al no tratar con el MDA del sistema y con el archivo-buzón del usuario, ya no había que preocuparse de que el sistema operativo soportara bloqueo de archivos.

Asimismo, el único riesgo de extraviar correo también se había desvanecido. Antes, si usted especificaba el envío a un archivo-buzón y el disco estaba lleno, entonces el correo se perdía irremediablemente. Esto no pasa con el envío vía SMTP debido a que el SMTP del receptor no devolverá un OK mientras el mensaje no haya sido entregado con éxito, o al menos haya sido mandado a la cola para su entrega ulterior.

Además, el desempeño mejoró mucho (aunque uno no lo notaráa en la primera corrida). Otro beneficio nada despreciable fue la simplificación de la página del manual.

Más adelante hubo que agregar la entrega a un agente local especificado por el usuario con el fin de manejar algunas situaciones oscuras involucradas con la asignación dinámica de direcciones en SLIP. Sin embargo, encontré una forma mucho más simple de hacerlo.

¿Cuál era la moraleja? No hay que vacilar en desechar alguna característica superflua si puede hacerlo sin pérdida de efectividad. Antôine de Saint-Exupery (un aviador y diseñador de aviones, cuando no se dedicaba a escribir libros clásicos para niños) afirmó que

13. "La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar."

Cuando el código va mejorando y se va simplificando, es cuando sabe que está en lo correcto. Así, en este proceso, el diseño de fetchmail adquirió una identidad propia, diferente de su ancestro, el popclient.

Había llegado la hora de cambiar de nombre. El nuevo diseño parecía más un doble del Sendmail que el viejo popclient; ambos eran MTAs, agentes de transporte, pero mientras que el Sendmail empuja y luego entreg, el nuevo popclient jala y después entrega. Así que, después de dos arduos meses, lo bautice de nuevo con el nombre de fetchmail.
7 El crecimiento de Fetchmail

Allí me encontraba con un bonito e innovador diseño, un programa que sabía funcionaba bien porque lo utilizaba diariamente, y me enteraba por la lista beta, que era muy activa. Esta gradualmente me hizo ver que ya no estaba involucrado en un hackeado personal trivial, que podía resultar útil para unas cuantas personas más. Tenía en mis manos un programa que cualquier hacker con una caja UNIX y una conexión SLIP/PPP realmente necesita.

Con el método de expedición por SMTP se puso adelante de la competencia, lo suficiente como para poder convertirse en un "matón profesional", uno de esos programas clásicos que ocupa tan bien su lugar que las otras alternativas no sólo son descartadas, sino olvidadas.

Pienso que uno realmente no podría imaginar o planear un resultado como éste. Usted tiene que meterse a manejar conceptos de diseño tan poderosos que posteriormente los resultados parezcan inevitables, naturales, o incluso predestinados. La única manera de hacerse de estas ideas es jugar con un montón de ideas; o tener una visión de la ingeniería suficiente para poder llevar las buenas ideas de otras personas más allá de lo que sus propios autores originales pensaban que podían llegar.

Andrew Tanenbaum tuvo una buena idea original, con la construcción de un UNIX nativo simple para 386, que sirviera como herramienta de enseñanza. Linus Torvalds llevó el concepto de Minix más allá de lo que Andrew imagino que pudiera llegar, y se transformó en algo maravilloso. De la misma manera (aunque en una escala menor), tomé algunas ideas de Carl Harris y Harry Hochheiser y las impulsé fuertemente. Ninguno de nosotros era "original" en el sentido romántico de la idea que la gente tiene de un genio. Pero, la mayor parte del desarrollo de la ciencia, la ingeniería y el software no se debe a un genio original, sino a la mitología del hacker por el contrario.

Los resultados fueron siempre un tanto complicados: de hecho, ¡justo el tipo de reto para el que vive un hacker! Y esto implicaba que tenía que fijar aún más alto mis propios estándares. Para hacer que el fetchmail fuese tan bueno como ahora veía que podía ser, tenía que escribir no sólo para satisfacer mis propias necesidades, sino también incluir y dar el soporte a otros que estuvieran fuera de mi órbita. Y esto lo tenía que hacer manteniendo el programa sencillo y robusto.

La primera característica más importante y contundente que escribí después de hacer eso fue el soporte para recabado múltiple, esto es, la capacidad de recoger el correo de los buzones que habían acumulado todo el correo de un grupo de usuarios, y luego trasladar cada mensaje al recipiente individual del respectivo destinatario.

Decidí agregarle el soporte de recabado múltiple debido en parte a que algunos usuarios lo reclamaban, pero sobre todo porque evidenciaría los errores de un código de recabado individual, al forzarme a abordar el direccionamiento con generalidad. Tal como ocurrió. Poner el RFC822 a que funcionara correctamente me tomó bastante tiempo, no sólo porque cada uno de las partes que lo componen son difíciles, sino porque involucraban un montón de detalles confusos e interdependientes entre sí.

Así, pues, el direccionamiento del recabado múltiple se volvió una excelente decisión de diseño. De esta forma supe que:

14 Toda herramienta es útil empleándose de la forma prevista, pero una *gran* herramienta es la que se presta a ser utilizada de la manera menos esperada.

El uso inesperado del recabado múltiple del fetchmail fue el trabajar listas de correo con la lista guardada, y realizar la expansión del alias en el lado del cliente de la conexión SLIP/PPP. Esto significa que alguien que cuenta con una computadora y una cuenta de ISP puede manejar una lista de correos sin que tenga que continuar entrando a los archivos del alias del ISP.

Otro cambio importante reclamado por mis auxiliares beta era el soporte para la operación MIME de 8 bits. Esto se podía obtener fácilmente, ya que había tenido cuidado de mantener el código de 8 bits limpio. No es que yo me hubiera anticipado a la exigencia de esta característica, sino que obedecía a otra regla:

15. Cuándo se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaución de alterar el flujo de datos lo menos posible, y ¡*nunca* eliminar información a menos que los receptores obliguen a hacerlo!

Si no hubiera obedecido esta regla, entonces el soporte MIME de 8 bits habría resultado difícil y lleno de errores. Así las cosas, todo lo que tuve que hacer fue leer el RFC 1652 y agregar algo de lógica trivial en la generación de encabezados.

Algunos usuarios europeos me presionaron para que introdujera una opción que limitase el número de mensajes acarreados por sesión (de manera tal que pudieran controlar los costos de sus redes telefónicas caras). Me opuse a dicho cambio durante mucho tiempo, y aun no estoy totalmente conforme con él. Pero si usted escribe para el mundo, debe escuchar a sus clientes: esto no debe cambiar en nada tan sólo porque no le están dando dinero.
8 Algunas lecciones mas extraídas de Fetchmail

Antes de volver a los temas generales de ingeniería de software, hay que ponderar otras dos lecciones específicas sacadas de la experiencia de fetchmail.

La sintaxis de los archivos rc incluyen palabras clave opcionales "de ruido" que son ignoradas totalmente por el analizador de sintaxis. La sintaxis tipo inglés que estas permiten es considerablemente más legible que la secuencia de pares palabra clave-valor tradicionales que usted obtiene cuando quita esas palabras clave opcionales.

Estas comenzaron como un experimento de madrugada, cuando noté que muchas de las declaraciones de los archivos rc se asemejaban un poco a un minilenguaje imperativo. (Esta también fue la razón por la cual cambié la palabra clave original del popclient de "servidor" a "poll").

Me parecía en ese entonces que el convertir ese minilenguaje imperativo más tipo inglés lo podía hacer más fácil de usar. Ahora, a pesar de que soy un partidario convencido de la escuela de diseño "hágalo un lenguaje", ejemplificada en Emacs, HTML y muchas bases de datos, no soy normalmente un fanático de la sintaxis estilo inglés.

Los programadores han tendido a favorecer tradicionalmente la sintaxis de control, debido a que es muy precisa, compacta y no tienen redundancia alguna. Esto es una herencia cultural de la época en que los recursos de cómputo eran muy caros, por lo que la etapa de análisis tenía que ser la más sencilla y económica posible. El inglés, con un 50% de redundancia, parecía ser un modelo muy inapropiado en ese entonces.

Este no es la razón por la cual yo dudo de la sintaxis tipo inglés; y sólo lo menciono aquí para demolerlo. Con los ciclos baratos, la fluidez no debe ser un fin por sí misma. Ahora es más importante para un lenguaje el ser conveniente para los humanos que ser económico en términos de recursos computacionales.

Sin embargo, hay razones suficientes para andar con cuidado. Una es el costo de la complejidad de la etapa de análisis: nadie quiere incrementarlo a un punto tal que se vuelva una fuente importante de errores y confusión para el usuario. Otra radica en que al hacer una sintaxis del lenguaje tipo inglés se exige frecuentemente que se deforme considerablemente el "inglés" que habla, por lo que la semejanza superficial con un lenguaje natural es tan confusa como podría haberlo sido la sintaxis tradicional. (Usted puede ver mucho de esto en los 4GLs y en los lenguajes de búsqueda en bancos de datos comerciales).

La sintaxis de control de fetchmail parece esquivar estos problemas debido a que el dominio de su lenguaje es extremadamente restringido. Está muy lejos de ser un lenguaje de amplio uso; las cosas que dice no son muy complicadas, por lo que hay pocas posibilidades de una confusión, al moverse de un reducido subconjunto del inglés y el lenguaje de control real. Creo que se puede extraer una lección más general de esto:

16. Cuando su lenguaje está lejos de un Turing completo, entonces el azúcar sintáctico puede ser su amigo.

Otra lección trata de la seguridad por obscuridad. Algunos usuarios de fetchmail me solicitaron cambiar el software para poder guardar las claves de acceso encriptadas en su archivo rc, de manera tal que los crackers no pudieran verlos por pura casualidad.

No lo hice debido a que esto prácticamente no proporcionaría ninguna protección adicional. Cualquiera que adquiera los permisos necesarios para leer el archivo rc respectivo sería de todos modos capaz de correr el fetchmail; y si por su password fuera, podría sacar el decodificador necesario del mismo código del fetchmail para obtenerlo.

Todo lo que la encriptación de passwords en el archivo .fetchmailrc podría haber conseguido era una falso sensación de seguridad para la gente que no está muy metida en este medio. La regla general es la siguiente:

17. Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.
9 Condiciones necesarias para el Estilo del Bazar

Los primeros que leyeron este documento, así como sus primeras versiones inacabadas que se hicieron públicas, preguntaban constantemente sobre los requisitos necesarios para un desarrollo exitoso dentro del modelo del bazar, incluyendo tanto la calificación del líder del proyecto como la del estado del código cuando uno va a hacerlo público y a comenzar a construir una comunidad de co-desarrolladores.

Esta claro que uno no puede partir de cero en el estilo bazar. Con él, uno puede probar, buscar errores, poner a punto y mejorar algo, pero sería muy difícil originar un proyecto en un modo semejante al bazar. Linus no lo intentó de esta manera. Yo tampoco lo hice así. Nuestra naciente comunidad de desarrolladores necesita algo que ya corra para jugar.

Cuando uno comienza la construcción del edificio comunal, lo que debe ser capaz de hacer es presentar una promesa plausible. El programa no necesita ser particularmente bueno. Puede ser burdo, tener muchos errores, estar incompleto y pobremente documentado. Pero en lo que no se puede fallar es en convencer a los co-desarrolladores potenciales de que el programa puede evolucionar hacia algo elegante en el futuro.

Linux y fetchmail se hicieron públicos con diseños básicos fuertes y atractivos. Mucha gente piensa que el modelo del bazar tal como lo he presentado, ha considerado correctamente esto como crítico, y luego ha saltado de aquí a la conclusión de que es indispensable que el líder del proyecto tenga un mayor nivel de intuición para el diseño y mucha capacidad.

Sin embargo, Linus obtuvo su diseño a partir de UNIX. Yo inicialmente conseguí el mío del antiguo popmail (a pesar de que cambiaría mucho posteriormente, mucho más, guardando las proporciones, de lo que lo ha hecho Linux). Entonces, ¿tiene que poseer realmente un talento extraordinario el líder-coordinador en el modelo del bazar, o la puede ir pasando con tan sólo coordinar el talento de otros para el diseño?

Creo que no es crítico que el coordinador sea capaz de originar diseños de calidad excepcional, pero lo que sí es absolutamente esencial es que él (o ella) sea capaz de reconocer las buenas ideas sobre diseño de los demás.

Tanto el proyecto de Linux como el de fetchmail dan evidencias de esto. A pesar de que Linus no es un diseñador original espectacular (como lo discutimos anteriormente), ha mostrado tener una poderosa habilidad para reconocer un buen diseño e integrarlo al kernel de Linux. Ya he descrito cómo la idea de diseño de mayor envergadura para el fetchmail (reenvío por SMTP) provino de otro.

Los primeros lectores de este artículo me halagaron al sugerir que soy propenso a subestimar la originalidad en el diseño en los proyectos del bazar, debido a que la tengo en buena medida, y por lo tanto, la tomo por sentada. Puede ser verdad en parte; el diseño es ciertamente mi fuerte (comparado con la programación o la depuración).

Pero el problema de ser listo y original en el diseño de software se tiende a convertir en hábito: uno hace las cosas como por reflejo, de manera tal que parezcan elegantes y complicadas, cuando debería mantenerlas simples y robustas. Ya he sufrido tropiezos en proyectos debido a esta equivocación, pero me las ingenié para no sucediera lo mismo con fetchmail.

Así, pues, considero que el proyecto del fetchmail tuvo éxito en parte debido a que contuve mi propensión a ser astuto; este es un argumento que va (por lo menos) contra la originalidad en el diseño como algo esencial para que los proyectos del bazar sean exitosos. Consideremos de nuevo Linux. Supóngase que Linus Torvalds hubiera estado tratando de desechar innovaciones fundamentales en el diseño del sistema operativo durante la etapa de desarrollo; ¿podría acaso ser tan estable y exitoso como el kernel que tenemos hoy en realidad?

Por supuesto, se necesita un cierto nivel mínimo de habilidad para el diseño y la escritura de programas, pero es de esperar que cualquiera que quiera seriamente lanzar un esfuerzo al estilo del bazar ya esté por encima de este nivel. El mercado interno de la comunidad del software libre, por reputación, ejerce una presión sutil sobre la gente para que no inicie esfuerzos de desarrollo que no sea capaz de mantener. Hasta ahora, esto parece estar funcionando bastante bien.

Existe otro tipo de habilidad que no esta asociada normalmente con el desarrollo del software, la cual yo considero que es igual de importante para los proyectos del bazar, y a veces hasta más, como el ingenio en el diseño. Un coordinador o líder de proyecto estilo bazar debe tener don de gentes y una buena capacidad de comunicación.

Esto podría parecer obvio. Para poder construir una comunidad de desarrollo se necesita atraer gente, interesarla en lo que se está haciendo y mantenerla a gusto con el trabajo que se está desarrollando. El entusiasmo técnico constituye una buena parte para poder lograr esto, pero está muy lejos de ser definitivo. Además, es importante la personalidad que uno proyecta.

No es una coincidencia que Linus sea un tipo que hace que la gente lo aprecie y desee ayudarle. Tampoco es una coincidencia que yo sea un extrovertido incansable que disfruta de trabajar con una muchedumbre, y tenga un poco de porte e instintos de cómico improvisado. Para hacer que el modelo bazar funcione, ayuda mucho tener al menos un poco de capacidad para las relaciones sociales.
10 El contexto social del software libre

Bien se ha dicho: las mejores hackeadas comienzan como soluciones personales a los problemas cotidianos del autor, y se se vuelven populares debido a que el problema común para un buen grupo de usuarios. Esto nos hace regresar al tema de la regla 1, que quizá puede replantearse de una manera más útil:

18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.

Así ocurrió con Carl Harris y el antiguo popclient, y así sucede conmigo y fetchmail. Esto, sin embargo, se ha entendido desde hace mucho. El punto interesante, el punto que las historias de Linux y fetchmail nos piden enfocar, está en la siguiente etapa, en la de la evolución del software en presencia de una amplia y activa comunidad de usuarios y co-desarrolladores.

En The Mythical Man-Month, Fred Brooks observó que el tiempo del programador no es fungible; que el agregar desarrolladores a un proyecto maduro de software lo vuelve tardío. Expuso que la complejidad y los costos de comunicación de un proyecto aumentan como el cuadrado del número de desarrolladores, mientras que el trabajo crece sólo linealmente. A este planteamiento se le conoce como la Ley de Brooks, y es generalmente aceptado como algo cierto. Pero si la Ley de Brooks fuese general, entonces Linux sería imposible.

Unos años después, el clásico de Gerald Weinberg La Psicología de la Programación de Computadoras plantea, visto en retrospectiva, una corrección esencial a Brooks. En su discusión de la "programación sin ego", Weinberg señala que en los lugares donde los desarrolladores no tienen propiedad sobre su código, y estimulan a otras personas a buscar errores y posibles mejoras, son los lugares donde el avance es dramáticamente más rápido que en cualquier otro lado.

La terminología empleada por Weinberg ha evitado quizá que su análisis gane la aceptación que merece: uno tiene que sonreír al oír que los hackers de Internet no tienen ego. Creo, no obstante, que su argumentación parece más valida ahora que nunca.

La historia de UNIX debió habernos preparado para lo que hemos aprendido de Linux (y lo que he verificado experimentalmente en una escala más reducida al copiar deliberadamente los métodos de Linus). Esto es, mientras que la creación de programas sigue siendo esencialmente una actividad solitaria, los desarrollos realmente grandes surgen de la atención y la capacidad de pensamiento de comunidades enteras. El desarrollador que usa solamente su cerebro sobre un proyecto cerrado está quedando detrás del que sabe como crear en un contexto abierto y evolutivo en el que la búsqueda de errores y las mejoras son realizadas por cientos de personas.

Pero el mundo tradicional de UNIX no pudo llevar este enfoque hasta sus últimas consecuencias debido a varios factores. Uno era las limitaciones legales producidas por varias licencias, secretos e intereses comerciales. Otra (en retrospectiva) era que la Internet no estaba todavía madura para lograrlo.

Antes de que Internet fuera tan accesible, había comunidades geográficamente compactas en las cuales la cultura estimulaba la "programación sin ego" de Weinberg, y el desarrollador podía atraer fácilmente a muchos desarrolladores y usuarios capacitados. El Bell Labs, el MIT AI Lab, la Universidad de California en Berkeley son lugares donde se originaron innovaciones que son legendarias y aún poderosas.

Linux fue el primer proyecto de un esfuerzo consciente y exitoso de usar el mundo entero como un nido de talento. No creo que sea coincidencia que el período de gestación de Linux haya coincidido con el nacimiento de la World Wide Web, y que Linux haya dejado su infancia durante el mismo período, en 1993-1994, en que se vio el despegue de la industria ISP y la explosión del interés masivo por la Internet. Linus fue el primero que aprendió a jugar con las nuevas reglas que esa Internet penetrante hace posibles.

A pesar de que la Internet barata es una condición necesaria para que evolucionara el modelo de Linux, no creo que sea en sí misma una condición suficiente. Otros factores vitales fueron el desarrollo de un estilo de liderazgo y el arraigo de hábitos cooperativos, que permiten a los programadores atraer más co-desarrolladores y obtener el máximo provecho del medio.

Pero, ¿qué es el estilo de liderazgo y qué estos hábitos? No pueden estar basados en relaciones de poder, y aunque lo fueran, el liderazgo por coerción no produciría los resultados que estamos viendo. Weinberg cita un pasaje de la autobiografía del anarquista ruso del siglo XIX Kropotkin Memorias de un Revolucionario, que está muy acorde con este tema:

"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, ordenar, 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 sólo puede lograrse mediante el esfuerzo serio de muchas voluntades convergentes."

El "esfuerzo serio de muchas voluntades convergentes" es precisamente lo que todo proyecto estilo Linux requiere; mientras que el "principio de orden y disciplina" es efectivamente imposible de aplicar a los voluntarios del paraíso anarquista que llamamos Internet. Para poder trabajar y competir de manera efectiva, los hackers que quieran encabezar proyectos de colaboración deben aprender a reclutar y entusiasmar a las comunidades de interés de un modo vagamente sugerido por el "principio de entendimiento" de Kropotkin. Deben aprender a usar la Ley de Linus.

Anteriormente me referí al efecto Delphi como una posible explicación de la Ley de Linus. Pero existen analogías más fuertes con sistemas adaptivos en biología y economía que se sugieren irresistiblemente. El mundo de Linux se comporta en muchos aspectos como el libre mercado o un sistema ecológico, donde un grupo de agentes individualistas buscan maximizar la utilidad en la que los procesos generan un orden espontáneo autocorrectivo más desarrollado y eficiente que lo que podría lograr cualquier tipo de planeación centralizada. Aquí, entonces, es el lugar para ver el "principio del entendimiento".

La "función utilidad" que los hackers de Linux están maximizando no es económica en el sentido clásico, sino algo intangible como la satisfacción de su ego y su reputación entre otros hackers. (Uno podría hablar de su "motivación altruista", pero ignoraríamos el hecho de que el altruismo en sí mismo es una forma de satisfacción del ego para el altruista). Los grupos voluntarios que funcionan de esta manera no son escasos realmente; uno en el que he participado es el de los aficionados a la ciencia ficción, que a diferencia del mundo de los hackers, reconoce explícitamente el "egoboo" (el realce de la reputación de uno entre los demás) como la motivación básica que está detrás de la actividad de los voluntarios.

Linus, al ponerse exitosamente como vigía de un proyecto en el que el desarrollo es realizado por otros, y al alimentar el interés en él hasta que se hizo autosustentable, ha mostrado el largo alcance del "principio de entendimiento mutuo" de Kropotkin. Este enfoque cuasieconómico del mundo de Linux nos permite ver cual es la función de tal entendimiento.

Podemos ver al método de Linus como la forma de crear un mercado eficiente en el "egoboo", que liga, lo más firme posible, el egoísmo de los hackers individuales a objetivos difíciles que sólo se pueden lograr con la cooperación sostenida. Con el proyecto de fetchmail he demostrado (en una escala mucho menor, claro) que sus métodos pueden copiarse con buenos resultados. Posiblemente, lo mío fue realizado de una forma un poco más consciente y sistemática que la de él.

Muchas personas (especialmente aquellas que desconfían políticamente del libre mercado) podrían esperar que una cultura de individuos egoístas que se dirigen solos sea fragmentaria, territorial, clandestina y hostil. Pero esta idea es claramente refutada, por (por poner un ejemplo) la asombrosa variedad, calidad y profundidad de la documentación de Linux. Se da por un hecho que los programadores odian la documentación: ¿cómo entonces los hackers de Linux generan tanta? Evidentemente, el libre mercado en egoboo de Linux funciona mejor para producir tal virtuosismo, que los departamentos de edición, masivamente subsidiados, de los productores comerciales de software.

Tanto el proyecto de fetchmail como el del kernel de Linux han demostrado que con el estimulo apropiado al ego de otros hackers, un desarrollador/coordinador fuerte puede usar la Internet para aprovechar los beneficios de contar con un gran número de co-desarrolladores, sin que se corra el peligro de desbocar el proyecto en un auténtico relajo. Por lo tanto, a la Ley de Brooks yo le contrapongo lo siguiente:

19. 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.

Pienso que el futuro del software libre será cada vez más de la gente que sabe como jugar el juego de Linus, la gente que deja atrás la catedral y abraza el bazar. Esto no quiere decir que la visión y la brillantez individuales ya no importen; al contrario, creo que en la vanguardia del software libre estarán quienes comiencen con visión y brillantez individual, y luego las enriquezcan construyendo positivamente comunidades voluntarias de interés.

A lo mejor éste no sólo es el futuro del software libre. Ningún desarrollador comercial sería capaz de reunir el talento que la comunidad de Linux es capaz de invertir en un problema. ¡Muy pocos podrían pagar tan solo la contratación de las más de doscientas personas que han contribuido al fetchmail!

Es posible que a largo plazo triunfe la cultura del software libre, no porque la cooperación es moralmente correcta o porque la "apropiación" del software es moralmente incorrecta (suponiendo que se crea realmente en esto último, lo cual no es cierto ni para Linus ni para mí), sino simplemente por que el mundo comercial no puede ganar una carrera de armamentos evolutiva a las comunidades de software libre, que pueden poner mayores órdenes de magnitud de tiempo calificado en un problema que cualquier compañía.