Ayer presenté una reflexión de Pentecostés titulada “dejar la catedral, salir a la calle”.

Como el lector atento habrá podido observar, estaba inspirada en un trabajo antiguo y ya famoso de Eric S. Raymond, escrito el año 1997, con título La catedral y el bazar. Ese escrito oponía dos “estilos” de desarrollo fundamentalmente opuestos.

‒ El modelo catedral sigue siendo utilizado por la mayoría de los fabricantes de software comercial, y por gran parte de investigadores, científicos, políticos y (en nuestro caso) de hombres de Iglesia: Se busca el modelo perfecto y se organiza todo desde arriba, conforme a un plan previamente definido y dirigido por alguien, desde arriba. Todas las cosas han sido pensadas previamente, todas han de ajustarse, como en una Catedral, donde un arquitecto dirige la obra de conjunto, conforme a un diseño, de manera que cada uno tiene que obedecer y seguir la norma de conjunto. Es lo que pasaba (a mi juicio) en la visión de la Iglesia Católica.

‒ Por el contrario, el modelo bazar del mundo Linux, no partía de un esquema superior, definido de antemano, sino que ofrecía unos espacios de colaboración directa, en los que cada uno puede entrar y aportar, sin un designio previo, por el placer de colaborar dialogando en la obra de todos. Ese modelo ha sido propuesto por Linus Benedict Torvalds (* 1969, Helsinki, Finlandia), ingeniero de cultura sueca, uno de los hombres más influyentes del momento actual, conocido por haber creado el “sistema operativo Linux”, que se funda precisamente en ese principio de la “colaboración de todos”. En esa línea, volviendo al ámbito teológico o religioso, podríamos decir que la “actividad del Espíritu” no está en alguno o algunos que dirigen la obra de los demás (que tienen que obedecer), sino que está en todos, que colaboran en la obra común de la comunicación y del conocimiento.

Modelo eclesial Linux. Principio

Según ese modelo, podría añadir que el Espíritu Santo no empieza dirigiendo las cosas desde un jerarca superior (organizando una compleja catedral, con su sabiduría más alta), sino que se introduce en el gran “bazar” de los intercambio múltiples, donde todos pueden aportar por igual sus iniciativas, sin más finalidad que la comunicación.

Ciertamente, las iniciativas de este modelo “Linux” (propio de un bazar eclesial) pueden y deben precisarse con cuidado, pero tienen un sentido y pueden ponerse ya en práctica. Ellas significarían un gran cambio en la organización y vida eclesial. Este “bazar” eclesial, tipo Linux, puede funcionar y funcionará si se tienen en cuenta cinco principio o reglas:

1. El Espíritu Santo, es decir, la creatividad cristiana pertenece a todos, no en un modelo jerárquico de catedral, sino en un modelo comunitario de bazar

2. Lo que en la iglesia se transmite de unos a otros (para compartirlo) no son unos saberes informáticos (como en Linux), ni unos contenidos teóricos (como en la Wikipedia), sino unos contenidos y medios vitales, de comunión humana, en plano de saber y querer, de compartir y gozar mutuamente.

3. El principio de este Linux eclesial no es el “capital” de algunos (sobre los demás o a costa de los demás), sino el capital común de todos, que se tiene en la medida en que se comparte, sobre un gran espacio de propiedad común de vida (que es el Espíritu Santo).

4. El modelo de agente de este Linux eclesial es Jesús, a quien podemos definir como hombre de la calle, que ha vivido para los demás, sin reservarse nada. Éste es un modelo de creatividad personal: Cada uno ofrece a los demás lo que tiene y puede, poniéndolo en circulación en la plaza común (en eso que podemos llamar el bazar-iglesia), por el gozo de ser y compartir

5. Este modelo de Iglesia (y esta Iglesia Linux-Bazar) no es de nadie, siendo de todos. En ella puede haber unos representantes de la comunión (obispos, ministros…), incluso un Papa…, como signo de la unidad y de la universalidad del “campo-linux”, pero ellos no tienen autoridad como personas (ni tienen un capital más grande), sino que son una especie de árbitros para que se pueda cumplir el fair play.

Dejo el resto para los que quieran seguir evocando este modelo (con referencias al amor mutuo, a la eucaristía, a la red de contactos universales, a la fe….). Buen día, buen trabajo. Ofrezco además un breve excurso, con una parte seleccionada del antiguo trabajo de Raymond.

Eric S. Raymond La catedral y el bazar (un estracto)
http://biblioweb.sindominio.net/telematica/catedral.html

1 La Catedral y el Bazar
Linux es subversivo. ¿Quién hubiera pensado hace apenas cinco años que un sistema operativo de talla mundial surgiría, como por arte de magia, gracias a la actividad hacker desplegada en ratos libres por varios miles de programadores diseminados en todo el planeta, conectados solamente por los tenues hilos de la Internet?
Lo que es seguro es que yo no. Cuando Linux apareció en mi camino, a principios de 1993, yo tenía invertidos en UNIX y el desarrollo de software libre alrededor de diez años. Fui uno de los primeros en contribuir con GNU a mediados de los ochentas y he estado aportando una buena cantidad de software libre a la red, desarrollando o colaborando en varios programas (NetHack, los modos VC y GUD de Emacs, xlife y otros) que todavía son ampliamente usados. Creí que sabía cómo debían hacerse las cosas.
Linux vino a trastocar buena parte de lo que pensaba que sabía. Había estado predicando durante años el evangelio UNIX de las herramientas pequeñas, de la creación rápida de prototipos y de la programación evolutiva. Pero también creía que existía una determinada complejidad crítica, por encima de la cual se requería un enfoque más planeado y centralizado. Yo pensaba que el software de mayor envergadura (sistemas operativos y herramientas realmente grandes, tales como Emacs) requería construirse como las catedrales, es decir, que debía ser cuidadosamente elaborado por genios o pequeñas bandas de magos trabajando encerrados a piedra y lodo, sin liberar versiones beta antes de tiempo.
El estilo de desarrollo de Linus Torvalds ("libere rápido y a menudo, delegue todo lo que pueda, sea abierto hasta el punto de la promiscuidad") me cayó de sorpresa. No se trataba de ninguna forma reverente de construir la catedral. Al contrario, la comunidad Linux se asemejaba más a un bullicioso bazar de Babel, colmado de individuos con propósitos y enfoques dispares (fielmente representados por los repositorios de archivos de Linux, que pueden aceptar aportaciones de quien sea), de donde surgiría un sistema estable y coherente únicamente a partir de una serie de artilugios.
El hecho de que este estilo de bazar parecía funcionar, y funcionar bien, realmente me dejó sorprendido. A medida que iba aprendiendo a moverme en ese medio, no sólo trabajé arduamente en proyectos individuales, sino en tratar de comprender por qué el mundo Linux no naufragaba en el mar de la confusión, sino que se fortalecía con una rapidez inimaginable para los constructores de catedrales.
Creí empezar a comprender a mediados de 1996. El destino me dio un medio perfecto para demostrar mi teoría, en la forma de un proyecto de software libre que trataría de realizar siguiendo el estilo del bazar de manera consciente. Así lo hice y resultó un éxito digno de consideración.
En el resto de este artículo relataré la historia de este proyecto, y la usaré para proponer algunos aforismos sobre el desarrollo real del software libre. No todas estas cosas fueron aprendidas del mundo Linux, pero veremos cómo fue que les vino otorgar un sentido particular. Si estoy en lo cierto, le servirán para comprender mejor qué es lo que hace a la comunidad linuxera tan buena
1. Todo buen trabajo de software comienza a partir de las necesidades personales del programador. (Todo buen trabajo empieza cuando uno tiene que rascarse su propia comezón)
Esto podría sonar muy obvio: el viejo proverbio dice que "la necesidad es la madre de todos los inventos". Empero, hay muchos programadores de software que gastan sus días, a cambio de un salario, en programas que ni necesitan ni quieren. No ocurre lo mismo en el mundo Linux; lo que sirve para explicar por qué se da una calidad promedio de software tan alta en esa comunidad.
2. Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).
Aunque no presumo ser un extraordinario programador, he tratado siempre de imitar a uno de ellos. Una importante característica de los grandes programadores es la meticulosidad con la que construyen. Saben que les pondrán diez no por el esfuerzo, sino por los resultados; y que casi siempre será más fácil partir de una buena solución parcial que de cero.
Linus, por ejemplo, no intentó escribir Linux partiendo de cero. En vez de eso, comenzó por reutilizar el código y las ideas de Minix, un pequeño sistema operativo (OS) tipo UNIX hecho para máquinas 386. Eventualmente terminó desechando o reescribiendo todo el código del Minix, pero mientras contó con él le sirvió como una importante plataforma de lanzamiento del proyecto en gestación que posteriormente se convertiría en Linux.
Con ese espíritu, comencé a buscar una herramienta POP que estuviese razonablemente escrita para ser usada como plataforma inicial para mi desarrollo.
La tradición del mundo UNIX de compartir las fuentes siempre se ha prestado a la reutilización del código (ésta es la razón por la que el proyecto GNU escogió a UNIX como su OS base, pese a las serias reservas que se tenían). El mundo Linux ha asumido esta tradición hasta llevarla muy cerca de su límite tecnológico; posee terabytes de código fuente que están generalmente disponibles. Así que es más probable que la búsqueda de algo bueno tenga mayores probabilidades de éxito en el mundo Linux que en ningún otro lado.

5. Cuando se pierde el interés en un programa, el último deber es heredarlo a un sucesor competente.
Sin siquiera discutirlo, Carl y yo sabíamos que el objetivo común era obtener la mejor solución. La única duda entre nosotros era si yo podía probar que el proyecto iba a quedar en buenas manos. Una vez que lo hice, él actuó de buena gana y con diligencia. Espero comportarme igual cuando llegue mi turno.
3 La importancia de contar con usuarios
Así fue como heredé popclient. Además, recibí su base de usuarios, lo cual fue tan o más importante. Tener usuarios es maravilloso. No sólo porque prueban que uno está satisfaciendo una necesidad, que ha hecho algo bien, sino porque, cultivados adecuadamente, pueden convertirse en magníficos asistentes.
Otro aspecto importante de la tradición UNIX, que Linux, de nuevo, lleva al límite, es que muchos de los usuarios son también hackers, y, al estar disponible el código fuente, se vuelven hackers muy efectivos. Esto puede resultar tremendamente útil para reducir el tiempo de depuración de los programas. Copn un buen estímulo, los usuarios diagnosticarán problemas, sugerirán correcciones y ayudarán a mejor los programas mucho más rápido de lo que uno lo haría sin ayuda.
6. Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.
Suele ser fácil subestimar el poder de este efecto. De hecho, es posible que todos continuásemos desestimando la capacidad multiplicadora que adquiriría con el número de usuarios y en contra de la complejidad de los sistemas, hasta que así nos lo vino a demostrar Linus.
En realidad, considero que la genialidad de Linus no radica en la construcción misma del kernel de Linux, sino en la invención del modelo de desarrollo de Linux. Cuando en una ocasión expresé esta opinión delante de él, sonrió y repitió quedito una frase que ha dicho muchas veces: "Básicamente soy una persona muy floja que le gusta obtener el crédito por lo que, realmente, hacen" los demás. Flojo como una zorra. O, como diría Robert Heinlein, demasiado flojo para fallar.
4 Libere rápido y a menudo
Las publicaciones rápidas y frecuentes del código constituyen una parte crítica del modelo Linux de desarrollo. La mayoría de los programadores, en los que me incluyo, creía antes que era una mala política involucrarse en proyectos más grandes triviales, debido a que las primeras versiones, casi por definición, salen plagadas de errores, y a nadie le gusta agotar la paciencia de serias y no tuve éxito.
Pero un año después, a medida que Linux se agigantaba, quedo claro que estaba pasando algo distinto y mucho más sano. La política abierta de desarrollo de Linus era lo más opuesto a la construcción estilo catedral. Los repositorios de archivos en sunsite y tsx-11 mostraban una intensa actividad y muchas distribuciones de Linux circulaban. Y todo esto se manejaba con una frecuencia en la publicación de programas que no tenía precedentes.
Linus estaba tratando a sus usuarios como colaboradores de la forma más efectiva posible:

Mi formulación original rezaba que todo problema deberá ser transparente para alguien. Linus descubrió que la personas que entendían y la que resolvían un problema no eran necesariamente las mismas, ni siquiera en la mayoría de los casos. Decía que "alguien encuentra el problema y otro lo resuelve". Pero el punto está en que ambas cosas suelen suceder con gran rapidez.
Aquí, pienso, subyace una diferencia esencial entre el estilo del bazar y el de la catedral.
En el enfoque estilo catedral de la programación, los errores y problemas de desarrollo son fenómenos truculentos, insidiosos y profundos. Generalmente toma meses de revisión exhaustiva para unos cuantos el alcanzar la seguridad de que han sido eliminados del todo. Por eso se dan los intervalos tan largos entre cada versión que se libera, y la inevitable desmoralización cuando estas versiones, largamente esperadas, no resultan perfectas.

En el enfoque de programación estilo bazar, por otro lado, se asume que los errores son fenómenos relativamente evidentes o, por lo menos, que pueden volverse relativamente evidentes cuando se exhiben a miles de entusiastas desarrolladores asistentes que colaboran al parejo sobre cada una de las versiones. En consecuencia, se libera con frecuencia para poder obtener una mayor cantidad de correcciones, logrando como efecto colateral benéfico el perder menos cuando un eventual obstáculo se atraviesa.

5, 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.

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