Software Abierto

Una Metodología (¿Nueva?) de Desarrollo

{ El cuerpo del documento de Halloween es un memorándum interno de estrategia sobre las posibles respuestas de Microsoft al fenómeno de Linux/Software Abierto. Este documento tiene un fuerte olor a la cultura corporativa única de Microsoft (como lo afirman fuentes independientes tales como The Borg) para ser menos que genuina.

La lista de colaboradores mencionada al final del documento incluye algunas personas que son conocidas como personajes clave dentro de Microsoft, y pareciera que el documento es un esfuerzo de investigación que tuvo la cooperación de los ejecutivos (el autor parecía esperar que Gates lo leyera).

Como consecuencia de esto, este artículo nos proporciona con una muestra muy valiosa del cambio del desdén con que Microsoft veía al Software Abierto a lo que actualmente está pensando la compañía -- lo cual, como lo verán ustedes, es una rara combinación de astucia y miopía institucional.

Debido a que el autor citó mis análisis sobre la dinámica de la comunidad del software abierto (La Catedral y el Bazar) y (Cuidando la Noósfera) ampliamente, me parece justo que responda por parte de la comunidad. :-)

A continuación están algunas citas notables de los documentos, con ligas a las partes en las que están colocadas. Es de ayuda el saber que "OSS" es la abreviatura del autor de "Software de Fuente Abierta".

* El OSS representa una amenaza directa, a corto plazo al ingreso y al dominio de la plataforma a Microsoft, especialmente en el ámbito de los servidores. Además, el paralelismo intrínseco, y el libre intercambio de ideas dentro del OSS tiene beneficios que no puede reproducir nuestro actual modelo de licenciamiento, y por tanto, representan una amenaza hacia el intercambio de ideas entre los desarrolladores.

* Estudios recientes de casos (el Internet) proporcionan evidencia muy dramática ... de que la calidad comercial puede lograrse/superarse por parte de los proyectos de OSS.

* ... para comprender cómo competir en contra del OSS, debemos dirigirnos en contra de un proceso, en vez de una compañía.

* El OSS tiene una credibilidad a largo plazo... por lo que las tácticas FUD no pueden ser empleadas para combatirlo.

* Linux y otros entusiastas del OSS están haciendo cada vez más creíble el planteamiento de que el software OSS es al menos tan robusto "C, si no es que más "C que las alternativas comerciales. El Internet proporciona el escaparate ideal, de gran visibilidad para el mundo OSS.

* Linux ha sido empleado en ambientes comerciales, de misiones críticas con excelentes resultados y testimonios públicos. ... Linux tiene un mejor desempeño que muchos otros UNIXes ... Linux está sobre el camino de ser eventualmente dueño del mercado UNIX de las x86 ...

* Linux puede ganar mientras los servicios/protocolos sean mercancías sujetas a la venta.

* Los proyectos OSS han sido capaces de ganarse un punto de arranque en muchas aplicaciones de servidores debido a la amplia utilización de protocolos sencillos y personalizados. Al extender estos protocolos y desarrollar nuevos protocolos, podemos evitar la entrada de los proyectos OSS al mercado.

* La capacidad del proceso OSS para reunir y forjar un coeficiente intelectual colectivo de millares de individuos a través de Internet es simplemente sorprendente. Es más, la evangelización del OSS crece proporcionalmente mucho más rápido con el Internet de lo que nuestros propios esfuerzos de evangelización parecen crecer.

Los comentarios en verde, rodeados por llaves, son míos (Eric S. Raymond). He resaltado lo que creo como clave en el texto original con rojo. He insertado comentarios cerca de estos puntos clave; usted puede leer el documento navegando a través del índice de comentarios en secuencia.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

He insertado algunos otros comentarios en verde que no están asociados con los puntos claves y que no están dentro del índice. Estos comentarios adicionales son de interés solamente si usted está leyendo todo el documento.

Fuera de esto, he dejado el documento tal cual es, de manera tal que lo que usted está leyendo es lo que Bill Gates lee sobre el Software Abierto. Este documento es algo largo, pero el que persevera alcanza. Una reparación adecuada del pensamiento de la oposición es algo que significa algo de esfuerzo, pero lo vale -- y existen dos o tres cuestiones que realmente valen la pena en este discurso de ejecutivos.

Esta versión anotada del memorándum VinodV fue preparada durante el fin de semana del 31 de Octubre al 1 de Noviembre de 1998. Para conmemorar esta fecha, y debido a la esperanza de que el publicar este documento ayude a realizar una de las peores pesadillas de Microsoft, llamé a este documento el "Documento de Halloween".

Cópielo ahorita mismo; Microsoft podría entablar un juicio para borrar esto. }
 

 

Tabla de Contenido

Tabla de Contenido *

Resumen Ejecutivo *

Software Abierto *

              ¿Qué es eso? *

            Taxonomía de Licenciamiento del Software *

            El Software Abierto es Importante para Microsoft *

            Historia *

Proceso del Software Abierto *

            Equipos de Desarrollo del Software Abierto *

            Coordinación del Desarrollo en el OSS *

            Desarrollo en Paralelo *

            Depuración en Paralelo *

            Solución de Conflictos

            Motivación *

            Reparto del Código *

Fortalezas del Software Abierto *

            Atributos Exponenciales del OSS *

            Credibilidad a largo plazo *

            Depuración en Paralelo *

            Desarrollo en Paralelo *

            OSS = Perfecto! documentación/Evangelización *

            Ritmo de Publicación *

Debilidades del Software Abierto *

            Costos de Mantenimiento *

            Cuestiones sobre el Proceso *

            Credibilidad Organizativa *

Modelos de Negocios del Software Abierto *

            Servicios Secundarios *

            Falta de Liderazgo -- Entrada al Mercado *

            Comercialización de los Proveedores *

            Primero construcción, -- luego $$$ *

Linux *

 Qué es eso? *

            Linux es un proceso de Desarrollo + SO real y creíble *

            Linux es una amenaza a corto/mediano plazo en el ámbito de los servidores *

            No es probable que Linux sea una amenaza en el escritorio *

            Cómo derrotar a Linux *

Netscape *

            Organización y Licenciamiento *

            Fortalezas *

            Debilidades *

            Predicciones *

Apache *

            Historia *

            Organización *

            Fortalezas *

            Debilidades *

            IBM y Apache *

Otros proyectos OSS *

Respuesta de Microsoft *

            Vulnerabilidades de los Productos *

            Cómo capturar los beneficios del OSS -- Intercambio de Ideas entre los Desarrolladores *

            Cómo capturar los beneficios del OSS para los Procesos Internos de Microsoft *

            Extendiendo los beneficios del OSS -- Infraestructura de Servicio *

            Mediatizar los ataques del OSS *

Otras Ligas Interesantes *

Reconocimientos *

Historia de las Revisiones *
 
 
 

Resumen Ejecutivo

El Software (OSS) es un proceso de desarrollo que estimula la rápida creación e implentación de aspectos que aumentan la capacidad del software y depuran el código/base de conocimiento. En años recientes, como respuesta al crecimiento de Internet, los proyectos de OSS han adquirido una complejidad y profundidad tradicionalmente asociados con proyectos comerciales, tales como Sistemas Operativos y servidores de misiones críticas.

El OSS representa una amenaza directa, a corto plazo al ingreso y al dominio de la plataforma a Microsoft, especialmente en el ámbito de los servidores. Además, el paralelismo intrínseco, y el libre intercambio de ideas dentro del OSS tiene beneficios que no puede reproducir nuestro actual modelo de licenciamiento, y por tanto, representan una amenaza hacia el intercambio de ideas entre los desarrolladores.

{ OK, esto muestra que Microsoft no se ha dormido durante el cambio. }

Sin embargo, otras debilidades del proceso OSS proporcionan un camino para que Microsoft pueda tener una ventaja en áreas clave tal como mejoras de arquitectura (e.g. almacenamiento), integración (e.g. esquemas), facilidad de uso y apoyo organizativo.

{ Esta recomendación es de sumo interés, ya que no alcanza a cubrir las recomendaciones posteriores que se realizan en el documento acerca de la descomercialización de los protocolos, etc. }

Software Abierto

¿Qué es eso?

El Software Abierto (OSS) es software cuya fuente y binarios son distribuidos, o están disponibles para un producto dado, generalmente de manera gratuita. Es común que no se distinga la diferencia entre shareware o freeware y OSS, pero existen varias diferencias significativas entre los modelos de licenciamiento y el proceso en el cual se desenvuelve cada producto

Taxonomía del Licenciamiento de Software

Estas características amplias de licenciamiento incluyen:
 

Software Comercial

• Software de Prueba

• Shareware

• Software de Uso No Comercial

• Binarios Gratuitos

• Librerías Gratuitas

• Fuente Abierta (Estilo BSD)

• Fuente Abierta (Estilo Apache)

• Fuente Abierta (Estilo GNU/Linux)

Estudios recientes de casos (el Internet) proporcionan evidencia muy dramática ... de que la calidad comercial puede lograrse/superarse por parte de los proyectos de OSS. Sin embargo, en este momento no existe evidencia contundente de la calidad del código OSS además de la anecdótica.

{ Estos enunciados, tomados juntos, son algo contradictorios a menos que "los estudios recientes" son todos "anecdóticos". Pero si fuese así, entonces porqué lo llama "evidencia muy dramática"?

Parece ser que hay involucrado algo de autorrespaldo y autosuficiencia en la segunda oración. Sin embargo, la primera oración es una enorme concesión para  Microsoft (así sea de manera interna). }

3. El OSS tiene un proceso de desarrollo único, con fortalezas y debilidades únicas

El proceso OSS es único en cuanto a sus participantes, ya que se puede proporcionar las motivaciones y los recursos para abordar los problemas. Por lo tanto, el OSS tiene algunas características no reproducibles que deben ser comprendidos cabalmente.

Historia

El software abierto tiene sus orígenes en la comunidad científica y de aficionados y estaba caracterizado por intercambio ad hoc de código fuente entre los desarrolladores/usuarios.

Software de Internet

El estudio de casos más grande del OSS es el Internet. La mayor parte del código originario del Internet estaba, y aún está basado sobre OSS, como lo describió en una entrevista Tim O'Reilly (http://www.techweb.com/internet/profile/toreilly/interview):

TIM O'REILLY: El principal mensaje con el que iniciamos era "que el software abierto funciona". BIND tiene el papel absolutamente dominante del mercado como la pieza de misión crítica de software del Internet. Apache es el servidor de Web dominante. El SendMail probablemente corre en el 80 % de los servidores de correo y probablemente toca cada una de las piezas de correo electrónico sobre el Internet.

Free Software Foundation/Proyecto GNU

El crédito de la primera muestra de OSS moderno organizado se le otorga generalmente a Richard Stallman del MIT. A finales de 1983, Stallman creó la Free Software Foundation (FSF) (Fundación de Software Gratuito) -- http://www.gnu.ai.mit.edu/fsf/fsf.html -- con el objetivo de crear una versión gratuita del sistema operativo UNIX. La FSF publicó una serie de fuentes y binarios dentro del marco del GNU (que significa recursivamente "GNU no es UNIX).

Las iniciativas originales de FSF/GNU se quedaron cortas en su objetivo original de la creación de un UNIX completamente OSS. Sin embargo, si contribuyeron a varias aplicaciones y herramientas de programación famosas y muy difundidas que se utilizan actualmente, entre las que están:

GNU Emacs -- Originalmente era un poderoso editor de texto en modo texto, pero con el tiempo, se mejoró a Emacs al proporcionarle un front-end para compiladores, lectores de correo electrónico, etc.

• GNU C Compiler (GCC) -- El GCC es el compilador más ampliamente utilizado en el mundo del OSS y de la academia. Además del compilador, está disponible un conjunto bastante estandarizado de librerías intermedias como complemento de las librerías del ANSI C.

• GNU GhostScript -- Un visualizador impresor de PostScript.

Licenciamiento CopyLeft

El software FSF/GNU introdujo el esquema de licenciamiento copyleft, que no sólo hacía ilegal el ocultar el código fuente del software GNU, sino también hacía ilegal ocultar el código fuente del trabajo derivado del software GNU. El documento que describe esta licencia es conocido como la Licencia Pública General (GPL).

La revista Wired tiene el siguiente resumen de este esquema y de sus intenciones (http://www.wired.com/wired/5.08/linux.html):
 

La licencia pública general, o GPL, permite a los usuarios vender, copiar e intercambiar programas con copyleft -- que también pueden tener Copyright (derechos reservados) -- pero tienen que tener la misma libertad de vender o copiar tus modificaciones y de cambiarlas posteriormente. Usted deberá hacer disponible las modificaciones de su código fuente disponible sin restricciones.

La segunda cláusula del código fuente del software libre es el más controvertido (y, posiblemente el más exitoso) aspecto del licenciamiento CopyLeft.

Proceso de Software Abierto

Los procesos comerciales de desarrollo de software están enmarcados por la organización alrededor de objetivos económicos. Sin embargo, debido a que el dinero generalmente no constituye el motivo (principal) detrás del Software Abierto, la comprensión de la naturaleza de la amenaza requiere de una profunda comprensión del proceso y motivación de los equipos de desarrollo de OSS.

En otras palabras, para comprender cómo se puede competir en contra del OSS, debemos dirigirnos en contra de un proceso, en vez de una compañía en particular.

{ Este es un enfoque muy importante, uno que yo hubiera deseado que se le escapase a Microsoft. La lucha real no es NT vs. Linux, o Microsoft vs. Red Hat/Caldera/S.u.S.E. -- sino en la lucha entre el desarrollo con fuente cerrada vs. la de fuente pública. La catedral vs. el bazar.

Esto también se aplica viceversa, por lo cual es el motivo de que el condenar a Microsoft por sí mismo yerra en el punto -- ellos constituyen un síntoma, no la enfermedad misma. A mí me gustaría que lo entendiesen de esta manera una mayor cantidad de hackers de Linux.

En el ámbito práctico, esto implica que podemos esperar que la maquinaria de propaganda de Microsoft se dirija directamente en contra del proceso y de la cultura del software abierto, en vez de competidores específicos. Aténganse a ello... }

Equipos de Desarrollo de Software Abierto

Algunas de las características centrales de los equipos de OSS a través de Internet son:
 

• Geográficamente difuso. Algunos de los desarrolladores clave de Linux, por ejemplo, están distribuidos uniformemente a través de Europa, Estados Unidos y Asia.

• Un gran conjunto de gente que contribuye con un conjunto más pequeño de individuos clave. Una vez más, Linux tiene más de 1,000 personas que aportan parches, realizan depuraciones, etc., y tienen a más de 200 individuos que contribuyen directamente al código del kernel.

• No están motivados por el dinero (en el corto plazo). Estos individuos se asemejan más a aficionados que invierten su tiempo/energía libre en el desarrollo de un proyecto de OSS, mientras que mantienen otros empleos de tiempo completo. Esto ha comenzado a cambiar con la aparición de versiones comerciales del SO Linux.

Coordinación del Desarrollo del OSS

Comunicación a Escala Internet

La coordinación de un equipo de OSS es extremadamente dependiente de las formas propias de colaboración de Internet. Entre los métodos típicos empleados para sacarle el mayor provecho a las tecnologías de colaboración de Internet están:
 

• Listas de Correo Electrónico

• Grupos de Noticias

• Monitoreo de las 24 horas al día, 7 días a la semana por parte de suscriptores internacionales

• Sitios de Web

Los proyectos de OSS de las dimensiones de Linux y Apache son viables sólo si tienen una comunidad de desarrolladores altamente calificados reunidos para abordar un problema. Por lo tanto, existe una relación directa entre el tamaño del proyecto que el OSS puede abordar y el crecimiento del Internet.

Dirección común

Además de los medios de comunicación, existe otro conjunto de factores que coordinan de manera implícita la dirección del equipo.

Objetivos Comunes

Los objetivos comunes son equivalentes a los planteamientos de visión que permean dentro de la toma de decisiones distribuidas por parte de todo el equipo de desarrollo. Una sola y clara directiva (e.g. "volver a crear UNIX") es transmitida de manera mucho más eficiente, y se actúa sobre de ella más efectivamente que una múltiple e intangible (e.g. "hacer un buen sistema operativo").

Precedentes Comunes

Los precedentes son posiblemente el factor más importante en la explicación del rápido y cohesivo crecimiento de los proyectos masivos de OSS tales como el Sistema Operativo Linux. Debido a que la comunidad de Linux ha tenido años de experiencia compartida enfrentando a otras formas de UNIX, ellos fácilmente son capaces de discutir de una manera no-confrontacional lo que ha funcionado y lo que no lo hizo.

No hubo argumentos en contra de la sintaxis de los comandos para utilizar el editor de textos que todo el mundo ya usaba "vi", y los desarrolladores simplemente sacaron trozos del espacio de nombres de comandos para desarrollarlos.

El poseer un punto de vista 20:20 histórico proporciona una estructura implícita fuerte. En organizaciones con más visión, esta estructura es proporcionada por un liderazgo visionario y fuerte.

{ A primera vista, esto parece el comentario de un Bill de nariz café por parte de alguien que espera que Gates lea el memorándum -- usted casi puede ver al autor inclinarse ante un icono del Líder Temerario.

En un sentido más general, esto sugiere una subestimación serie a la que posiblemente se le puede sacar provecho de la capacidad de la comunidad del software abierto de crear sus propios líderes visionarios. No obtuvimos Emacs o Perl o la World Wide Web a partir de una "visión 20:20" -- ni es correcto plantear que aún el diseño relativamente conservador del kernel de Linux como una recreación retrospectiva de modelos pasados.

De acuerdo a esto, el documento sugiere que la respuesta de Microsoft hacia el Software Abierto puede estar mal parado al poner énfasis sobre la innovación de nuestras acciones y de la manera que empleamos para realizarlo hacia el resto del mundo. }

Conjunto de Habilidades Comunes

NatBro señala de la necesidad de un conjunto de habilidades de consenso como prerrequisito del desarrollo del OSS. Este punto está muy relacionado con los fenómenos de precedentes comunes. De su correo electrónico:
 

Una característica central "es el conjunto de habilidades comunes de UNIX/GNU/make a la cual recurre y refuerza el OSS. Yo podría pensar que todo el proceso no funcionaría si la barrera de entrada fuese mucho más alta de lo que es", un programador de UNIX con habilidades modestas puede crecer al realizar cosas interesantes dentro de Linux y otros productos OSS. Puesto de otra manera -- no es muy difícil que un desarrollador dentro del espacio de OSS inicie, debido a que las cosas necesarias para crear son muy similares entre sí, depuran de manera semejante, etc.
Mientras que los precedentes identifican un objetivo común, las habilidades comunes describen a un cierto número de personas que están versadas en el proceso necesario para alcanzar ese fin.

La Catedral y el Bazar

Se publicó un artículo muy influyente por parte de un entusiasta del software abierto, Eric Raymond por primera vez en Mayo de 1997 (http://www.redhat.com/redhat/cathedral-bazaar/) (versión en español http://148.228.125.65/~jsoto). El artículo de Raymond fue expresamente citado por el entonces Ejecutivo de Netscape Eric Hahn con uno de los motivos por los que se decidió publicar el código fuente del navegador.

Raymond destazó su proyecto de OSS para poder extraer las reglas de funcionamiento para que pudiesen ser explotados por otros proyectos OSS en el futuro. Entre las reglas de Raymond están las siguientes:
 

Cada trabajo bueno de software comienza por estimular la iniciativa personal del desarrollador.

Esto resume una de las motivaciones centrales de los desarrolladores dentro del proceso OSS en la solución de un problema inmediato por parte de un desarrollador individual. Esto ha permitido al OSS evolucionar hacia proyectos complejos sin la constante retroalimentación de una organización de comercialización/soporte.

Los buenos programadores saben qué es lo que hay que escribir. Los mejores saben como reescribirlo (y reutilizarlo).
Raymond plantea que los desarrolladores son más propensos a reutilizar el código en una manera rigurosa de software abierto que en el ambiente de desarrollo más tradicional, debido a que se les garantiza el acceso a todo el código fuente de manera permanente.

La amplia disponibilidad del código fuente reduce el costo de búsqueda para encontrar un problema del código en específico:

 
"Planee desechar uno; de todos modos, usted lo hará."

Esta es una cita de Fred Brooks, "The Mythical Man-Month" (El Mítico Hombre del Mes), Capítulo 11. Debido a que los equipos de desarrollo en el OSS están involucrados en componentes enormes y difusos, muchos de los subcomponentes en Linux tuvieron varios prototipos iniciales seguidos de la selección y refinamiento hacia un sólo diseño por Linus.
 

El tratar a sus usuarios como codesarrolladores es abordar la ruta de esfuerzo mínimo para el mejoramiento del código y para una depuración efectiva.

Raymond plantea una fuerte documentación y un soporte de desarrollador significativo dentro de los proyectos OSS para obtener el máximo de los beneficios posibles.

La documentación del código es citada como un área en el que los desarrolladores comerciales típicamente presentan negligencias que serían errores fatales dentro del OSS
 

Publique temprano. Publique frecuentemente. Y escuche a sus clientes.
Esto es una cita clásica de cualquier manual de Microsoft. Sin embargo, los entusiastas del OSS hacen notar que su ciclo de publicación-retroalimentación es potencialmente de un orden de magnitud más rápido que el software comercial.

{ Esto es una afirmación arrogante interesante, como si ellos pensaran que yo fui inspirado de alguna manera por la manera de publicaciones exclusivamente de binarios por parte de Microsoft.

Pero esto sugiere algo más -- aún cuando el autor comprende intelectualmente la importancia de la publicación del código fuente, él no alcanza a percibir realmente que tan fuerte estímulo puede ser la frecuente publicación de código fuente realmente. Es posible que vivir bajo las suposiciones de Microsoft haga esto imposible. }
 

Dadas las grandes dimensiones de la base de beta testers y codesarrolladores, se identificará rápidamente casi cualquier problema y la reparación será obvia para alguien.
Esto es probablemente la esencia del punto de vista de Raymond hacia el proceso de OSS. El posteriormente resumió esta regla como "la depuración es paralelizable". A continuación viene un análisis con mayor profundidad.

{ Bueno, lo sacó de todos modos. }

Desarrollo en Paralelo

Una vez que se haya establecido el marco de componentes (e.g. que se hayan definido las estructuras y aplicaciones clave), los proyectos OSS tales como Linux usan varios equipos pequeños de individuos que resuelven de manera independiente los problemas en particular.

Debido a que los desarrolladores son típicamente aficionados, la capacidad para financiar esfuerzos múltiples, que compiten entre sí no resulta un problema en sí, y el proceso OSS se beneficia de la capacidad de elegir la mejor implementación potencial a partir de las que se produjeron.

Nótese que esto depende mucho de:

Un grupo grande de individuos que están dispuestos a proporcionar código.

Un marco de componentes fuerte e implícita (que en el caso de Linux fue heredado de la arquitectura de UNIX).

Depuración Paralela

El argumento central planteado por Eric Raymond es que, a diferencia de otros aspectos del desarrollo de software, la depuración del código es una actividad cuya eficiencia aumenta de manera casi lineal con respecto al número de individuos comprometidos con el proyecto. Existen reducidos/ningún costo de mantenimiento o coordinación asociados con la depuración de un pedazo de código fuente abierta. Esta es la clave de las leyes de Brooks para el OSS.

Raymond incluye la descripción de Linus Torvalds dentro del proceso de depuración:
 

Mi planteamiento original era que todo problema "será transparente para alguien". Linus comentaba que la persona que entiende y repara el problema no es necesariamente, ni siquiera típicamente la persona que lo identifica. Él decía que "Alguien identifica el problema y alguien más lo entiende. Y causaré controversia al afirmar que encontrarlo constituye un mayor reto." Pero el punto es que ambas cosas tienden a suceder bastante rápidamente.
Dicho de otra manera
 
"La depuración es paralelizable". Jeff [Dutky <dutky@wam.umd.edu] plantea que a pesar de que la depuración requiere que los involucrados se coordinen con algún desarrollador en el papel de moderador, no se requiere de comunicación significativa entre los depuradores. Por lo tanto, no es presa de la misma complejidad y de los costos de administración que hacen que se sumen desarrolladores sea problemáticos.
Una ventaja de la depuración en paralelo es que los errores y su reparación son encontrados/propagados mucho más rápidamente que el proceso tradicional. Por ejemplo, cuando se posteó por primera vez el ataque IP del TearDrop en la red, habían pasado menos de 24 horas para que la comunidad de Linux haya publicado una reparación disponible para bajarse de la red.

Estimulación de la Depuración

Una extensión de la depuración en paralelo que agregaré es la hipótesis de Raymond de la "depuración impulsiva. En el caso del SO Linux, está implícito en el hecho de instalar el SO el instalar un ambiente de depuración/desarrollo. Por lo tanto, es muy probable que si algún usuario/desarrollador se encuentra con un error del componente de otro individuo, y especialmente si el error es "somero", el usuario puede rápidamente reparar el código y mediante las tecnologías de colaboración de Internet, propagar el parche hacia el moderador del código rápidamente.

Dicho de otra manera, los procesos de OSS tienen una barrera muy baja de entrada al proceso de depuración debido a la metodología en común de desarrollo/depuración derivado a partir de las herramientas de GNU.

Solución de Conflictos

Cualquier proceso de desarrollo a gran escala se encontrará con conflictos que deberán resolverse. Frecuentemente, la solución radica en una decisión arbitraria para avanzar dentro del proyecto. En términos comerciales, el desempeño de la jerarquía de la corporación resuelve este problema. Cómo es que los equipos de OSS resuelven estos problemas?

En el caso de Linux, Linus Torvalds es el "líder" sin discusión del proyecto. Él delegó a grandes componentes (e.g. interfaces de red, manejadores de dispositivos, etc.) a varios de sus "lugartenientes", quienes delegan de facto a un puñado de dueños de área (e.g. manejadores de LAN).

Otras organizaciones son descritas por Eric Raymond (http://earthspace.net/~esr/writings/homesteading/homesteading-15.html)

Algunos proyectos muy grandes descartan el modelo del "dictador benevolente" completamente. Una manera de hacerlo es hacer que los codesarrolladores formen un comité donde se vota (como sucede con Apache). Otro mecanismo es la rotación de la dictadura, en el que el control es rotado entre un integrante y otro dentro de un círculo de codesarrolladores veterano (que es la manera en que se organizan los desarrolladores de Perl).

Motivación

Esta sección proporciona un análisis de algunas de las razones centrales del por qué los desarrolladores de OSS contribuyen a los proyectos de OSS.

Resolviendo el Problema a Mano

Esto es básicamente un replanteamiento de la primera regla de Raymond "Cada uno de los trabajos buenos de software comienza por la estimulación de la iniciativa del desarrollador".

Muchos proyectos de OSS - tales como Apache - iniciaron como un pequeño grupo de desarrolladores que empezaron a resolver un problema inmediato. Mejoras subsecuentes del código generalmente parten de la aplicación que realizan los individuos en sus propios escenarios (e.g. el descubrir que no existe un manejador del dispositivo para un NIC en particular, etc.).

Educación

El kernel de Linux surgió de un proyecto educativo de la Universidad de Helsinki. De manera semejante, muchos de los componentes del sistema Linux/GNU (el GUI de X Windows, utilerías de shell, la formación de clústers, la parte de redes, etc.) fueron extendidos por individuos localizados en instituciones educativas.
 

• En el Extremo Oriente, por ejemplo, Linux está creciendo más rápidamente que la conectividad de Internet, lo que se debe principalmente a la adopción educativa.

• Las Universidades son algunos de los que propusieron por primera vez al OSS como herramienta educativa.

• Los proyectos de enseñanza/investigación que están por encima de Linux son fácilmente "diseminados" debido a la amplia disponibilidad del código fuente de Linux. En particular, esto frecuentemente implica nuevas ideas de investigación que son implementadas y disponibles en Linux antes de que estén disponibles/incorporados a otras plataformas.

Gratificación del Ego

La motivación más etérea, y quizás la más profunda, presentada por la comunidad de desarrollo de OSS es simplemente la gratificación del ego.

En "La Catedral y el Bazar", Eric S. Raymond cita:
 

La "función de utilidad" de los hackers de Linux están maximizando, no en el sentido económico clásico, sino en la intangibilidad de la satisfacción de su propio ego y de la reputación entre otros hackers.
Y, por supuesto, "usted no es aún un hacker a menos que alguien más lo llame hacker".

Cuidando la Noósfera

En un segundo artículo publicado por Raymond llamado "Cuidando la Noósfera" (http://sagan.earthspace.net/~esr/writings/homesteading/), él aborda la diferencia entre el intercambio motivado por razones económicas (e.g. el desarrollo comercial de software por dinero) y el "intercambio gratuito" (e.g. alabado sea el OSS).

El "cuidar" está adquiriendo propiedad al ser el primero en "descubrir" al proceso, o al ser el más reciente en realizar una contribución significativa a él. La "Noósfera" es vagamente definida como el "espacio de todo el trabajo". Por lo tanto, como plantea Raymond, la motivación del hacker de OSS es la aspiración de cubrir la mayor área dentro de un trabajo. En otras palabras, tomar el crédito del pedazo más grande del premio.

{ Esto es una mala interpretación sutil pero significativa. Esta introduce la noción del 'tamaño' territorial que no está por ningún lado en mi teoría. Podría ser un error personal del autor, pero sospecho que refleja la cultura obsesionada con la competencia de Microsoft. }

Del artículo de "Cuidando la Noósfera":

La abundancia refleja relaciones de mando difíciles de sostener, y las relaciones  comerciales de intercambio pierden sentido. En las culturas de intercambio libre, el estatus social está determinado no por lo que usted controla, sino lo que usted comparte.

Examinado de esta manera, es bastante claro que la sociedad de hackers de software abierto es en realidad una cultura de intercambio libre. Dentro de ella, no existe una escasez seria de 'necesidades de supervivencia' -- espacio de disco, ancho de banda, poder de cómputo. El software es compartido libremente. Esta abundancia crea una situación en la que la única medida del éxito competitivo es la reputación entre sus iguales.

De manera más sucinta (http://www.techweb.com/internet/profile/eraymond/interview):
 

SIMS: Por lo tanto, la escasez de lo que usted buscaba era la escasez de atención y recompensa?
RAYMOND: Esto es correcto.

Altruismo

La motivación controversial, y por la que estoy inclinado a creer es que en algún nivel, el altruismo "degenera" en una forma de gratificación del ego planteado por Raymond

Una motivación menor que parte del altruismo es la lucha contra Microsoft.

{ Lo que constituye un reconocimiento fascinante, cuando viene de Microsoft mismo! Por supuesto, él no analiza donde existe la relación; por que esto podría pegar demasiado cerca de la casa... }

Una amenaza clave de cualquier equipo grande de desarrollo -- y uno que es particularmente exacerbado por el proceso caótico de un equipo de desarrollo de las dimensiones de Internet es el riesgo de división de equipos.

La división de los equipos ocurre cuando evolucionan versiones múltiples e inconsistente de proyectos de desarrollo de código fuente.

Por ejemplo, en el mundo comercial, el manejo único del código de Windows NT es considerado como una de las mayores ventajas sobre el código "dividido" que se encuentran en las implementaciones comerciales de UNIX (SCO, Solaris, IRIX, HP-UX, etc.).

División dentro del UNIX OSS del BSD

Dentro del espacio del OSS, el UNIX BSD es la mejor muestra de una división dividida del proyecto. El UNIX de BSD fue un intento de la Universidad de California en Berkeley para crear una versión gratuita del sistema operativo UNIX con propósitos educativos. Sin embargo, Berkeley puso severas restricciones sobre los usos no académicos del código fuente.

Para poder crear una versión totalmente gratuita de UNIX BSD, se creó un equipo ad hoc de desarrolladores (pero cerrado) llamado FreeBSD. Por una u otra razón, surgieron discrepancias dentro del equipo de FreeBSD, por lo que se crearon otras variantes (OpenBSD, NetBSD, BSDI).

Existen dos factores dominantes que llevaron a la división del árbol de BSD:
 

• No todos pueden contribuir al código de BSD. Esto limita en efecto el tamaño real de la "Noósfera" y crea el potencial de que alguien pueda plantear de manera creíble que su porción de código será más dominante que el código BSD central.

{Vaya. Esto es algo que yo nunca había visto -- el que la división pueda ser llevado a cabo por la creencia de que la división podría acumular un mayor bazar que el proyecto actual. Esto en verdad explica la división de EGCS y BSD, aunque no explica la división de Emacs/Xemacs.

OK, hemos aprendido algo nuevo ahora. Esto podría explicar el hecho que va en contra de la intuición de que el abrir el desarrollo en realidad tiene la menor tendencia a la división... }

A diferencia del GPL, las licencias de BSD no ponen restricciones sobre el código derivado. Por lo tanto, si usted piensa que sus modificaciones son lo suficientemente buenas, usted es libre de dividir el código, cobrar por él, cambiar el nombre, etc.

Ambos motivos pueden crear una situación en la que los desarrolladores pueden intentar forzar una división en el código y reunir honorarios (monetarios o de ego) a expensas del colectivo de BSD.

{Falta de} División en Linux

En contraste con el ejemplo de BSD, el código fuente del kernel de Linux no se ha dividido. Entre las razones que explican la integridad del código fuente de Linux están:

Liderazgo universalmente aceptado

Linus Torvalds es una celebridad dentro del mundo de Linux, y sus decisiones se consideran finales. En comparación con esto, no existió un líder con éxito similar dentro de los esfuerzos derivados del BSD.

Linus es considerado por el equipo de desarrollo como un moderador de código justo y razonable, y su reputación dentro de la comunidad de Linux es bastante fuerte. Sin embargo, Linus no está involucrado en cada una de las decisiones. Frecuentemente, los subgrupos resuelven sus diferencias -- que frecuentemente son grandes -- entre ellos mismos y evitan la escisión.

• Membresía Abierta y el potencial de contribución a largo plazo.

En contraste con la membresía cerrada de BSD, cualquiera puede contribuir a Linux y su estátus -- y por tanto ser capaz de "mantener" un mayor pedazo de Linux basado en el tamaño de las contribuciones anteriores.

Esto indirectamente presenta un obstáculo a la escisión. Casi no existe mecanismo con credibilidad por la cual el código en minoría, escisionista podrá ser capaz de mantener el ritmo de innovación hacia el código principal de Linux

• El licenciamiento GPL elimina los motivos económicos de la escisión

Debido a que los derivados de Linux DEBEN estar disponibles a través de algún camino gratuito, esto reduce la rentabilidad a largo plazo para cualquier minoría con una parte del  árbol de Linux.

• La escisión del código base también divide la "Noósfera"

Las motivaciones de ego impulsan a los desarrolladores de OSS a apostar a la Noósfera más grande. El dividir al código fuente invariablemente reduce el espacio de realización de cualquier desarrollador subsecuente para el nuevo árbol de código.

Fortalezas del Software Abierto

Cuáles son las fortalezas centrales de los productos OSS con los que debe estar preocupados Microsoft?

Atributos Exponenciales del OSS

A semejanza de nuestro negocio de Sistema Operativo, el ecosistema de OSS tiene varios atributos exponenciales:

Los procesos OSS están creciendo en el Internet

La limitación más grande a la que se enfrenta cualquier proyecto de OSS es encontrar la cantidad necesaria de desarrolladores dispuestos a invertir en el proyecto. Como medio que hace posible este proceso, el Internet es indispensable para reunir la cantidad necesaria de gente para un proyecto de la escala de un Sistema Operativo. Es más, el motor de crecimiento de este tipo de proyectos es el crecimiento mismo del Internet. Las mejoras en las tecnologías de comunicación van aceitando directamente el motor del OSS.

Dicho de otra manera, el crecimiento del Internet hará que los proyectos OSS existentes se hagan cada vez más grande, y también hará posible que los proyectos de OSS en categorías más reducidas se hagan viables.

• Los procesos OSS son del tipo "el ganador se lleva todo"

A semejanza del software comercial, el proyecto OSS más viable en muchas categorías eliminará a los demás proyectos OSS y adquirirá su capacidad intelectual. Por ejemplo, Linux está eliminando BSD UNIX y ha absorbido la mayor parte de sus ideas centrales (así como las ideas de los UNIXes comerciales). Esta característica le da ventajas comparativas enormes a un proyecto en particular.

• Los desarrolladores buscan contribuir a la plataforma más grande de OSS.

Entre más grande sea el proyecto OSS, mayor será el prestigio que adquirirá el desarrollador con la contribución de un componente importante de alta calidad en su Noósfera. Este fenómeno contribuye a la naturaleza de que "el ganador se lleva todo" de los procesos OSS en un segmento determinado.

• Los proyectos más grandes de OSS resuelven más problemas a la mano

Entre mayor sea un proyecto, mayor será la cantidad de desarrollo/prueba/depuración que recibirá el código. Entre más grande sea la cantidad de depuración involucrada, mayor será el número de gente que querrá emplearlo.

Credibilidad a Largo Plazo

Los binarios pueden morir, pero el código fuente vive para siempre

Una de las implicaciones más importantes de un ecosistema viable de OSS es la credibilidad a largo plazo

Definición de la Credibilidad a Largo Plazo

La credibilidad a largo plazo existe si no existe manera alguna de que se le margine a uno del negocio en el corto plazo. Esto obliga a un cambio en la manera que los competidores tratan con usted.

Por ejemplo, Airbus Industries reunió una credibilidad a largo plazo debido a un apoyo explícito a largo plazo. Por lo tanto, cuando estaban negociando un contrato de aerolíneas, Boeing era más susceptible de aceptar un contrato a corto plazo, sin dividendos cuando estaba compitiendo contra Lockheed que cuando estaba negociando contra Airbus.

Al aplicarse en el caló de la industria del software, un producto/proceso tiene credibilidad a largo plazo si no se pueden emplear tácticas FUD para combatirlo.

El OSS tiene Credibilidad a Largo Plazo

Los sistemas OSS son considerados como creíbles debido a que el código fuente está disponible potencialmente para millones de lugares e individuos.

{ Estamos en un aspecto central de la concepción que tiene sobre la realidad Microsoft. Entiendo cual sería la reacción típica de un hacker a este tipo de pensamiento al encontrarlo nauseabundo, pero refleja el tipo de medios inmisericordes que tienen los aspectos negativos del libre mercado con los que tenemos que aprender a enfrentarnos.

La cuestión realmente interesante de estos dos enunciados es que implican que Microsoft debería dejar de utilizar FUD como una táctica efectiva en contra de nosotros.

La mayor parte de nosotros ha estado asumiendo que el juicio antitrust del Departamento de Justicia ha evitado que Microsoft saque los fusiles FUD. Pero si Su Majestad [Bill Gates] entendió esta parte del memorándum, entonces Microsoft puede estar creyendo que necesitan desarrollar una respuesta más sustanciosa, debido a que FUD no va a funcionar.

Esto podría significar buenas y malas noticias. La buena noticia es que Microsoft dejaría de utilizar la mercadotecnia para atacarnos, el cual ha sido en el pasado un arma mucho más poderosa que su tecnología inferior. La mala noticia es que dejar de emplear este mecanismo sería en realidad una mejor estrategia; ellos no estarían desperdiciando tanta energía y podrían producir una respuesta más efectiva. }

La probabilidad de que Apache deje de existir es órdenes de magnitud menor que la probabilidad de que WordPerfect deje de existir, por ejemplo. La desaparición de Apache no está relacionado con la desaparición de los binarios (que son afectados por cambios en su adquisición) sino en la desaparición del código fuente y de la base del conocimiento.

Dicho de otra manera, los clientes saben como se va a desempeñar Apache dentro de cinco años -- siempre y cuando exista un mínimo de interesados de su comunidad de usuarios/desarrolladores.

Uno de los clientes de Apache, durante la discusión de sus motivos para correr su sitio de comercio electrónico sobre OSS afirmó que "es debido a que es de fuente abierta, por lo que le puedo asignar uno o dos desarrolladores al proyecto y lo puedo mantener yo mismo indefinidamente".

Falta de Escisión estimula la Credibilidad a Largo Plazo

La GPL y su animadversión a la división de los equipos de desarrollo garantizan a los clientes el que no estén dentro de un proceso evolutivo que lleve a un callejón sin salida al subscribirse a una versión comercial en particular de Linux.

El callejón sin salida evolutivo es el centro del argumento del FUD.

{ Esto es muy cierto -- y aquí hay otra omisión flagrante. Si el autor hubiera sido realmente honesto, él habría notado que los entusiastas del OSS están bien colocados para voltear este argumento en dirección contraria y matar a Microsoft con este argumento.

Como lo admite el mismo autor, el OSS está blindado en este sentido. Por otro lado, la creciente complejidad y el deslizamiento de la calendarización del recientemente renombrado "Windows 2000" sugiere que éste es un callejón evolutivo sin salida.

El autor no lo señaló, pero nosotros si lo deberíamos hacer. }

Depuración en Paralelo

Los entusiastas de Linux y otros OSS están haciendo el planteamiento cada vez más creíble de que el software OSS es por lo menos tan robusto -- si no es que más robusto -- que las alternativas comerciales. El Internet proporciona un escaparate ideal de alta visibilidad para el mundo de OSS.

{ Somos un puñado de aficionados, la mayor parte de nosotros sin paga y casi siempre de medio tiempo en contra de una máquina de propaganda dirigida por algunos de los mejores especialistas en el negocio de la comercialización de tecnología.

Y son estos aficionados los que "están haciendo el planteamiento cada vez más creíble". Como lo reconoce Microsoft, en realidad estamos ganando.

Es posible que exista un mensaje subyacente de productos aquí . }

En particular, las organizaciones más grandes que confían en el OSS para sus operaciones de negocios (e.g. ISP) están a gusto con el hecho de que puedan reparar un error paralizante independientemente de un calendario comercial (por ejemplo, UUNET fue capaz de obtener, compilar y aplicar el parche contra el ataque de teardrop en sus máquinas de Linux dentro de 24 horas después de que ocurrió el primer ataque público.).

Desarrollo en Paralelo

Se puede plantear de manera alternativa que los recursos, ?? los recursos de los desarrolladores son esencialmente libres en el OSS --. Debido a que el universo de desarrolladores potenciales es masivo, es económicamente viable el investigar simultáneamente varias soluciones/versiones a un problema y escoger la mejor solución al final.

Por ejemplo, el stack TCP/IP de Linux fue escrito probablemente tres veces. Los componentes en ensamblador en particular han sido afinados a mano y refinados.

OSS = Perfecto - Evangelización/Documentación sobre API

La evangelización/educación de desarrolladores es básicamente proporcionar al desarrollador con código subyacente. Mientras que la evangelización de las aplicaciones del modelo cerrado se fundamenta básicamente en la confianza, la evangelización OSS API permite al desarrollador elegir.

NatBro y Ckindel señalan una división de las capacidades de desarrollo en este lugar. Mientras que el desarrollador entusiasta está confortado por la evangelización OSS, los desarrolladores novatos/intermedios "el grueso de la comunidad de desarrollo" prefieren el modelo de confianza + credibilidad organizativa (e.g. Microsoft API X mira de este lado.).

{ Si esto fuera realidad, la mayor parte de los desarrolladores que preferirían el modelo de ?confianza? no sería una cuestión relevante.

Veinte años de experiencia en el campo me dicen que en general no es cierto que los desarrolladores prefieren este tipo de código, aún cuando sus jefes que no son técnicos son lo suficientemente cándidos para preferir la ?confianza?. Obviamente, Microsoft quiere creer que la ?credibilidad organizativa? importa - por lo que yo detecto aquí algunos deseos planteados.

Por otro lado, pueden estar en lo correcto. Nosotros, los de la comunidad del software abierto no podemos asumir el costo de despreciar esta posibilidad. Yo pienso que podemos satisfacerla al desarrollar documentación de alta calidad. De esta manera, la ?confianza? que cita el autor (o los publicadores de buena reputación tales como O?Reilly o Addison-Wesley) pueden sustituir la ?confianza? dentro de una organización que defina API.) }

Ritmo de Publicación

Los proyectos de OSS que tienen muchos componentes son capaces de publicar subcomponentes tan pronto como el desarrollador ha terminado su código. Por lo tanto, los proyectos OSS revisan rápida y frecuentemente.

Las debilidades intrínsecas de los proyectos OSS caen dentro de tres categorías principales:

Costos de Manejo

• Asuntos del Proceso

• Credibilidad Organizativa

Costos de Manejo

El mayor obstáculo al que se enfrentan los proyectos OSS es enfrentar el crecimiento exponencial de los costos de manejo a medida que un proyecto va siendo escalados en términos de innovación y tamaño. Esto implica un límite al ritmo al cual puede innovar un proyecto OSS

El Inicio de un Proyecto OSS es Difícil.

Eric Raymond afirma que:
 

Es bastante claro el hecho de que nadie puede empezar de cero en el estilo bazar. Uno puede probar, depurar y mejorar dentro del estilo del bazar, pero sería muy difícil originar un proyecto en el modelo del bazar. Linus no lo intentó. Yo tampoco lo hice. Su comunidad nasciente de desarrolladores requiere de algo que se puede probar y ejecutar para comenzar a jugar. El planteamiento de Raymond puede extenderse a la dificultad de iniciar/sostener un proyecto si es que no existe un precedente/objetivo claro (o demasiados objetivos) para el proyecto.

Credibilidad del Bazar

Obviamente, existen muchos más trozos de código fuente en el Internet que comunidades OSS. ¿Qué es lo que separa el código fuente muerto del bazar?

Un artículo (http://www.mibsoftware.com/bazdev/0003.htm) proporciona los siguientes criterios de credibilidad:
 

"... pensando en términos del mínimo absoluto de participantes no conduce a nada. Fetchmail y Linux tiene grandes números de beta testers actualmente, pero obviamente comenzaron con unos cuantos. Lo que ambos proyectos tenían era un puñado de entusiastas y una promesa plausible. La promesa era en parte técnica (este código será maravilloso con un poco de esfuerzo) y sociológico (si usted se une, usted tendrá la misma diversión que la que estamos teniendo). Por lo tanto, ¡lo que es necesario para que se desarrolle un bazar es que sea creible el hecho de que existirá un bazar en toda su extensión!

Yo postearé algunos de los principales criterios centrales que deberán existir para que un bazar sea creíble, y entre estos están:
 

• Una Futura Noósfera Grande - El proyecto debe ser lo suficientemente atractivo para que la recompensa intelectual recompense el tiempo invertido por los desarrolladores. El SO Linux se desempeña bastante bien en este aspecto.

• Despertar la Curiosidad - El proyecto deberá ser importante/ejecutable por una gran audiencia de desarrolladores. El Apache Web Server proporciona un excelente ejemplo de esto.

• Resolver la Cantidad Justa del Problema Primero - La solución de una parte excesiva del problema relega a la comunidad de desarrolladores de OSS al papel de testers. El resolver demasiado poco antes de empezar el OSS reduce la promesa plausible y no proporciona una infraestructura lo suficientemente fuerte para coordinar el trabajo de manera eficiente.

{ Estos tres puntos están bien pensados, y en realidad mejoran mi caracterización dentro del artículo "La Catedral y el Bazar". La diferenciación entre una "Futura Noósfera Grande" y "Despertar la Curiosidad" es de bastante provecho. }

Desarrollo Posterior a la Paridad

Al describir este problema a JimAll, el proporcionó la perfecta analogía de "corretear luces". La manera más fácil de obtener un comportamiento de una muchedumbre grande y semiorganizada es señalarles un blanco conocido. Teniendo las luces proporciona una concretización de una idea. En muchas situaciones, el tener una luz al cual seguir es sustituto de un liderazgo central fuerte.

Por supuesto, una vez que este principio organizativo ya no está disponible (una vez que el proyecto ha alcanzado la paridad con la vanguardia), el nivel de manejo necesario para avanzar hacia nuevas fronteras se hace masivo.

{ Esto no tiene sentido. En el mundo del software abierto, todo lo que se requiere es una persona con una buena idea.

Parte del punto del software abierto es que reduce las barreras de energía que retardan la innovación. Hemos encontrado mediante nuestra experiencia que el "manejo masivo" que plantea el autor es uno de los peores obstáculos.

En el mundo del software, los innovadores pueden intentar cualquier cosa, y la única prueba es si los usuarios estarán dispuestos a experimentar con la innovación y que les guste una vez que ya lo hayan hecho. El Internet hace posible este proceso, y las convenciones sobre la cooperación entre la comunidad del software abierto están específicamente diseñados para promoverlos

La tercera alternativa a "corretear luces" o "liderazgo central fuerte" (y que resulta más efectivo que los anteriores) es evolucionar en una anarquía creativa, en la que existen miles de líderes y decenas de miles de seguidores conectados a través de una red de revisión entre pares y sujeto a revisiones en casos reales.

Microsoft no puede ganarle a esto. Yo no pienso que en realidad siquiera lo comprendan, ni un ápice. }

Esto es posiblemente el hecho que más salta a la vista de la comunidad de Linux, ahora que ya han logrado paridad con la vanguardia en UNIX en muchos sentidos.

{ La comunidad no sólo lo ha alcanzado, sino ya lo demolió. Este hecho es el centro de la ventaja a largo plazo del software abierto sobre el desarrollo cerrado. }

Trabajo no Llamativo

Otro asunto interesante para observar en el cercano futuro del OSS es que tan bien han sido capaces de llevar a cabo trabajo duro para llevar a la vida a un producto de calidad comercial.

En el espacio de los sistemas operativos, esto incluye pequeñas y esenciales funciones tales como administración de la alimentación, suspender/reanudar, infraestructura de administración, cosas llamativas del UI y profundo soporte de Unicode, etc.

Para Apache, esto implica funcionalidad de administradores novatos tales como wizards.

Trabajo de Integración y Arquitectura

El trabajo de integración a través de los módulos es el mayor costo encontrado por los equipos de OSS. Un memorándum mandado por correo electrónico de parte de Nathan Myrhvold en mayo del 98 señala que todos los aspectos del desarrollo de software y trabajo de integración está sujeta a las leyes de Brooks.

Hasta ahora, Linux se ha beneficiado enormemente del modelo de integración/división del trabajo promovido por los anteriores UNIX. Además, la organización Apache fue simplicada por especificaciones sencillas, tolerantes a fallas del protocolo HTTP y del diseño de aplicaciones de los servidores UNIX.

Las innovaciones futuras requieren de cambios en el modelo de integración/arquitectura central que serán muy difíciles de absorber por parte de un equipo OSS, debido a que devalúa simultáneamente sus precedentes y conjunto de habilidades.

{ Esta predicción es una parte de la última afirmación del autor de que el desarrollo del software abierto se basa de manera crítica de precedentes en el diseño y que es inevitable mirar hacia atrás. Esto es míope - parece ser que proyectos tales como Python (http://www.python.org), Beowulf (http://www.beowulf.org) y Squeak (http://squeak.cs.uiuc.edu) (para citar sólo a tres de cientos de proyectos innovadores) no salen en su radar.

Lo único que podemos esperar es que Microsoft continúe creyendo esto, debido a que mediatizaría su respuesta. Mucho va a depender de como interpretan ellos las innovaciones tales como la SMPización del kernel de Linux. }

Cuestiones del Proceso

Estas son las debilidades intrínsecas de una metodología diseño/retroalimentación del OSS.

Costo Iterativo

Uno de los puntos clave para el proceso OSS es el tener muchas más iteraciones que el software comercial (se sabe que Linux llegó a sacar revisiones de su kernel más de una vez al día). Sin embargo, los clientes comerciales nos dicen que ellos desean menos revisiones, no más.

{ Es por esto que existen los distribuidores comerciales de Linux - para mediar entre los procesos rápidos de desarrollos y los clientes que no desean seguir cada uno de los dobleces de éste. El kernel puede estar sujeta a una revisión al día, pero Red Hat sólo realiza una revisión cada seis meses. }

Retroalimentación de Usuarios que no son Expertos

El SO Linux no fue desarrollado para usuarios finales, sino para otros hackers. De manera similar, el servidor de Web de Apache está dirigido implícitamente a los operadores de los sitios más grandes, no a los servidores de intranet departamentales.

La cuestión central aquí es que debido a que los OSS no tienen un componente explícito de comercialización/retroalimentación de los clientes, listas de peticiones - y por lo tanto desarrollo de características para el usuario final - están dominados por los usuarios más aventajados.

Una de las cosas que los grupos de desarrollo han aprendido en MSFT con el tiempo es que la facilidad de uso, la facilidad de uso, etc. debe ser construido a partir de cero en un producto y no puede añadirse posteriormente.

{ Esto exige comentario - debido a que esto es tan correcto en teoría, pero es flagrantemente incorrecto en la práctica de Microsoft. Lo equivocado de esto implica una debilidad que se puede explotar en la estrategia implicada (por Microsoft) al enfatizar el UI.

Existen dos maneras de construir el uso "de cero". Una (la manera Microsoft) es para diseñar aplicaciones monolíticas que están definidas y dominadas por sus UI. Esto tiende a producir "Windowcitis" - monstruosidades rígidas, torpes y propensas a errores que lo que tienen es una superficie flamante y un interior hueco.

Los programas que están construidos de esta manera parecen amigables para el usuarios a primera vista, pero resultan ser enormes sumideros de tiempo y energía en un plazo mayor. Sólo se les puede sostener con una mercadotecnia de bombo y platillo, cuyo propósito principal es lavarles el cerebro a los usuarios para hacerles creer que (a) los errores son características, o que (b) todos los errores son culpa de los usuarios estúpidos, o que (c) se eliminarán todos los usuarios si el usuario adquiere la siguiente versión. Este enfoque ha sido derrotado en esencia.

La otra manera es a la manera UNIX/Internet/Web, que es el separar al motor (que es el que realiza todo el trabajo) del UI (que hace todo el desplegado y el control). Este enfoque requeire de un motor y un UI que se comunican utilizando un protocolo bien definido. Esto está ejemplificado por los pares navegador/servidor - el motor se especializa en ser un motor, y el UI se especializa en ser el UI.

Con este segundo enfoque, la complejidad total se reduce y la confiabilidad aumenta. Además, es más fácil de evolucionar/mejorar/personalizar la interfaz, precisamente debido a que no está estrechamente unido al motor. Hasta es posible hacer múltiples interfaces personalizados para diferente público.

Finalmente, esta arquitectura lleva naturalmente a aplicaciones que están listas para las empresas - que pueden ser utilizadas o administradas de manera remota por el servidor. Este enfoque funciona - y es la manera natural de ser de la comunidad del software abierto la que va en contra de Microsoft.

El punto central aquí es que si Microsoft quiere pelear con la comunidad de software abierto sobre el UI, dejémosle ser - debido a que allí podemos también ganar la batalla, peleándola a nuestra manera. Ellos pueden escribir monolitos de Windows cada vez más elaborados que le solda a usted con su consola servidor-aplicación. Nosotros ganaremos si podemos escribir aplicaciones limpias distribuidas que pueden sacar provecho de Internet y de la Web y hacer de la UI una elección del usuario que puede evolucionar.

Sin embargo, tenemos que hacer notar que el que ganemos depende de la existencia de protocolos bien definidos (tales como HTTP) para comunicar los UI con los motores. Es por esto que los asuntos de este memorándum sobre la "descomercialización de los protocolos" es tan siniestra. Nos tenemos que poner en guardia en contra de esto. }

La tendencia interesante que podemos observar aquí será el efecto que los proveedores de OSS (tales como Red Hat en el espacio de Linux, C2Net en el espacio Apache) tendrán sobre el ciclo de retroalimentación.

Credibilidad Organizativa

¿Cómo puede el OSS proporcionar el servicio que los consumidores esperan de los proveedores de software?

Modelo de Soporte

El soporte del producto es lo primero de lo que se preocupan los consumidores prospecto, y es la característica principal sobre la que se preocupan los redistribuidores comerciales.

Sin embargo, la gran mayoría de los proyectos OSS tienen soporte por parte de los desarrolladores de sus respectivos componentes. El escalar esta infraestructura de soporte al nivel esperado en los productos comerciales será un reto considerable. Existen muchos órdenes de magnitud de diferencia entre los usuarios y desarrolladores en IIS vs. Apache.

{ La vaguedad de esta última frase dice muchas cosas. Si el autor hubiera continuado, él tendría que reconocer que Apache está eliminando a IIS del mercado (la porción de Apache en el mercado es del 54% y está subiendo; mientras que el de IIS está alrededor de 14% y está cayendo).

Esto llevaría a una elección de alternativas desagradables (para Microsoft). Puede ser que los canales informales de soporte al usuario y la "credibilidad organizativa" en realidad produzcan mejores resultados de lo que puede ofrecer la organización IIS de Microsoft. Si esto es cierto, entonces sería muy difícil ver en principio por qué los mismo no debería ser cierto de otros proyectos de software abierto.

La alternativa - el que Apache es tan bueno que en realidad no necesite mucho soporte o "credibilidad organizativa" - es aún peor. Esto implica que todo el soporte de tiempo completo y los batallones de marketing de Microsoft han sido una gigantesca mala inversión, como las manzanas de departamentos estalinistas de hace cuarenta años.

Estas dos explicaciones implican estrategias diferentes, pero paralelas para los que impulsan el software abierto. Una estrategia es la de construir software que es de tan alta calidad que no requiere de demasiado soporte (pero de todos modos lo hacemos, y en general tenemos). La otra es realizar de manera más intensiva lo que ya estamos haciendo sobre las líneas de listas de correo de soporte, grupos de noticias, FAQs, y otros canales informales, pero extremadamente efectivos. }

En el corto-mediano plazo, este factor por sí mismo relegará los productos OSS a los más experimentados de la comunidad de usuarios.

Futuros Estratégicos

Un problema muy sublime, que afectará la plena adopción de los consumidores de los proyectos OSS es la falta de dirección estratégica en el ciclo de desarrollo OSS. Mientras que el continuo aumento del conjunto de características de un producto OSS es muy creíble, las futuras características no tendrán compromiso organizativo para garaantizar su desarrollo.

{ No. En la comunidad del software abierto, las nuevas características son llevadas a cabo por el comportamiento de búsqueda de novedades y de territorio de los hackers individuales. Esta es una fuerza que no se puede despreciar. El Internet y la Web fueron creadas de esta manera - no debido a un "compromiso organizativo", sino debido a que alguien, en algún lado pensó "Hey, esto sería muy bonito...".

Es posible que seamos afortunados del hecho de que la "credibilidad organizativa" esté tan presente en la visión de Microsoft. El tiempo y la energía que invierten pensando sobre esto y creyendo que es un requisito indispensable son recursos que no irán hacia alguna actividad que podría ser efectiva en contra nosotros. }

¿Qué es lo que significa para la comunidad linuxera el apuntarse para ayudar al Sistema Nervioso Digital de las Corporaciones? ¿Cómo puede Linux garantizar compatibilidad retroactiva con las aplicaciones escritas por desarrolladores previos? ¿A quién demandaría uno si la siguiente versión de Linux no cumple algún compromiso? ¿Cómo puede Linux realizar una alianza estratégica con alguna otra entidad?

{El autor ha sido rebasado por los hechos en este punto. Uno le debería preguntar a los cuates de Microsoft en Intel, quién compró una parte minoritaria de las acciones en Red Hat menos de dos meses después de que este memorándum fue escrito. }

En los últimos dos años, el OSS ha tomado un nuevo giro con el surgimiento de compañías que venden software OSS, y lo que es más importante, compañías que están contratando a desarrolladores tiempo completo para mejorar la base del código. ¿Cuál es el modelo de negocio que justifica estos salarios?

En muchos casos, las respuestas a estas preguntos son similares a la pregunta ¿Por qué debería yo someter mi protocolo/aplicación/API a un organismo de estándares?

Modelos de Negocios de Software Abierto

Servicios Secundarios

El vendedor de OSS-ware proporciona ventas, soporte e integración con el cleinte. Efectivamente, esto transforma al vendedor de OSS-ware de un manufacturero de bienes de paquete en un proveedor de servicios.

Falta de Líder - Entrada al Mercado

El modelo de negocios OSS de Falta de Líder puede ser utilizado con dos propósitos:
 

• Adelantándose en un mercado nasciente.

• Entrada hacia un mercado existente con partes de código cerrado bien establecidos.

Muchos de los nuevos participantes OSS, especialmente aquéllos en el espacio de los Sistemas Operativos - ven el subsidio al desarrollo de productos OSS como una manera de desbancar a Microsoft.

Los distribuidores de Linux, tales como Red Hat, Caldera y otros, han expresado voluntad para pagar los salarios de desarrolladores tiempo completo que publican todo su trabajo hacia la comunidad OSS. Al pagar de manera simultánea estos esfuerzos, Red Hat y Caldera se están coludiendo de manera implícita y creen que tendrán mayores ganancias dentro del creciente mercado de Linux que compitiendo directamente entre sí.

Un ejemplo indirecto es la contratación de Larry Wall por parte de O?Reilly & Associates, quien es líder y desarrollador de tiempo completo de PERL. Por supuesto, la editorial que más publica manuales de referencia de PERL es O'Reilly & Associates.

Para el corto plazo, especialmente debido a que el proyecto OSS está en la parte más escarpada de su curva de crecimiento, tales inversiones generan ROI positivo. En el largo plazo, las motivaciones de ROI pueden desviar a estos desarrolladores hacia la creación de extensiones propietarias, en vez de publicar OSS.

Estandarización de los Proveedores hacia Abajo.

Este modelo está muy cercanamente relacionado con el modelo de negocios anterior. Sin embargo, en vez de tratar de obtener dividendos marginales por servicios por un mercado con un masivo crecimiento, estos negocios aumentan sus dividendos como parte de una cadena de valor al rentabilizar a los proveedores hacia abajo.

Las mejores muestras de esto actualmente son los vendedores de servidores delgados tales como Whistle Communicatios y Cobalt Micro, quienes están subsidiando de manera activa a los desarrolladores en SAMBA y Linux respectivamente.

Ambas compañías generan sus dividendos de la venta de hardware. Por lo tanto, el subsidiar al OSS les permite evitar el mercado actual de PC, en la que se debe pagar un impuesto al vendedor de SO (el precio de venta al consumidor del NT Server es de $800, mientras que MSRP de Cobalto está alrededor de $1000).

Los primeros desarrolladores de Apache fueron empleados por ICP y ISP con pocos recursos.

Otro ejemplo reciente es el acuerdo de IBM con Apache. Al declarar al servidor de HTTP como una mercancía, IBM espera concentrar más dividendo en los servicios de aplicación técnicas más arcanas que une con su distribución de Apache (además de que espera alcanzar la tremenda porción del mercado de Apache).

Primero que Llega, Construye, Posteriormente $$$

Una de las cualidades exponenciales de OSS - los proyectos exitosos de OSS se tragan a los menos exitosos a su espacio - implica un modelo de negocios de socavamiento al investigar directamente en OSS ahora, ellos pueden socavar/eliminar proyectos que compiten con ellos posteriormente, especialmente si el proyecto requiere de evangelización API. Esto es lo mismo que tomar la ventaja de la iniciativa en OSS.

Además, la escala de desarrollo, el ritmo de iteración y de confiabilidad de los procesos de OSS son una bendición para los iniciadores pequeños quienes típicamente no pueden solventar un personal en casa de desarrolladores.

Ejemplos de este tipo de iniciadores en este espacio son SendMail.com (que hace una versión con soporte comercial del agente de transferencia de correo sendmail) y C2Net (que hace un Apache encriptado y comercial).

Sun Microsystems ha anunciado recientemente que su proyecto JINI será proporcionado vía OSS y puede representar una aplicación de socavamiento.

Las siguientes secciones analizan los proyectos OSS más relevantes, entre los cuales están Linux, Apache y ahora, el navegador OSS de Netscape.

Un segundo memorándum titulado "Análisis Competitivo del SO Linux" proporciona un análisis a profundidad del SO Linux. En este documento proporciono un resumen superficial de mis hallazgos en Linux.

Linux

¿Qué es eso?

Linux es el SO de Software Abierto número uno del Internet. Linux ha sacado provecho de 25 años de lecciones aprendidas sobre el sistema operativo UNIX.

Características Principales:
 

• Multiusuarios/Multiprocesos (kernel y usuarios)

• Multiplataformas (x86, Alpha, MIPS, PowerPC, SPARC, etc.)

• Espacio de memoria protegida de 32 bits para aplicaciones; soporte de memoria virtual (el de 64 bits está en desarrollo).

• SMP (CPUs de Intel y Sun)

• Soporte múltiple de sistema de archivos (FAT16, FAT32, NTFS, Ext2FS).

• Desempeño en redes de alto rendimiento.

• Interfaz de redes NFS/SMB/IPX/Appletalk.

• Stack más rápido en pruebas perf de UNIX vs. UNIX.

• Manejo de Disco

• Striping, mirroring, FAT16, FAT32, NTFS.

• Xfree86 GUI

Linux es un Proceso Real, Creíble de SO + Desarrollo

Como otros productos OSS, la clave real para Linux no es una versión estática del producto, sino un proceso alrededor de él. Este proceso le da credibilidad y un aire de futura seguridad a las inversiones de los clientes en Linux.
 

• Confiados en ambientes de misiones críticas. Linux ha sido empleado en ambientes comerciales de misiones críticas con un excelente conjunto de testimoniales públicos.

• Linux = Mejor Variante de UNIX. Linux tiene mejor desempeño que muchos otros sabores de UNIX en la mayor parte de las categorías de desempeño (interfaz de redes, E/S de disco, interruptores ctx de procesos, etc.). Para hacer crecer sus base de características, Linux ha robado características de otros sabores de UNIX (características de shell, sistemas de archivos, gráficos, puertos de CPU).

• El único SO UNIX en ganar una parte del mercado. Linux está sobre el camino de adueñarse del mercado x86 de UNIX y ha sido la única versión de UNIX en obtener una parte respetable del mercado de SO para Servidores. Yo creo que Linux - más que NT - será la mayor amenaza a SCO en el futuro cercano.

• Los procesos iterativos de Linux son MUY rápidos. Por ejemplo, el equivalente de Linux de TransmitFile se transformó de una idea a una implementación final en aproximadamente dos semanas.

{ Todo esto es cierto. Yo no lo podría haber redactado mejor :-) . }

Linux es una amenaza a corto/mediano plazo en el área de los servidores

La amenaza principal que Microsoft enfrenta de Linux es en contra del NT Server.

La fortaleza futura de Linux contra el NT Server (así como otros UNIX) está basada en varias características clave:
 

• Linux utiliza hardware de PC común y, debido a la modularidad del SO, puede ser ejecutado en sistemas de menor tamaño que NT. Se utiliza frecuentemente a Linux para servicios tales como DNS corriendo en antiguas 486 encerrados.

• Debido a su herencia UNIX, Linux representa un menor costo de cambio para algunas organizaciones que NT.

• Las ventajas de escalabilidad, interoperabilidad, disponibilidad y facilidad de administración (SIAM) son superiores a las de NT.

• Linux puede ganar en tanto los servicios/protocolos son comerciales.

{ Aquí sentimos que se está desarrollando una idea...

Para decirlo de manera un poco diferente, Linux puede ganar si los servicios son abiertos y los protocolos sencillos. Microsoft puede ganar sólo si los servicios son cerrados y los protocolos son opacos y complejos.

Para ponerlo más burdo, los servicios y los protocolos "comercializables" son buenos para los consumidores, debido a que promueven la competencia y la elección. Por lo tanto, para que Microsoft gane, el consumidor debe perder.

La revelación más interesante dentro de este memorándum es que tan cercano está dispuesto Microsoft para afirmar esta lógica. }

Es improbable que Linux sea una amenaza en el escritorio

Es improbable que Linux sea una amenaza en el mediano plazo en el escritorio por varias razones:
 

• Aplicaciones y Enfoque pobre para el usuario final. Los procesos de desarrollo de OSS son mucho mejores para resolver cuestiones individuales de componentes que para resolver escenarios de integración, tales como facilidad de uso de principio a fin.

• Los costos del cambio para la base instalada del sector de escritorio. El cambiar de desktop es difícil y el retador debe ser capaz de obtener una ventaja marginal significativa. Los procesos de Linux están más enfocados a ventajas de los que siguen (e.g. copiar lo que ha demostrado funcionar) y por lo tanto es incapaz de proporcionar al retador una ventaja suficiente para proporcionar un ímpetu de cambio.

• La herencia de UNIX frenará la invasión. La facilidad de uso debe ser construido a partir de cero. La orientación de hacker de Linux quizá nunca proporcione los requierimientos de facilidad de uso para el usuario promedio de escritorio.

• Netscape Communicator = versión comercial, ligeramente modificado de Mozilla (cuya página está fijada por default en http://home.netscape.com ).

A diferencia del GPL total, Netscape se reserva el derecho final de rechazar/forzar modificaciones sobre el código fuente de Mozilla, y los ingenieros de Netscape son designados como "Directores de Areas" de los componentes principales (por ahorita).

Fortalezas

Capitaliza el Sentimiento anti-Microsoft en la Comunidad OSS

Con respecto a los demás proyectos OSS, se considera a Mozilla como uno de los ataques más directos y de corto plazo en contra de Microsoft. Este factor es probablemente el factor aglutinador principal para motivar a los desarrolladores a participar dentro del código fuente de Mozilla.

Credibilidad Renovada

La disponibilidad del código fuente de Mozilla ha renovado la credibilidad de Netscape en el ámbito de los navegadores hasta cierto punto. Como lo señala Bharat en http://ie/specs/Mozilla/default.html:

 
"Ellos han garantizado, al publicar su código, que éste nunca desaparecerá del horizonte de manera tan completa como lo hizo WordStar. Los navegadores Mozilla sobrevivirán bastante bien durante los próximos 10 años, aún si disminuye la base de usuarios."

Despiertan una Gran Curiosidad

El navegador es ampliamente usado/diseminado. Por lo tanto, el universo de personas que pueden estar dispuestas a resolver "un problema inmediato a la mano" y/o reparar un error es bastante alto.

Debilidades

Desarrollo posterior a la paridad

Mozilla ya está cercana a la paridad con IE4/5. Por lo tanto no existe un ejemplo fuerte para ayudar a coordinar de manera implícita el equipo de desarrolladores.

Netscape ha asignado a algunos de sus mejores desarrolladores hacia la tarea de tiempo completo de administrar la base de código fuente de Mozilla, y va resultar interesante ver si esto ayuda a la capacidad de Mozilla para ganar nuevo terreno.

Noósfera Reducida

Una debilidad interesante es el tamaño de la "Noósfera" remanente del navegador OSS.
 

1. El navegador por sí mismo está en esencia terminado.

2. Los intereses comerciales de Netscape disminuyen los efectos de las contribuciones de la Noósfera.

• Continuar quedándose a la zaga de IE a largo plazo.

Manteniendo en mente el hecho de que el código fuente fue publicado hace poco tiempo (Abril del 98), ya existe evidencia de la disminución del interés en Mozilla. Se encontró evidencia extremadamente no científica de la disminución del volumen de la lista de correo en las listas de Mozilla de Abril a Junio.

Las listas internas de correo de Mozilla pueden encontrarse en http://egg.Microsoft.com/wilma/lists.

Apache

Historia

Extraído de http://www.apache.org/ABOUT_APACHE.html.

En febrero de 1995, el software de servidor más popular de la Web era el demonio HTTP de dominio público desarrollado por NCSA, Universidad de Illinois, Urbana-Champaign. Sin embargo, se llegó a un alto de ese demonio de httpd a partir de a mediados de 1994, y muchos webmasters tuvieron que desarrollar sus propias extensiones y composturas de errores que necesitaban una distribución común. Un pequeño grupo de webmasters, conectados por correo electrónico privado, se reunieron con el propósito de coordinar sus cambios (en la forma de "parches"). Para finales de febrero de 1995, 80 desarrolladores centrales formaron el grupo fundador del Grupo Apache original. En abril de 1995, se publicó el Apache 0.6.2.

Durante mayo-junio de 1995, se desarrolló una nueva arquitectura de servidor (cuyo nombre clave era Shambhala), el cual incluía una estructura modular y API para una mejor extensibilidad, administración de memoria por bancos y un modelo adaptativo antiescisionista del proceso. El grupo se cambió a esta nueva base del servidor en Junio y le agregaron características del 0.7.x, lo que resultó en el Apache 0.8.8 (y sus descendientes) en agosto.

Poco después del año de fundación del grupo, el servidor de Apache había rebasado al httpd de NCSA como servidor número uno del Internet.

Organización

El equipo de desarrollo de Apache consiste de 19 integrantes centrales, además de cientos de administradores de servidores de Web alrededor de todo el mundo, quienes han sometido reportes de errores o parches de una forma u otra. Los datos de los errores de Apache pueden encontrarse en: http://bugs.apache.org/index.

Una descripción de la administración del código y de los procedimientos de solución de conflictos seguidos por el equipo de Apache pueden encontrarse en http://www.apache.org.

Liderazgo:

Existe un grupo central de proponentes (llamados de manera informal "centrales"), el cual fue formado por fundadores del proyecto y que aumenta de tiempo en tiempo cuando los miembros centrales proponen desarrolladores sobresalientes y el resto del grupo central está de acuerdo. Solución de conflictos:

Los cambios al código son propuestos a la lista de correos, y generalmente son votados por los integrantes activos - se requiere de tres votos +1 (afirmativos) y ningún voto -1 (negativos, o vetos) para integrarlo a la modificación del código durante su ciclo de publicación.

Fortalezas

Porción del Mercado:

Apache es, por mucho, el servidor de Web número 1 en el Internet actualmente. La posesión de la mayor parte del mercado le proporciona un control extremadamente poderoso sobre la evolución del mercado.

En particular, la porción del mercado de Apache en el ámbito de los servidores de Web presentan las siguientes desventajas:

El protocolo de mínimo común denominador HTTP reduce nuestra capacidad de extender el protocolo para dar soporte a nuevas aplicaciones.

• Le dio nueva vida a UNIX. Donde quiera que Apache vaya, UNIX debe de ir con él.

Soporte de Terceras Personas

El número de herramientas/módulos/plug-ins disponibles para Apache han estado aumentando cada vez más.

Debilidades

Desempeño

En el corto plazo, el IIS vence de manera razonable a Apache sobre SPECWeb. A medida que pasa el tiempo, y a medida que el IIS se integra al kernel y toma ventaja de una mayor integración con NT, se espera que esta ventaja aumente.

A diferencia de esto, Apache está limitado por el requierimiento de que esté escrito en un código portable a todos los ambientes del OS.

Complejidad del Protocolo HTTP y Servicios de Aplicación

Parte de los motivos por los cuales Apache fue capaz de poder ocupar un buen punto de arranque y despegar fue debido a que el protocolo HTTP es demasiado sencillo. A medida que sumen cada vez más características sobre el humilde servidor de Web (e.g. soporte de transacciones multiusuarios, POD, etc.) será interesante ver como va a ser capaz de mantener el paso el equipo de Apache.

Por ejemplo, el soporte de ASP es un manejador central para IIS en las intranets corporativas.

IBM y Apache

Recientemente, IBM anunció su soporte para la base de código de Apache en su aplicación de servidor WebSphere. Sin embargo, todavía no es claro el resultado del furor de la prensa.
 

• IBM todavía manda y da soporte a los servidores de Web Apache y Domino GO.

• El compromiso de IBM parece ser:

• Ayudar a Apache a portar a plataformas IBM estratégicas (AS/400, etc.).

• Redistribuir los binarios de Apache a consumidores que solicitan soporte de Apache.

• Soporte para binarios de Apache (¿sólo si fuesen adquiridos a través de IBM?).

• IBM tiene desarrolladores participando de manera activa en los grupos de discusión/desarrollo de Apache.

• IBM ha tomado el papel principal para optimizar Apache para NT.

Algunos Otros Proyectos OSS
 

• GIMP - http://www.gimp.org - GIMP (Programa GNU para Manipulación de Imágenes) es un proyecto OSS para crear un clon de Adobe Photoshop para las estaciones de trabajo UNIX. Sin embargo, según las características que tienen, su versión 1.0 es más semejante a PaintBrush.

• WINE/WABI - http://www.wine.org - Wine (Wine no es un Emulador) es una librería de emulación de ventanas de OSS para UNIX. Wine compite (en algunos aspectos) con el proyecto WABI de Sun, el cual no es OSS. Por ejemplo, las versiones más anticuadas de Office son capaces de correr en WINE, aunque tendría que evaluarse su desempeño.

• PERL - http://www.perl.org - PERL (Lenguaje Práctico de Evaluación y Reporte) es el lenguaje de facto para realizar scripts en los servidores de Web Apache. PERL es muy popular en UNIX en especial debido a su poderosa manipulación de textos y cadenas de caracteres y a que UNIX se basa en administración por comandos para toda su funcionalidad.

• BIND - http://www.bind.org - BIND (Demonio de Nombres de Internet de Berkeley) es el servidor de DNS de facto en internet. En muchos sentidos, se desarrolló el DNS a partir del BIND.

• Sendmail - http://www.sendmail.org - Sendmail es actualmente el agente de transferencia de correo número 1 de Internet.

• Squid - http://ww.squid.org - Squid es un servidor Proxy OSS basado en el protocolo ICP. Squid es algo popular entre los ISP internacionales grandes, a pesar de que tiene problemas en su desempeño.

• SAMBA - http://www.samba.org - SAMBA proporciona un servidor SMB de archivos de UNIX. Recientemente, el equipo de SAMBA ha podido realizar ingeniería en reversa y desarrollar un controlador de dominio de NT para UNIX. SGI tiene contratado a uno de los líderes de SAMBA (Para finales de este año, Samba será capaz de reemplazar totalmente todas las funciones primarias de Windows NT Server (http://www.sonic.net/~roelofs/reports/linux-19980714-phq.html)).

• KDE - http://www.kde.org - (Ambiente de Escritorio K). Combina un navegador, un shell y una suite de office integrado para desktops UNIX. Revise las muestras en http://www.kde.org/kscreenshots.html y http://www.kde.org/koffice/index.html

• Majordomo - El servidor de listas de correo dominante en Internet, que está escrito en su totalidad en PERL vía OSS.

Vulnerabilidades de los Productos

¿Por dónde será más probable que Microsoft sienta presión por parte de los proyectos de OSS?

Servidor vs. Cliente

El servidor es más susceptible de ser vulnerable a los productos OSS que el cliente. Entre las razones expuestas están las siguientes:
 

• Los cambios de tareas de los consumidores son más frecuentes - el consumidor promedio de escritorio está acostumbrado a una mayor variedad de aplicaciones que el del servidor. Por lo tanto, la integración, la facilidad de uso, etc. son características clave.

• Los servidores son más específicos a las tareas - Los productos OSS trabajan mejor si los objetivos/precedentes están claramente definidos (e.g. haciendo utilizables los protocolos estándares).

• Los servidores estándares tienen un menor compromiso que sus consumidores - El reemplazar servidores estándar tales como de archivo, impresión, de relevo de correos, etc. con alternativas de software abierto no interfiere conla experiencia del usuario final. Además, en estos servicios estándares, una solución "experimental", "desechable" será aplicado más frecuentemente por una organización.

• Los servidores están administrados de manera profesional - Esta es una de las ventajas del OSS en la personalización y mediatiza la debilidad de la carencia de facilidad de uso por parte del usuario final.

Cómo capturar los beneficios del OSS - Socialización de los Desarrolladores

La capacidad de los procesos OSS de reunir y hacer efectivo un coeficiente intelectual colectivo de miles de individuos sobre el Internet es simplemente sorprendente. Lo que es más importante, la evangelización del OSS aumenta con respecto al tamaño del Internet mucho más rápida que nuestros propios esfuerzos de evangelización.

{ Esto es, Microsoft está siendo superado en capacidad intelectual y comercial por el Software Abierto - ¡y lo sabe! }

¿Cómo puede Microsoft capturar alguna parte de la exuberante capacidad intelectual para enfocarse sobre los productos OSS?

Entre las ideas iniciales que se tienen están:
 

• Capturar los beneficios de la depuración en paralelo mediante un licenciamiento más amplio - El ser más liberal al proporcionar licencias de códigos fuentes para NT a organizaciones tales como las universidades y algunos socios.

• Proporcionar herramientas de entrada de bajo costo o gratuitos -El efecto secundario de las herramientas es generar una capacidad/vocabulario común que los desarrolladores pueden sacar provecho. Como lo señala NatBro, la amplia disponibilidad de un conjunto consistente de herramientas de desarrollo en Linux/UNIX es un medio crítico para coordinar de manera implícita el sistema.

• Publicar partes del código fuente - Tratar de generar el interés de los hackers de agregar valor a las bases del código fuente de MS. Un primer candidato podrían ser partes del stack de TCP/IP. Sin embargo, como lo señala OshM, el reto es encontrar alguna parte del código fuente de MS que sea capaz de generar la noósfera con la masa crítica suficiente para generar interés.

• Proporcionar mayor extensibilidad - El desarrollador entusiasta de Linux es amante de comprender API y partes internas sin documentar. La documentación/publicación de algunos API internos como "sin soporte" puede ser un medio de generar innovaciones externas a los que podríamos sacar provecho. En particular, al asegurar una mayor cantidad de componentes para una mayor cantidad de equipos para que sean scripteables/automatizables para asegurar que los usuarios puedan jugar con nuestros componentes.

• Crear una Comunidad/Noósfera. El MSDN llega a una población extremadamente grande. ¿Cómo podemos crear las estructuras sociales que proporcionen beneficios en la red para sacar provecho de esta gigantesca base de desarrolladores? Por ejemplo, ¿qué pasaría si tuviésemos un muestrario de VB en Microsoft.com que permitiese a los desarrolladores de VB postear y publicar su código fuente de sus proyectos de VB para compartirlos con otros desarrolladores de VB? Yo pienso que muchos desarrolladores en VB tendrían una enorme gratificación a su ego del hecho de que pudiesen tener su nombre/código para que se pudiese baja de Microsoft.com.

• Monitoreo de grupos de noticias de OSS. Aprender nuevas ideas y contratar a los mejores o más brillantes individuos.

Capturando los beneficios del OSS para los procesos internos de Microsoft

¿Qué es lo que puede aprender Microsoft del ejemplo del OSS? Dicho de manera más concreta: ¿Cómo podemos nosotros reconstruir el ambiente de desarrollo de OSS? Diferentes analistas de este artículo han señalado de manera consistente que internamente deberíamos ver a Microsoft como una comunidad OSS idealizada, pero por varias razones no lo somos:

Diferentes métodos de desarrollo. El construir un ambiente de desarrollo/construcción de NT es extremadamente complejo, y radicalmente diferente del ambiente utilizado por el equipo de Office.

Diferentes herramientas/administradores de código fuente. Algunos equipos usan SLM, otros usan VSS. Diferentes bases de datos de depuración. Diferentes procesos de construcción.

Ningún acceso central de depósito de código. No existe un conjunto central de servidores para buscar, instalar y revisar el código de nuestros proyectos más allá del alcance inmediato. Incluso, el proporcionar un depósito central para los símbolos de depuración constituirían un enorme beneficio. NatBro afirma que:
 

"Un desarrollador que trabaja en Microsoft sobre el OS no puede estimular su curiosidad. Ellos ya tiene Excel. Tampoco puede desarrollar su curiosidad el desarrollador de Excel con el SO. Le llevaría meses el entender cómo construir, depurar e instalarlo, y es probable que de todos modos no tenga acceso al código fuente apropiado.

Mayor comunicación entre desarrolladores. Las listas de correo que tratan sobre componentes en particular y reportes de errores están generalmente disponibles solamente para integrantes del equipo.

Mayor robustez de los componentes. Linux y otros proyectos de OSS hacen más fácil a los desarrolladores el experimentar con componentes pequeños sin introducir regresiones hacia otros componentes: DavidDs afirma que:
 

"Las personas que trabajan con sus partes de manera independiente del resto, de manera tal que el resto son abstracciones internas entre componentes son mejor documentadsa y mejor expuestas/exportadas, así como más robustas, debido a que no tienen idea para lo que pueden ser llamadas. El sistema de desarrollo de Linux ha evolucionado al permitir más partes participar, sin causar la enorme cantidad de problemas de integración, debido a que la robustez está presente en cada nivel. Esto es maravilloso, dirigido a largo plazo, hacia la estabilidad global, y el SO lo muestra."

Por supuesto, el secreto en este caso es capturar estos beneficios sin tener que solventar los costos de los procesos OSS. Estos costos son típicamente los obstáculos puestos en primer lugar:
 

• Integración. Un desarrollador de tiempo completo sobre un componente tiene mucho trabajo por hacer antes de analizar e integrar composturar de otros desarrolladores dentro de la compañía.

• Costos y dependencias iterativas. El potencial de divisiones minúsculas entre versiones borrador del SO siendo utilizados por un desarrollador y el SO central utilizado por un desarrollador de Excel diferente.

Ampliando los beneficios del OSS - Infraestructura de Servicios

El soporte de una comunidad de plataforma y desarrollo requiere de una gran cantidad de infraestructura de servicio que no puede proporcionar el OSS. Entre estos están los PDC, MSDN, ADCU, ISVs, IHVs, etc.

Las comunidades OSS, que son el equivalente de MSDN, son una conferederación amplia de sitios de Web con documentación de API de calidad variable. MS tiene la oportunidad de explotar realmente la Web para la evangelización de los desarrolladores.

Mediatizando los Ataques del OSS

Generalmente, Microsoft triunfa al atacar la debilidad central de los proyectos OSS.

Desestandarizar los protocolos y las aplicaciones

Los proyectos OSS han sido capaces de ganarse un punto de entrada en muchas aplicaciones de servidor debido a la amplia utilización de protocolos sencillos y estandarizados. Al extender estos protocolos y desarrollar nuevos protocolo, podemos evitar la entrada de los proyectos de OSS al mercado.

David Stutz realiza un excelente comentario: cuando se compite con el nivel de integración en el desktop con Microsoft "La estandarización de protocolos en realidad se convierten en el medio de integración" para los proyectos OSS. Existe una gran cantidad de coeficiente intelectual que está siendo invertido en varios grupos de trabajo de IETF, quienes están creando rápidamente un modelo de arquitectura para la integración de estos proyectos OSS.

{ En otras palabras, se deben encerrar los protocolos abiertos y se debe aplastar a IETF para poder "desestandarizar los protocolos y aplicaciones" y detener al software abierto.

Una vez más, la mejor respuesta de los entusiastas del software abierto ha sido señalar a los consumidores cuando se está "desestandarizando" que es en donde los vendedores ganan y los clientes pierden. }

Algunos ejemplos de iniciativas de Microsoft en las que se está extendiendo los protocolos estandarizados son los siguentes:
 

• Integración del DNS con el Directorio. Manejando el Servicio de Directorio para agregar valor al DNS mediante actualizaciones dinámicas, seguridad y autentificación.

• HTTP DAV. El DAV es complejo, y la especificación del protocolo proporciona un nivel infinito de complejidad en la implementación para varias aplicaciones (e.g. el diseño del intercambio sobre DAV es bueno, pero ciertamente no es el único diseño obvio). Apache se verá presionado a adoptar y elegir las primeras áreas correctas de DAV a implementar.

• MSMQ para Aplicaciones Distribuidas. MSMQ es un excelente ejemplo de tecnología distibuida, en la que la mayor parte del valor reside en los servicios y en la implementación y NO en el protocolo de transmisión. Lo mismo es verdadero para MTS, DETC y COM+.

Hacer que la Integración sea Obligatoria - Especialmente en el ámbito del servidor

El surgimiento de servidores especializados es especialmente potente, y coloca una amenaza a largo plazo que afecta directamente a nuestros ingresos. Una de las claves para combatir esta amenaza es crear escenarios de integración que sean valiosos sobre la plataforma del servidor. David Stutz señala que:
 

El asunto de fondo aquí es que, quienquiera que tenga las mejores tecnologías y procesos de integración orientadas hacia la red será el que gane el negocio estándar de servidores. Existe una convergencia de sistemas anidados, conectividad móvil y protocolos persuasivos de red que harán que el número de servidores aumente de manera drástica (especialmente "servidores especialistas"?). El consumidor de uso cotidiano es un buen negocio para estar en él -- ¿Será este negocio reducido a migajas por negocios de servidores estándar de propósito especializado?

Administración del Sistema. La funcionalidad de la administración del sistema puede en teoría tocar todos los aspectos de un producto/plataforma. Por lo tanto, esto no es algo que pueda ser derivado fácilmente hacia una base de código existente de una manera dividida en componentes. Esta debe ser diseñado desde cero o debe ser el resultado de una revaloración consciente de todos los componentes dentro de un proyecto dado.

Facilidad de Uso. Así como la administración, ésta frecuentemente se tiene que diseñar desde cero, y por lo tanto requiere de un gran costo de manejo de desarrollo. Los proyectos OSS tendrán problemas de manera consistente para dar el ancho en esta rubro.

Escenarios de Solución. ZAW, redes por línea telefónica, wizards, etc.

Integración de Clientes. ¿Cómo podemos sacar de la base de clientes para proporcionar requerimientos similares de integración en nuestros servidores? Por ejemplo, MSMQ, como un software intermediario requiere de un código de cliente y servidor muy sincronizados.

El control del software intermediario es crítico. Obviamente, a medida que se hace necesario la estandarización de los riesgos de mayor orden para mantener los m'argenes de ganancia dentro del negocio de los servidores OS.

Credibilidad Organizativa

Procesos de Publicación y de Service Pack. Al consolidar y mantener la ardua tarea de mantener las composturas m'as recientes, Microsoft proporciona una ventaja clave al consumidor para los procesos básicos de OSS.

Compromiso a Largo Plazo. Mediante herramientas tales como acuerdos con empresas, investigaci'on a largo plazo, notas ejecutivas, etc., Microsoft es capaz de comprometerse a una visi'on a largo plazo y crear un mayor sentido de orden a largo plazo que los procesos OSS.

Otras ligas interesantes

http://www.lwn.net/ -- Publica resúmenes semanales del mundo de desarrollo de Linux.

http://slashdot.org/ -- discusión y noticias diarias dentro de la comunidad OSS.

http://www.linux.org

http://www.opensource.org

http://news.freshmeat.net/ -- Información sobre las publicaciones y actualizaciones más recientes de software abierto.

Agradecimientos:

Muchas personas proporcionaron, se~nalaron, corroboraron el documento y proporcionaron correo electr'onico interesantes puntos de vista sobre este documento y sobre Linux.

Nat Brown

Jim Allchin

Charlie Kindel

Ben Slivka

Josh Cohen

George Spix

David Stutz

Stephanie Ferguson

Jackie Erickson

Michael Nelson

Dwight Krossa

David D¡¯Souza

David Treadwell

David Gunter

Oshoma Momoh

Alex Hopman

Jeffrey Robertson

Sankar Koundinya

Alex Sutton

Bernard Aboba

Historia de la Revisión