ATRAS
SIGUIENTE
INDICE

6. Eric Steven Raymond.

Introducción

Eric Raymond, es una especie de filósofo del mundo del Software Libre. Aunque no solo es famoso por sus escritos, ya que varios paquetes de software de su autoría forman parte de las distribuciones de GNU/Linux.

Entre sus aportes se puede destacar:


  • Emacs VC (Version Control) Un Front End para CVS, o sea control de versiones.

  • Fetchmail: una solución para la obtención de correo para máquinas UNIX, especialmente para aquellos con conexión intermitente al servidor de correo (PPP, SLIP). Recupera los mensajes usando alguna variante de POP o de IMAP.

  • Participó del desarrollo de las bibliotecas ncurses .

Eric Steven Raymond

Se precia de ser uno de los primeros voluntarios en sumarse al proyecto GNU de Stallman ( a mediados de la década del 80). Y aunque luego fue uno de los creadores del movimiento Open Source, asegura que continúan siendo amigos con Stallman.

A los efectos de estudiar el movimiento del software libre, es esencial tener en cuenta los escritos publicados por Raymond. Consiguió resumir de forma magistral el fenómeno y crear un mito en su artículo "La catedral y el bazar". Trató de destacar las diferencias entre varios campos del mundo de código fuente abierto. Se dio cuenta de que los que lideraban proyectos de código libre tenían distintas formas de compartir y quería explicar cuál de todas es la que mejor funciona.

La Catedral y el Bazar - Ver Documento Completo -

Este famoso escrito fue presentado por Raymond en mayo de 1997, en un congreso sobre GNU/Linux en Bavaria. En el mismo se encarga de analizar el modelo de desarrollo creado y utilizado por Linus Torvalds para su proyecto Linux30. El hacker dice que este modelo cambió su forma de pensar. Mucha gente dentro del mundo del software cree que hay un cierto nivel de complejidad a partir del cual es recomendable un desarrollo centralizado. Linus Torvalds demostró que estaban equivocados al desarrollar una pieza de software tan crítica como es el núcleo de un sistema operativo, de una manera abierta y completamente descentralizada.

Para explicar este fenómeno emplea una metáfora bien descriptiva. Sugiere que el mundo del Software Libre es como un bazar con muchos comerciantes diferentes que ofrecen sus mercancías. El desarrollo empresarial, por el contrario, esta estructurado como los sindicatos religiosos que construyeron las catedrales medievales.

Los bazares ofrecen mucha competencia, pero sin orden alguno. Las catedrales estaban sometidas a la dirección de jerarquías sacerdotales, que aprovechaban la riqueza de la ciudad para construir el proyecto de un solo arquitecto.

Las diferencias entre ambos son evidentes. El equipo de la catedral puede producir una obra de arte si el arquitecto tiene talento, los encargados de la financiación tienen éxito y la dirección consigue que todo el mundo se concentre en su trabajo. El bazar, por otra parte, consiste en muchos mercaderes pequeños que tratan de competir unos con otros. Los mejores se quedan con los mejores clientes, y los otros pronto acaban sin trabajo.

Aunque parezca que la comparación apunta a separar el desarrollo comercial/cerrado del mundo Open Source, Raymond señala que la FSF es como la catedral del Software Libre. Obviamente con esto no quiere decir que la FSF sea lo mismo que Microsoft, pero sí que su modelo de desarrollo es por lo general centralizado.

A lo largo del escrito, Raymond redacta su experiencia personal durante el desarrollo de fetchmail. Expresa de manera clara y explicativa, cómo fue que se decidió a aplicar un modelo similar al utilizado en el proyecto Linux para llevar adelante su propio desafío. A medida que avanza en detalles va definiendo algunos axiomas que son interesantes de discutir.

- Toda buena pieza de software empieza por una motivación personal de un programador31.

Esta regla es bastante controversial. Sin dudas, muchos de los proyectos surgen de la necesidad de una persona o de un grupo de personas, pero no siempre es así. De hecho, si fuera de esta manera sería imposible poder contar con un sistema operativo completo de la talla de GNU/Linux. Se necesitan muchísimas herramientas, las cuales fueron en su gran mayoría desarrolladas por voluntarios de la FSF. Entonces, hay muchas aplicaciones que fueron escritas por el simple hecho de una necesidad. Para citar un ejemplo simple: la utilidad tar. Tar se encarga de armar un solo archivo a partir de dos o más. No se puede suponer que sea el interés de nadie, programar dicha utilidad. Pero para poseer un sistema tipo UNIX completo se debe contar con una aplicación de este tipo.

Como este ejemplo hay cientos, ya que los sistemas tipo UNIX se caracterizan por la cantidad de aplicaciones que poseen. Entonces, aunque puede ser verdad que en muchos casos los proyectos nacen de motivaciones particulares, no es correcto definirlo como un axioma.

- Cuando perdés el interés en un programa, tu última obligación es entregarle el mando a un sucesor competente.

Esta sí es una máxima dentro del mundo de los proyectos Open Source. Es muy importante que el líder esté completamente dedicado al proyecto y que demuestre que los esfuerzos de los voluntarios son tenidos en cuenta. En el caso que al líder deje de interesarle el proyecto, ya sea porque alcanzó una madurez razonable o porque realmente no puede dedicarle todo el tiempo necesario, el mismo debe delegar esta responsabilidad en alguna otra persona del proyecto. Esto es necesario para que el proyecto no entre en un pozo. Además, siempre debe evitarse que por culpa de un líder que no cumple con sus responsabilidades, el proyecto sufra una bifurcación32. Siempre se busca evitar las bifurcaciones porque implican dos grupos distintos haciendo la misma tarea.

- Tratar a los usuarios como codesarrolladores es la mejor ruta para una rápida mejora del código y un debugging efectivo.

Esta es una de las lecciones aprendidas por Raymond del modelo de Linus, que aplicó a su propio proyecto de fetchmail. Esto se basa en una fortaleza de la tradición UNIX, que Linux también heredó, y es que muchos de sus usuarios son hackers. Dado que el código fuente está disponible, pueden ser hackers efectivos. Esto puede ser muy útil para reducir los tiempos de debugging. Si se los incentiva, los usuarios diagnostican problemas, sugieren correcciones, y ayudan a mejorar el código de una manera mucho más rápida que si el creador lo hiciera solo.

Este axioma se complementa con el siguiente, que apunta al mismo concepto y que Raymond lo definió como la ley de Linus.

- Ley de Linus: Dado el suficiente número de globos oculares, todos los errores son triviales.

Todo proyecto de Software Libre, tiene como plataforma a Internet. Esto permite que los voluntarios que conforman los grupos sean de diferentes partes del mundo. Las comunidades virtuales que se forman en torno a un proyecto, no podrían existir sin Internet como medio de comunicación.

La red no solo brinda el espacio de comunicación entre desarrolladores, sino que también es un excelente medio de publicidad. Hay sitios que se dedican a auspiciar estos proyectos (SourceForge, Freshmeat, etc). A través de ellos, los proyectos pueden darse a conocer al mundo. De esta forma comienzan a captar usuarios que son posibles codesarrolladores. Dada la masividad de Internet, es muy grande la posibilidad de que un proyecto que persigue objetivos interesantes; logre captar la atención de muchos hackers alrededor del mundo.

A medida que el proyecto comienza a lograr fama y suma adeptos, más y más gente comienza a interesarse en él. A partir de ahí comenzarán a aparecer distintos tipos de usuarios. Por un lado aquellos que simplemente utilizan el software porque les es de utilidad, y solo necesitan que el mismo cumpla con sus funciones. A su vez, serán quienes al utilizarlo de manera frecuente comiencen a encontrar errores. Si están bien entrenados, los reportarán. Otros, comenzarán a manipular el código fuente del software con lo que, aportarán sus opiniones y corregirán los bugs detectados. Todo esto puede suceder a una velocidad asombrosa.

La ley de Linus declara que al crecer la cantidad de gente que utilice el software y que lo inspeccione, cualquier problema que aparezca va a resultar trivial. Dado el gran número de voluntarios, las actividades se solapan y no son realizadas por la misma persona. Por eso, seguramente no será el mismo usuario que detecte un bug, que el que lo solucione.

Todo esto nos lleva a obtener como conclusión, que para los proyectos de este tipo los usuarios son el recurso más importante con que se cuenta. El usuario, no es meramente aquel que paga una determinada cantidad de dinero por la licencia de uso de un programa. Sino que sus opiniones y aportes son muy importantes y ayudan al progreso del proyecto. Sin dudas que esta es la mayor diferencia que se puede encontrar a la hora de comparar el modelo de desarrollo tipo Bazar, frente al modelo de la Catedral donde todo es muy cerrado.

- Publicar pronto y frecuentemente, delegar todo lo que puedas, estar abierto hasta el punto de la promiscuidad.

Esta es una parte crítica del modelo de desarrollo de Linux. Muchos desarrolladores creían que no era una práctica para proyectos grandes, porque las versiones tempranas están llenas de errorres y no se quiere agotar la paciencia de los usuarios.

La creencia de los modelos tipo catedral, es que al usuario deben llegarle la menor cantidad posible de errores. Para lograr eso, las versiones están separadas por largos lapsos de tiempo. Raymond dice lo siguiente:

'Según la idea de programación del constructor de catedrales, los errores y problemas de desarrollo son fenómenos taimados, insidiosos, profundos. Cuesta meses de escrutinio por parte de unos cuantos, muy dedicados, desentrañarlos por completo. De ahí los largos intervalos entre versiones, y la inevitable decepción cuando las entregas esperadas desde hace largo tiempo no son perfectas.

Por el contrario, según la visión del bazar, uno asume que los fallos son, habitualmente, fenómenos superficiales, o al menos que se pueden minimizar rápidamente, cuando se exponen a miles de ansiosos codesarrolladores que machacan incesantemente cada nueva versión. Por lo tanto, uno saca más versiones para poder realizar más correcciones y, como efecto colateral benéfico, tiene menos que perder si se cuela algun problema ocasional'.

Esto no implica que solamente se deban publicar versiones a menudo para satisfacer a los ansiosos Hackers. En general, lo que se realiza es una división del proyecto en dos ramas, la estable y la de desarrollo. Por un lado, los usuarios comunes pueden descargarse la última versión estable del programa, la cual les asegura un funcionamiento aceptable. La otra rama, es la que cuenta con las últimas modificaciones y sobre la que se efectúan las pruebas para incorporar nuevas funcionalidades al software. Este método permite que los dos tipos de usurarios puedan satisfacer sus necesidades.

Netscape y el Bazar

El 22 de enero de 1998, aproximadamente siete meses después de la primera edición de este escrito, Netscape Communications Inc, anunció sus planes de publicar el código fuente de su browser Netscape Navigator.

El vicepresidente ejecutivo de la firma le comunicó a Raymond: 'En representación de todos en la empresa, queremos agradecerte por ayudarnos a llegar a este punto. Tus pensamientos y tus escritos fueron la inspiración fundamental de esta decisión'.

Los resultados no fueron tan buenos como esperaban, pero Netscape pudo frenar la expansión monopólica de Microsoft y su Internet Explorer. Surgieron varios inconvenientes durante los primeros meses de vida del proyecto Mozilla. Tampoco puede indicarse que haya sido un fracaso. El problema principal es que Netscape no se atuvo a los principios básicos del modelo bazar. Por ejemplo, se tardó mucho tiempo en lanzar una versión que pudiera ejecutarse sin problemas. Parte de este inconveniente tuvo que ver con asuntos legales por el uso de las bibliotecas no libres motif. También se registraron dificultades en el seno de la conducción del proyecto, lo que desembocó en renuncias y pérdida de confianza por parte del público testigo de todo esto.

Hoy en día, el navegador Mozilla forma parte de la mayoría de las distribuciones de GNU/Linux. Ha alcanzado un nivel, más que satisfactorio de performance, pero no logró llegar al punto de ser un asesino de categoría33.

Los Documentos Halloween - Ver Los Documentos Completos -

El día 30 de Octubre de 1998, llegó a las manos de Eric Raymond un memorandum confidencial que parecía proceder de Microsoft. En él se analizaba el modelo Open Source y se estudiaban las implicancias del mismo en comparación con el modelo de negocios de la empresa de Bill Gates.

Raymond, ni lerdo ni perezoso, publicó el reporte titulándolo "Halloween Document" (en alusión a la fecha en que conoció la existencia del mismo). Este hecho recibió una fuerte cobertura de los medios, especialmente en Estados Unidos y Europa. Microsoft, se vio obligada a reconocer la autenticidad del mismo. Unos días después apareció un segundo documento "Halloween Document II", que hacía referencia específicamente al sistema operativo GNU/Linux.

Los documentos Halloween fueron como dinamita. Se convirtieron en el testimonio de las fortalezas del modelo Open Source, visto desde la companía que más perdió por el éxito de GNU/Linux. A su vez, sirvieron para confirmar muchas de las sospechas sobre las tácticas que emplearía Microsoft para detenerlos. Desde la empresa intentaron restarle importancia al hecho, y calificaron al informe como un estudio de ingeniería, que no reflejaba las políticas de Microsoft.

A continuación se detallarán los puntos más importantes de estos documentos, que sirven para entender como intentará una de las empresas más importantes de desarrollo comercial / cerrado, derrotar al incipiente Open Source.

En el comienzo, describe las principales características del Open Source. El autor declara que los proyectos de este tipo, han alcanzado calidad comercial. Como primer alarma indica que muchos casos de estudio que se han presentado en Internet, dan evidencia al resto de la gente (potenciales clientes de Microsoft) que los proyectos Open Source han logrado grandes resultados.

A lo largo del memorandum, el autor se encarga de destacar las personalidades más influyentes:

- Richard Stallman, por ser el creador de la concepción moderna de Software libre y por su proyecto GNU.

- Linus Torvalds, por ser el creador de Linux. Se lo identifica como un líder carismático.

- Eric Raymond. Es el más citado dentro de todo el documento. Se analizan sus escritos para describir el pensamiento y la forma de actuar de los hackers que integran el movimiento.

Como uno de los hechos más particulares e importantes, se destaca que la motivación principal de la mayoría de los proyectos no es monetaria. Indica que por lo general no hay una empresa detrás de los mismos, por lo que Microsoft debería apuntar al proceso en sí mismo y no a una empresa determinada.

Se puede concluir que es acertado el enfoque propuesto por el autor. A pesar de que hay varias empresas detrás del movimiento (las más conocidas son las que se encargan de armar las distribuciones del sistema GNU/Linux como SuSE o Red Hat), estas no son la principal amenaza contra Microsoft. Lo más importante es ver si está en condiciones el modelo que defiende (cerrado/comercial) de competir frente al abierto y libre del Open Source. Esta es la razón por la cual es acertado indicar que el proceso es el que atenta contra los objetivos de Microsoft y no alguna empresa en particular.

También se reconoce la fuerte penetración que ha tenido el modelo en el ámbito universitario / académico. Se detalla que es un campo muy importante ya que se producen muchas investigaciones y desarrollos nuevos que se implementan antes en GNU/Linux, que en la plataforma Microsoft.

Como punto más importante y preocupante, el autor plantea que GNU/Linux puede ganar la batalla solo si los servicios y protocolos siguen siendo commodities. Es una afirmación bastante fuerte, que da muestras claras de lo que ha sido la historia de los desarrollos de Microsoft: cerrado y oculto. Al sugerir que los protocolos deben dejar de ser un commodity, el autor está expresando que la mejor manera de ganar es creando protocolos propietarios y no compatibles con los demás, que no permitan la libertad de elección a los usuarios. Aunque desde Microsoft se planteó que este escrito no representaba sus políticas, da bastante escalofrío suponer que la empresa tiene en sus horizontes, por ejemplo, lanzar su propio protocolo tcp/ip o su propia versión del HTTP.

Estos documentos34 son muy importantes y permitieron dar a conocer la opinión de uno de los exponentes principales del modelo que se contrapone al del Software Libre. A su vez, Raymond escribió en estos últimos años varios ensayos más en los que continuó analizando el mundo del Software Libre y del Open Source.

Entre ellos se destacan:

Un análisis más detallado de estos escritos escapan al alcance de este trabajo. Se los nombra simplemente para dar una idea clara de la cantidad de ensayos y escritos que ha publicado Raymond, de ahí que se lo considere como el filósofo del Software Libre.

Consideraciones Finales

No hay duda alguna que Raymond es otra de las personalidades influyentes dentro del software libre. Varias razones son las que justifican esta afirmación.

Sus aportes contribuyeron a fortalecer varios ámbitos del movimiento. Por un lado, su temprana participación en el proyecto GNU y principalmente en el desarrollo de GNU EMACS. Otro de sus valiosos aportes fue la aplicación Fetchmail, que es muy respetada y utilizada. Por el otro lado, sus escritos han sido muy importantes a la hora de explicar el fenómeno del software libre y permitieron dar a conocer por parte de un integrante de la comunidad hacker cuáles eran los objetivos perseguidos por ellos.

Por último, para continuar enumerando sus aportes, puede marcarse su posición destacada en el grupo que lidera el movimiento Open Source. Es de importancia remarcar que su postura, no ha sido tan radical y confrontativa, como la de Stallman. Actitudes como la suya, fueron las que contribuyeron a que hoy en día se conozca más al Open Source que al software libre.

Todas estas razones permiten determinar que se está frente a otra de las personalidades que han dedicado gran parte de su vida, al esfuerzo de lograr que este modelo prevalezca frente al cerrado y propietario.



30Aquí se refiere solamente al kernel, que es el proyecto de Torvalds.

31El término utilizado era scratching a developer's itch, refiriéndose a que el programdor se rasca lo que le pica. Una metáfora para justificar que el programador ataca solo sus motivaciones personales.

32En la jerga se lo denomina fork. Fork es una de las llamadas al sistema en Unix. La misma sirve para crear procesos hijos, para lo cual el proceso padre se duplica y de ese proceso duplicado nace el hijo. Es una metáfora para describir las divisiones que pueden producirse en un proyecto que terminan dando origen a dos proyectos (el actual, más el nuevo).

33Asesino de categoría: Así se denomina a las aplicaciones que han capturado un nicho específico. Sería muy difícil para otra aplicación capturar la atención del público. Se dice que GNU/Linux es un asesino de categoria en cuanto a los Sistemas Operativos de código fuente abierto.

34Los documentos originales pueden encontrarse en la página de la Iniciativa Open Source: www.opensource.org.


ATRAS
SIGUIENTE
INDICE