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 X Software de Prueba Software de Uso No Comercial
Revisión Todos los Código Código Pública Uso derivados Redistribuible Fuente Fuente al Ilimitado deben ser Disponible Modificable código gratuitos fuente
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. Software de Prueba 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. Shareware 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. Software de Uso No Comercial 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. Binarios Gratuitos 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. Librerías Gratuitas 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. Fuente Abierta (Estilo BSD) 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. Fuente Abierta (Estilo Apache) 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. Fuente Abierta (Estilo GNU/Linux) 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 Kernel de Linux (sólo x86)
Número de Líneas de Código 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. 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. { 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. } 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ónretroalimentació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