Chapter 4

A veces, liberar el código puede ser eficaz no sólo como vía para incrementar el mercado sino como maniobra estratégica contra la competencia de una compañía. Puede ser fructífero revisar algunas de las tácticas de negocio descritas antes desde este ángulo; no directamente como generadores de ingresos sino como maneras de introducirse y reformar mercados.

Compartir costes como arma competitiva

Antes consideramos Apache como ejemplo de mejor y más barato desarrollo de infraestructuras mediante la compartición de costes en un proyecto open source. Para los fabricantes de software y sistemas que compiten con Microsoft y su servidor web IIS, el proyecto Apache es también un arma competitiva. Sería difícil, tal vez imposible, para cualquier otro proveedor de servidores web desbancar completamente las ventajas del enorme equipo de guerra de Microsoft y el poder de su monopolio en el mercado de desktop. Pero Apache permite a cada empresa que participa en el proyecto ofrecer un servidor web que es técnicamente superior a IIS y reafirma a los clientes con una cuota de mercado mayoritaria; a un coste muy inferior. Esto mejora la posición de mercado y el coste de producción para los productos de comercio electrónico de valor añadido (como WebSphere de IBM).

Esto es generalizable. La infraestructura abierta y compartida proporciona a sus participantes ventajas competitivas. Una es menor coste por participante para producir productos y servicios vendibles. Otra es una posición de mercado que asegura a los clientes que es mucho menos probable que quede atados a una tecnología huérfana como resultado de una cambio de estrategia o táctica de un proveedor.

Reajustar la competencia

Cuando el desarrollo del sistema open source de ventanas X windows fue financiado por DEC en los 80, su objetivo explícito era “reajustar la competencia”. En aquella época había varios entornos gráficos para Unix que competían, incluyendo especialmente el sistema NeWS de Sun Microsystems. Los estrategas de DEC creyeron (probablemente de manera correcta) que si Sun era capaz de establecer un estándar de gráficos propietario podría cerrar el floreciente mercado de estaciones de trabajo Unix. Financiando X y cediéndole ingenieros, y aliándose con muchos fabricantes más pequeños para establecer X como estándar de facto, DEC fue capaz de neutralizar las ventajas que tenían Sun y otros competidores con mayor experiencia interna en gráficos. Esto desplazó el foco de la competencia en el mercado de estaciones de trabajo hacia el hardware, donde DEC era históricamente fuerte.

Esto también es generalizable. El Open Source es atractivo para los clientes inteligentes, y para aliados potenciales que no son suficientemente grandes como para financiar un desarrollo competitivo por sí mismos. Un proyecto open source, lanzado en el momento adecuado, puede ser mejor que simplemente competir con éxito contra alternativas cerradas; en realidad puede evitar que consigan agarre en el mercado, reajustando la competencia y redirigiéndola desde un área donde la compañía que lo inicia es débil a una donde es fuerte.

Aumentar el estanque

Red Hat Software financió el desarrollo del sistema de paquetes RPM para proporcionar al mundo Linux un instalador de paquetes binarios estándar. Haciendo esto, apostaron por que el incremento de confianza que tal instalador estándar proporcionaría a los clientes potenciales valdría más en ingresos futuros que el coste de desarrollo del software o los ingresos potencialmente perdidos frente a los competidores que también serían capaces de usarlo.

A veces la mejor manera de ser una rana más grande es hacer que la charca crezca más rápido. Esto, por supuesto, es la razón económica de que las empresas de tecnología hayan participado en estándares públicos: y es útil pensar en el software open source como en un estándar ejecutable. Además de ser un excelente creador de mercados, esta estrategia puede ser un arma competitiva directa cuando una compañía pequeña la usa para desplazar la masa y el poder en el mercado de una compañía mucho más grande que no participa en la alianza del estándar. En el caso de Red Hat, el gran competidor obvio y reconocido es Microsoft; la estandarización de RPM en la mayoría de distribuciones Linux aportó mucho para la neutralización de las ventajas que Microsoft había establecido previamente en la sencillez de la administración de sistemas en sus máquinas Windows.

Evitando un chokehold

Al explicar antes el modelo de negocio líder en pérdidas / posicionador de mercado, describí cómo la apertura del código del navegador Mozilla por parte de Netscape fue una maniobra (exitosa) dirigida a evitar que Microsoft bloqueara HTML y el protocolo HTTP.

A menudo, es más importante evitar que su competencia consiga un chokehold en una tecnología particular que controlar la tecnología usted mismo. Abriendo el código, incrementa enormemente el tamaño potencial de su coalición bloqueante.

Open Source y Riesgo Estratégico de Negocio

Al final, las razones por las que el open source parece destinado a convertirse en una práctica extendida tienen más que ver con la demanda de los clientes y las presiones del mercado que con eficiencias del lado de la oferta para los proveedores. Ya he discutido, desde el punto de vista del proveedor, los efectos de la demanda de los clientes de fiabilidad y de infraestructuras sin un único jugador dominante, y cómo éstos han jugado históricamente en la evolución de las redes. Hay más que decir, sin embargo, sobre el comportamiento de los clientes en un mercado en el que el open source es un factor.

Colóquese por un momento en la situación de un Director de Tecnología en una compañía del Fortune 500 que piensa si construir o actualizar una de las infraestructuras IT de su firma. Quizá necesita elegir un sistema operativo de red para desplegarlo en toda la empresa; quizá su preocupación implica un servicio web y de comercio electrónico 24x7; quizá su negocio dependa de que sea capaz de soportar transacciones de bases de datos de alto volumen y alta fiabilidad.

Suponga que sigue el camino tradicional del código cerrado. Si lo hace, coloca a su firma a la merced del monopolio de un suministrador: porque por definición, hay sólo un lugar al que ir para obtener soporte, corrección de errores y mejoras. Si el suministrador no responde, no tendrá ningún recurso eficaz porque se encontrará atrapado por su inversión inicial y los costes de formación. Su suministrador lo sabe. Bajo estas circunstancias, ¿supone que el software cambiará para ajustarse a sus necesidades y su plan de negocios... o las necesidades de su proveedor y el plan de negocios de su proveedor?

La brutal verdad es esta: cuando sus procesos de negocio clave se ejecuten mediante bloques opacos de bits que ni siquiera puede ver (ni mucho menos modificar) habrá perdido el control de su negocio. Necesitará a su proveedor más que su proveedor le necesita a usted; y pagará, y pagará, y pagará otra vez por este desequilibrio de poder. Pagará en precios más altos, pagará en oportunidades perdidas y pagará en trampas que se hacen cada vez peores según el proveedor (que ha refinado su juego en un montón de víctimas anteriores) aprieta el lazo.

Compare esto con la opción open source. Si sigue esta ruta, usted tiene el código fuente, y nadie puede quitárselo. En lugar del monopolio de un proveedor con un chokehold en su negocio, ahora tiene varias compañías de servicios que ofertan por su negocio; y no sólo consigue que compitan entre ellas, sino que tiene la opción de construir su propia organización de soporte interna si eso parece menos caro que contratar a terceros. El mercado trabaja para usted.

La lógica es convincente; depender de código cerrado es una riesgo estratégico inaceptable para el negocio. Tanto que creo que no pasará mucho hasta que la compra de código cerrado a un único proveedor cuando haya una alternativa open source disponible se verá como una irresponsabilidad fiduciaria real, y una base para un litigio por parte de los accionistas.

La Ecología de Negocios del Open Source

La comunidad open source se ha organizado a sí misma de una manera que tiende a amplificar los efectos de productividad del open source. En el mundo Linux, en particular, es un hecho económicamente significativo que hay varios distribuidores de Linux que forman una capa distinta de los desarrolladores.

Los desarrolladores escriben código, y hacen el código disponible por Internet. Cada distribuidor selecciona algún subconjunto del código disponible, lo integra, lo empaqueta, pone su marca y lo vende a los clientes. Los usuarios eligen entre distribuciones, y pueden complementar una distribución descargando código directamente del sitio del desarrollador.

El efecto de esta separación entre capas es crear un mercado interno de mejoras muy fluido. Los desarrolladores compiten entre sí por la atención de los distribuidores y los usuarios sobre la calidad de su software. Los distribuidores compiten por los dólares de los usuarios sobre lo adecuado de sus políticas de selección, y sobre el valor que pueden añadir al software.

Un efecto de primer orden de la estructura interna de este Mercado es que ningún nodo de la red es indispensable. Los desarrolladores pueden abandonar; incluso si su parte del código base no es recogida directamente por algún otro desarrollador, la competencia por la atención tenderá a generar rápidamente alternativas funcionales. Los distribuidores pueden fallar sin dañar o comprometer el código base común. La ecología como un todo tiene una respuesta más rápida a las demandas del mercado, y más capacidad para resistir shocks y regenerarse, que la que cualquier fabricante monolítico de un sistema operativo cerrado puede posiblemente conseguir.

Otro efecto importante es reducir el sobrecoste e incrementar la eficiencia mediante la especialización. Los desarrolladores no experimentan las presiones que habitualmente comprometen los proyectos cerrados convencionales y los convierten en pozos de alquitrán; no hay listas de funciones inútiles y molestas de Marketing, ningún gestor obliga a usar lenguajes o entornos de desarrollo inadecuados y obsoletos, no hay requerimientos para reinventar la rueda de una manera nueva e incompatible en nombre de la diferenciación del producto o de la protección de la propiedad intelectual y (lo más importante) no hay fechas límite. No se corre para sacar una versión 1.0 antes de que esté bien hecha. De Marco y Lister observaron en su discusión del estilo de dirección “despiértame cuando esté acabado” en “Peopleware: Proyectos y equipos productivos” que esto normalmente conduce no sólo a más calidad sino a la entrega más rápida de un resultado operativo.

Los distribuidores, por otro lado, consiguen especializarse en las cosas que los distribuidores pueden hacer más eficazmente. Liberados de la necesidad de financiar desarrollos de software masivos y continuados sólo para permanecer competitivos, pueden concentrarse en la integración de sistemas, el empaquetamiento, el aseguramiento de la calidad y el servicio.

Tanto los distribuidores como los desarrolladores se mantienen honestos gracias al feedback constante y la monitorización de los usuarios, que es una parte integral del método open source.

Lidiando con el Éxito

La Tragedia de los Comunes puede no ser aplicable al desarrollo open source tal como sucede hoy, pero eso no significa que no haya razones para considerar si el momento actual de la comunidad open source es sostenible. ¿Dejarán de cooperar los jugadores clave cuando las apuestas se hagan mayores?

Hay varios niveles en los que se puede plantear esta pregunta. Nuestra historia “Comedia de los comunes” está basada en el argumento de que el valor de las contribuciones individuales al open source es difícil de convertir a dinero. Pero este argumento tiene mucha menos fuerza para las empresas (como, por ejemplo, los distribuidores de Linux) que ya tiene una fuente de ingresos asociada al open source. Su contribución ya se está traduciendo en dinero cada día. ¿Es estable su papel colaborativo actual?

Examinar esta cuestión nos conducirá a algunas perspectivas interesantes sobre la economía del software open source en el mundo real de nuestro tiempo; y sobre lo que un verdadero paradigma de industria de servicios implica para la industria de software en el futuro.

En el nivel práctico, aplicado a la comunidad open source tal como existe hoy, esta cuestión normalmente se plantea de dos maneras diferentes. Una: ¿Se fragmentará Linux? Dos: por el contrario, ¿desarrollará Linux un jugador dominante, casi monopolista?

La analogía histórica a la que mucha gente acude cuando se plantea si Linux se fragmentará es el comportamiento de los fabricantes de Unix propietarios en los 80. A pesar de la incesante charla sobre estándares abiertos, a pesar de las numerosas alianzas y consorcios y acuerdos, los Unix propietarios de separaron. El deseo de los vendedores de diferenciar sus productos añadiendo y modificando funciones del sistema operativo se demostró más fuerte que su interés en incrementar el tamaño total del mercado Unix manteniendo la compatibilidad (y como consecuencia bajando las barreras de entrada para los desarrolladores independientes de software y el coste total de propiedad para los clientes).

Es bastante improbable que esto suceda con Linux, por la simple razón de que todos los distribuidores están limitados a trabajar partiendo de una base común de código abierto. No es posible en la práctica para cualquiera de ellos mantener la diferenciación, porque las licencias bajo las que ha sido desarrollado el código de Linux requieren que compartan el código con el resto. En el momento que cualquier distribuidor desarrolla una función, todos los competidores son libres de clonarla.

Como todas las partes entienden esto, nadie piensa siquiera en hacer el tipo de maniobras que fragmentaron los Unix propietarios. Al revés, los distribuidores de Linux están obligados a competir de modos que benefician en la práctica al cliente y al mercado en general. Esto es, deben competir en servicio, en soporte, y su diseño se apoya en qué interfaces llevan a mayor sencillez de instalación y uso.

La base de código común también cierra la posibilidad de monopolización. Cuando la gente de Linux se preocupa por esto, el nombre que normalmente se murmura es “Red Hat”, que es el mayor y más exitoso de los distribuidores (con una cuota de mercado estimada de alrededor del 90% en los Estados Unidos). Pero es destacable que unos días después del anuncio en Mayo de 1.999 del lanzamiento de la esperada versión 6.0 de Red Hat, antes incluso de que los CD-ROM de Red Hat llegaran a distribuirse en cantidades significativas, imágenes de CD-ROM de la versión construidas a partir del propio servidor FTP de Red Hat estaban siendo anunciadas por un editor de libros y varios distribuidores de CD-ROM a precios incluso menores que los precios de lista de Red hat.

A la propia Red Hat ni siquiera se le movió un pelo por esto, porque sus fundadores entienden muy claramente que ellos si poseen ni pueden poseer los bits de su producto; las normas sociales de la comunidad Linux lo prohíben. En una reinterpretación de la famosa observación de John Gilmore de que Internet interpreta la censura como daño, y la evita con un rodeo, se ha dicho acertadamente que la comunidad hacker responsable de Linux interpreta los intentos de control como daño y los evita con un rodeo. Para Red Hat, haber protestado contra las copias de su producto más novedoso habría comprometido seriamente su capacidad para elicitar la cooperación futura de su comunidad de desarrolladores.

Quizá más importante en el momento actual, las licencias de software que expresan estas normas de la comunidad en una forma legal prohíben activamente a Red Hat monopolizar los fuentes del código en el que su producto está basado. La única cosa que pueden vender es una relación de marca/servicio/soporte con gente que desea libremente pagar por eso. Este no es un contexto en el que la posibilidad de un monopolio predador suponga una gran amenaza.

I+D abierta y la reinvención del patronazgo

Hay otro aspecto en el que la infusión de dinero real en el mundo open source lo está cambiando. Las estrellas de la comunidad están encontrándose cada vez más que pueden conseguir ser pagadas por lo que hacen, en lugar de seguir al open source como un hobby pagado por otro trabajo de día. Empresas como Red Hat, O’Reilly & Associates, y VA Linux Systems están construyendo el equivalente a brazos de investigación semi-independientes con charters para contratar y mantienen establos de talento open source.

Esto tiene sentido desde el punto de vista económico sólo si el coste per cápita del mantenimiento de este laboratorio puede pagarse fácilmente con las ganancias esperadas que se conseguirán incrementando más rápidamente el mercado de la compañía. O’Reilly puede permitirse pagar a los líderes de Perl y Apache para que hagan sus cosas porque espera que sus esfuerzos le permitirán vender más libros sobre Perl y Apache y llevar a más gente a sus conferencias. VA Linux Systems puede financiar su laboratorio porque mejorar Linux incrementa el valor de uso de las estaciones de trabajo y servidores que vende. Y Red Hat financia los Laboratorios de Desarrollo Avanzado Red Hat para incrementar el valor de su oferta Linux y atraer a más clientes.

Para los estrategas de los sectores más tradicionales de la industria del software, formados en culturas que consideran a las patentes o la propiedad intelectual protegida-por-secretos-de-negocio como las joyas de la corona de una organización, este comportamiento puede (a pesar de sus efectos en el incremento del mercado) parecer inexplicable. ¿Por qué financiar una investigación de la que cada uno de sus competidores (por definición) es libre de apropiarse sin coste?

Parecen existir dos rezones de control. Una es que mientras estas compañías sigan siendo jugadores dominantes en sus nichos de mercado, pueden esperar capturar la parte del león de los beneficios de la investigación y desarrollo open source. Usar el I+D para comprar futuros beneficios no es una idea nueva; lo que es interesante es que el cálculo implícito de que las ganancias futuras esperadas son suficientemente grandes como para que estas compañías puedan tolerar sin problemas a los aprovechados con tal de conseguir el efecto de revisión entre pares.

Aunque este análisis obvio del valor futuro esperado es necesario en un mundo de capitalistas duros que mantienen sus ojos en el retorno de la inversión, no es en realidad la manera más interesante de explicar la contratación de estrellas porque las propias empresas aportan una más difusa. Ellas le dirán, si les pregunta, que están haciendo simplemente lo correcto para la comunidad de la que provienen. Su humilde autor está suficientemente bien relacionado con directivos de las tres firmas antes mencionadas como para testificar que estas afirmaciones no pueden ser consideradas bobadas. Sin duda, yo fui personalmente reclutado en el borrad de VA Linux Systems a finales de 1.998 explícitamente para que estuviera disponible para aconsejarles sobre “lo adecuado”, y he encontrado que han estado muy dispuestos a escucharme cuando lo he hecho.

Un economista está autorizado para preguntar qué beneficio está implicado aquí. Si aceptamos que la charla sobre hacer lo adecuado no es una pose vacía, deberíamos preguntar a continuación que a qué interés de la compañía sirve “hacer lo adecuado”. La respuesta no es, en sí misma, ni sorprendente ni difícil de verificar si planteamos las preguntas adecuadas. Como con el comportamiento superficialmente altruista de otras industrias, lo que estas compañías creen que en realidad que están comprando es renombre.

Trabajar para ganar renombre, y valorarlo como un activo que predice futuras ganancias en el Mercado, tampoco es ninguna novedad. Lo que es interesante es la valoración extremadamente alta que el comportamiento de estas empresas sugiere que asignan a este renombre. Están dispuestas a contratar talento caro para proyectos que no son generadores directos de ingresos incluso durante las fases más hambrientas de capital de la carrera hacia la IPO. Y, al menos hasta aquí, el mercado ha premiado con generosidad este comportamiento.

Los propios directivos de estas empresas son bastante claros sobre las razones de que el renombre sea especialmente valorable para ellos. Se apoyan fuertemente en voluntarios entre su base de clientes para el desarrollo de productos y como fuerza de marketing informal. Su relación con su base de clientes es íntima, y a menudo se apoya en lazos de confianza personales entre individuos internos y externos a la firma. No se limitan a usar la comunidad hacker; se identifican con ella.

Estas observaciones refuerzan una lección que aprendimos antes de una línea de razonamiento distinta. La relación íntima entre Red Hat/VA/O’Reilly y sus clientes/desarrolladores no es la típica de las empresas fabricantes. En lugar de eso, lleva a un extremo interesante los patrones característicos de las industrias de servicios altamente profesionalizadas y de conocimiento intenso. Observando desde el exterior de la industria de la tecnología, podemos ver estos patrones (por ejemplo) en firmas de abogados, prácticas médicas y universidades.

Podemos observar, de hecho, que las empresas de open source contratan hackers “estrella” por las mismas razones que las universidades contratan académicos “estrella”. En ambos casos, la práctica es parecida en su mecanismo y en su efecto en el sistema de patronazgo aristocrático que financió la mayor parte de las bellas artes hasta después de la Revolución Industrial; una semejanza de la que algunas partes son plenamente conscientes.

Llegando allí desde aquí

Los mecanismos del mercado para financiar (¡y obtener beneficio!) del desarrollo open source están evolucionando todavía rápidamente. Los modelos de negocio que hemos revisado en este ensayo no serán probablemente los últimos en ser inventados. Los inversores están todavía pensando en las consecuencias de reinventar la industria del software como una con un foco explícito en el servicio mas que en la propiedad intelectual cerrada, y lo seguirán haciendo durante algún tiempo.

Esta revolución conceptual tendrá algún coste en pérdidas de beneficio para la gente que invierta en el valor de venta del 5% de la industria; históricamente, los negocios de servicio no son tan lucrativos como los negocios de fabricación (aunque como cualquier médico o abogado puede decirle, el retorno para los profesionales es a menudo mayor). Cualquier pérdida de beneficio, sin embargo, será más que compensada por los beneficios en el lado del coste, según los consumidores de software alcancen enormes ahorros y eficiencias con los productos open source. (Hay un paralelismo aquí con los efectos que el desplazamiento de la red tradicional de voz y teléfono por Internet está teniendo en todas partes).

La promesa de estos ahorros y eficiencias está creando una oportunidad de mercado que los emprendedores y sociedades de capital riesgo se están moviendo para explotar. Cuando el primer borrador de este ensayo estaba en preparación, la firma de capital riesgo más prestigiosa de Silicon Valley tomó una participación importante en la primera compañía emergente que se especializó en soporte técnico 24x7 de Linux (Linuxcare). En agosto de 1.999 la IPO de Red Hat fue (a pesar de un trasfondo de caída en acciones de Internet y tecnología) un gran éxito. Se espera que varias IPOs de empresas relacionadas con Linux y open source se lancen antes del final de 1.999; y que sean también bastante exitosas. (Actualización del año 2.000: ¡lo fueron!)