Traducido por:
José Soto Pérez
jsoto@labpar.fcfm.buap.mx
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. }
 


 

Vinod Valloppillil (VinodV)
Agosto 11, 1998 -- v1.00
Microsoft Confidential



 
 
 
 
 
 
 

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 *
 
 
 


 
 
 
 

Software Abierto
Una Metodología (¿Nueva?) de Desarrollo



 
 
 

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

Tipo de Software
             
Comercial
             
Software de Prueba
X

(sin todas las características)

X
         
Software de Uso No Comercial
X

(dependiente del usuario)

X
         
Shareware
X

(Licencia sin enforzamiento)

X
         
Binarios Gratuitos (Freeware)
X
X
X
       
Librerías Gratuitas
X
X
X
X
     
Fuente Abierta (estilo BSD)
X
X
X
X
X
   
Fuente Abierta (Estilo Apache)
X
X
X
X
X
X
 
Fuente Abierta (Estilo Linux/GNU)
X
X
X
X
X
X
X
Características de la Licencia Precio Cero Redistribuible Uso Ilimitado Código Fuente Disponible Código Fuente Modificable Revisión Pública al código fuente Todos los derivados deben ser gratuitos
Estas características amplias de licenciamiento incluyen:
 
  • Software Comercial
  • El software comercial el pan de cada día de Microsoft. Este software debe ser comprado, NO puede ser redistribuido, y típicamente pone a disposición del usuario final sólo los binarios.
    El software de prueba son generalmente versiones limitadas de software comercial que es distribuida libremente y cuya intención es la compra del código comercial. Como muestra de ello está el software de 60 días de evaluación.
    Los productos de software son totalmente funcionales y no tienen restricciones en cuanto a su distribución, pero existe una licencia que obliga eventualmente a los individuos y a las corporaciones a la compra del software. Muchas utilerías del Internet (tales como WinZip) toman ventaja de este método de distribución.
    El software de uso no comercial está disponible sin limitaciones, y se puede redistribuir por parte de entidades sin fines de lucro. Las corporaciones deberán adquirir este producto. Un ejemplo de esto sería Netscape Navigator.
    Los binarios gratuitos consisten de software cuyo binario se puede usar y distribuir libremente. Los binarios del Internet Explorer y NetMeeting entran dentro de este modelo.
    Las librerías gratuitas son productos de software cuyos binarios y fuentes pueden ser utilizados y distribuidos libremente, pero no pueden ser modificados por el usuario final sin violar la licencia. Ejemplos de esto son las librerías de clase, etc.
    Un pequeño y cerrado equipo de desarrolladores estilo BSD desarrolla productos de software abierto y permite el libre uso y redistribución de binarios y códigos. A pesar de que los usuarios pueden modificar el código, el equipo de desarrollo generalmente NO revisa lo que aporta el público.
    Apache asume el modelo de desarrollo de software abierto de BSD y lo extiende al permitir revisiones al código fuente por parte de terceras personas.
    El software basado en el GPL (Licencia Pública General) lleva la licencia de Software Abierto un paso crítico más allá. Mientras que el software estilo BSD y Apache permiten a los usuarios utilizar el código base y aplicar sus propios términos de licencia al código modificado (e.g. hacerlo comercial), la licencia GPL obliga que todos los trabajos derivados sean a su vez código GPL. "Eres libre de hackear este código en tanto que tu derivado es también hackeable."
    { Es interesante hacer notar cómo estas últimas tres diferencias parten del contexto de cómo la ve la comunidad de software libre.

    Para nosotros, el licenciamiento del software libre y los derechos que les proporciona a los usuarios y a terceras personas son centrales, y que la práctica de desarrollo varía ad hoc de una manera que no está amarrada a cualquiera de las variaciones de nuestras licencias. Por otro lado, dentro de esta taxonomía de Microsoft, la diferenciación central es quien tiene el privilegio de escribir en el código base.

    Esto refleja un punto de vista mucho más centralizado de la realidad, y refleja la falta de imaginación o comprensión de parte de los autores del memorándum. El no entiende a cabalidad nuestra tradición de desarrollo distribuido. Esto no causa la menor sorpresa... }

    El OSS es Importante para Microsoft

    Este documento se centra sobre el Software Abierto (OSS). El OSS es radicalmente diferente de otras formas de licenciamiento (en especial, del shareware) en dos aspectos muy importantes:
     

  • Siempre existe un camino de adquisición completamente gratuito del código base.
  • A diferencia de los binarios libremente distribuidos, el Software libre estimula un proceso alrededor del cual está el código base y estimula las extensiones del código base por parte de otros desarrolladores.

  • El OSS es una preocupación para Microsoft por varias razones:

    1. Los proyectos OSS han logrado calidad comercial.
     

    Una de las principales barreras para el OSS en muchos ambientes de clientes es que se ha percibido una falta de calidad. Los entusiastas del OSS plantean, en cambio, que una mayor revisión y depuración del código del software OSS da como resultado un código de mayor calidad que el de software comercial.
    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). }
    2. Los proyectos de OSS se han convertido en proyectos a gran escala y complejidad  
    Otra barrera que ha sido abordada por el OSS es la complejidad del proyecto. Los equipos de desarrollo de OSS están llevando a cabo proyectos cuyo tamaño y complejidad había sido hasta ahora el dominio exclusivo de equipos de desarrollo comerciales, organizados o motivados por intereses comerciales. Ejemplo de estos lo constituyen el Sistema Operativo Linux y el XFree86 GUI.
    El proceso de OSS está vitalmente relacionado con el Internet para proporcionar los recursos distribuidos de desarrollo a una escala gigantesca. Algunos ejemplos de los tamaños de los proyectos de OSS son :
    Proyecto
    Número de Líneas de Código
    Kernel de Linux (sólo x86)
    500,000
    Servidor de Web Apache
    80,000 
    SendMail
    57,000
    Servidor de Desktop XFree86
    90,000
    Distribución Completa de Linux
    ~ 10 millones

     
    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.
  • { Es muy interesante el hecho de que el autor reconoce este hecho, pero no prosigue la discusión en el sentido de la internacionalización de Linux, o la extensión del éxito que tiene Linux en ultramar (especialmente en Europa) está siendo llevada a cabo por el miedo a la dominación tecnológica de los Estados Unidos. Esta omisión puede representar un punto ciego que se puede explotar dentro de la estrategia de Microsoft. }
    {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.
    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
    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.
    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.
    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.
    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.
    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
  • { El contraargumento más fácil y más obvio para esto es señalar que Microsoft es bastante malo para la "facilidad de uso de principio a fin"; para lo que es bueno es para crear sistemas que a primera vista parecen tener calidad, pero que en realidad no lo tienen (y, a medida que pasa el tiempo, tienen un costo total mucho más alto en productividad perdida por errores y características faltantes que lo que tiene Linux).

    Aunque esto es cierto, este planteamiento evade una cuestión importante - el que el filisteismo de Microsoft sobre este rubro no hace que la crítica sea menos válida. El desarrollo de software abierto es bastante pobre en cuanto a la solución de este tipo de cuestiones, ya que no involucra una serie sistemática de pruebas de facilidad de uso con gente que no es hacker.

    Esto realmente va a retardar el avance de Linux sobre el escritorio. Sin embargo, esto no va a constituir obstáculos permanentes - no si esfuerzos tales como GNOME y KDE tienen el tiempo suficiente para madurar.}

    { Existe una suposición oculta de que la innovación y la "ventaja del vanguardista" son las únicas maneras de mitigar el costo percibido de cambio. Esta es una suposición peligrosa para Microsoft; puede ser que la confiabilidad y estabiliadad superior de Linux sea suficiente.

    Suponiendo sin conceder lo que afirma el autor, la posibilidad de que Linux pueda obtener una ventaja del retador suficiente no está asegurado a menos que el modo de software abierto sea incapaz de generar innovación - y nosotros sabemos que esto no es cierto. }

    { Mis comentarios anteriores sobre la ingeniería sobre la facilidad de uso, y la manera en que aborda la comunidad del software abierto este problema, se aplican aquí. Debemos de quitarle el fundamento a Microsoft al construir sistemas que usen software abierto para el soporte de usuarios, para que evolucionen en sus ambientes hacia el óptimo, de la misma manera en que lo realiza la Web. }


    Derrotar a Linux

    Además de atacar la debilidad general de los proyectos OSS (e.g. costos de arquitectura e integración), algunos ataques específicos a Linux son:
     


    Todas las tácticas estándares de productos de NT vs. Sun aplican para Linux.

    Hacer funcionalidades extendidas en servicios/protocolos comercializables y crear nuevos protocolos.

    La base de Linux es actualmente la infraestructura cotidiana de red y servidores. Al hacer la funcionalidad extendida comercializable ahora (e.g. mayor capacidad de almacenamiento en los sistemas de archivos, DAV/POD para las interfaces de red), elevamos la barrera y cambiamos las reglas del juego.

    { Aquí, como en el comentario anterior de cómo puede ganar Linux, podemos comenzar a ver como emerge un esbozo general de la estrategia de Microsoft de la neblina del ambiente corporativo. De hecho, no es bonito, sino que es lo suficientemente feo para hacerlo apropiado para publicarlo el día de Halloween.

    Lo que el autor está planteando es nada más y nada menos que tratar de subvertir toda la infraestructura "comercializable de redes y servidores" (entre ellas, TCP/IP, SMTP, HTTP, POP3, IMAP, NFS y otros estándares abiertos) para usarlos como protocolos, los cuales, a pesar de ser homónimos, podrían subvertir los dispositivos de control de consumidores y mercados para Microsoft (esto es lo que el autor realmente plantea cuando él exhorta a Microsoft a "elevar la barrera y cambiar las reglas del juego").

    El "comercializar funcionalidad extendida" es aquí un eufemismo para introducir extensiones no estandarizadas (o protocolos alternativos) que posteriormente son comercializados como estándares, aún cuando sean cerrados, con falta de documentación o con justo la suficiente para crear una ilusión de ser abiertos. El objetivo es hacer que los nuevos protocolos sean una lista de chequeo para consumidores corporativos guibles, mientras que simultáneamente hace que el desarrollar simbiotas de terceras partes para los programas de Microsoft sea poco menos que imposible. (Y cualquiera que tenga éxito será comprado.)

    Este juego se le conoce como "abrace y extienda". Hemos visto a Microsoft jugar este juego antes, y son bastante buenos en hacerlo. Cuando funciona, Microsoft gana un seguro de monopolio. Los consumidores pierden.

    Los entusiastas del software abierto pueden responer al señalar exactamente por qué y cómo pierden los consumidores (reducción de la competencia, elevación de los costos, disminución de la confiabilidad, pérdida de oportunidades). Los entusiastas del software abierto también pueden puntualizar esto al mostrar lo contrario - esto es, cómo aumentan las fuentes y estándares abiertos la competencia entre vendedores, disminuyen los costos, aumentan la confiabilidad y crean oportunidades.

    Una vez más, como lo reconoció Microsoft anteriormente, el Internet es nuestro hijo. Nuestra mejor acción para luchar contra el "abrace y extienda" es señalar que Microsoft está intentando cerrar el Internet. }

    En un intento de renovar su credibildiad en el ámbito de los navegadores, Netscape ha publicado recientemente, y está intentando crear una comunidad OSS alrededor de su código fuente de Mozilla.

    Netscape

    Organización y Licenciamiento

    La organización y modelo de licenciamiento de Linux está débilmente basado en la comunidad de Linux y el GPL con algunas cuantas diferencias. Primero, Mozilla y Netscape Communicator son dos códigos fuente con los ingenieros de Netscape que proporcionan la sincronización.
     

  • Mozilla = el browser distribuible libremente.
  • Ya no existen segmentos grandes, de amplio perfil para el cual puede desarrollarse un navegador por sí mismo. En otras palabras, Netscape ya ha resuelto el 80% interesante de este problema. Existe poca o nula gratificación para el 20% restante del código de Netscape.
      1. Los intereses comerciales de Netscape disminuyen los efectos de las contribuciones de la Noósfera.
    La administración de Linus Torvalds de la base del código fuente de Linux está dirigido hacia el objetivo de crear el mejor Linux posible. A diferencia de esto, Netscape se reserva de manera expresa el acto de realizar decisiones administrativas sobre la base de los intereses comerciales/mercantiles de Netscape. En vez de crear un producto importante, el código de los desarrolladores está sometido al precio bursátil de Netscape.


    Costos de Integración

    Potencialmente, el obtáculo más grande al que se puede enfrentar el esfuerzo de Mozilla es el nivel de integración que esperan los consumidores de las características de un navegador. Como lo afirmé anteriormente, la integración de desarrollo/prueba NO es una actividad paralelizable, y por lo tanto es lastimado por los procesos OSS.

    Predicciones

    Por lo tanto, las predicciones serán que, a diferencia de los proyectos de Apache y Linux, que son, por ahora, bastante exitosos, el esfuerzo de Mozilla de Netscape va a:
     

  • Producir el navegador dominante de Linux y algunos UNIX.
  • Lista (Privada) de Correo de Mozilla
    Abril de 1998
    Junio de 1998
    % de Disminución
    Petición de Búsquedas
    1073
    450
    58%
    Desarrollo del UI
    285
    76
    73%
    Discusión General
    1862
    687
    63%
    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.

  • Historia de la Revisión
    Fecha
    Revisión
    Comentarios
    8/03/98
    0.95
    8/10/98
    0.97
    Inicio de la tabla de Revisión 

    Añadido de los comentarios de JoshCo

    8/11/98
    1.00
    Algunas correcciones, copias impresas para la revisión de PaulMa.