Chapter 3

Este modelo lo usó por primera vez Cygnus Solutions, probablemente el primer negocio open source (1.989). En aquella época, las herramientas GNU proporcionaban un entorno de desarrollo común entre varias máquinas, pero cada herramienta usaba un proceso de configuración diferente y requería un conjunto diferente de parches para correr en cada plataforma. Cygnus domesticó las herramientas GNU y creó el script “configure” para unificar el proceso de construcción (la receta), y después vendió servicios de soporte y binarios empaquetados con su versión de las herramientas GNU (el restaurante). De acuerdo con la GPL, permitían a los clientes usar, distribuir y modificar libremente el software que distribuyeron, pero el contrato de servicios terminaría (o se requeriría pagar una tarifa superior) si había más usuarios de los servicios de soporte de los estipulados en el contrato (no se permite compartir el bufé de ensaladas).

Esto es también lo que hacen Red Hat y otros distribuidores de Linux. Lo que en realidad venden no es el software, los bits en sí mismos, sino el valor añadido al ensamblar y probar un sistema operativo funcional del que se garantiza (aunque sea de manera implícita) que es vendible y que es compatible con otros sistemas operativos de la misma marca. Otros elementos de su proposición de valor incluyen el soporte gratuito para la instalación y la provisión de opciones para contratos de soporte continuado.

El efecto de construcción de mercado del open source puede ser extremadamente poderoso, especialmente para compañías que están inevitablemente en una posición de prestación de servicios para empezar. Un caso reciente muy instructivo es Digital Creations, una empresa de diseño de sitios web fundada en 1.998 que se especializa en sitios con transacciones y bases de datos complejas. Su principal herramienta, la joya de la corona de la propiedad intelectual de la compañía, es un publicador de objetos que ha pasado por diversos nombres y encarnaciones pero ahora se llama Zope.

Cuando la gente de Digital Creations estaba buscando financiación, el socio capitalista que incorporaron evaluó cuidadosamente su nicho de mercado, su personal y sus herramientas. El socio capitalista recomendó a Digital Creations que liberara Zope.

Según los estándares tradicionales de la industria del software, esto parece un movimiento completamente absurdo. La sabiduría convencional de las escuelas de negocios dice que la propiedad intelectual como Zope es la joya de la corona de una compañía, y nunca, bajo ninguna circunstancia, debe cederse. Pero el socio capitalista tenía dos ideas relacionadas.

Una es que el verdadero valor central de Zope es en realidad los cerebros y habilidades de su gente. La otra es que es más probable que Zope genere valor como creador de mercado que como herramienta secreta.

Para ver esto, compare dos escenarios. En el convencional, Zope permanece como el arma secreta de Digital Creations. Establezcamos que es muy efectiva. Como resultado, la firma será capaz de producir con más calidad en menos tiempo, pero nadie lo sabe. Será fácil satisfacer a los clientes, pero más difícil construir una base de clientes con la que empezar.

El socio capitalista, en cambio, vio que liberar Zope podría ser una publicidad crítica para el verdadero activo de Digital Creations: su gente. Esperaba que los clientes que evaluaban Zope considerarían más eficiente contratar a los expertos que desarrollar conocimientos internos en Zope.

Uno de los directivos de Zope ha confirmado públicamente que su estrategia open source ha “abierto muchas puertas en la que no habríamos entrado de otra manera” [sic]. Los clientes potenciales responden sin duda a la lógica de la situación; y Digital Creations está prosperando.

Otro ejemplo actual es e-smith. Esta compañía vende contratos de soporte para software de servidores de Internet que es open source, un Linux personalizado. Uno de los directivos, describiendo la cantidad de descargas gratuitas del software de e-smith, dice “La mayoría de las empresas lo considerarían piratería de software; nosotros lo consideramos marketing gratuito”.

Accesorios

En este modelo, usted vende accesorios para el software open source. En la gama baja, tazas y camisetas; en la gama alta, documentación editada y producida profesionalmente.

O’Reilly & Associates Inc., editores de muchos volúmenes excelentes de referencia sobre software open source, es un buen ejemplo de este tipo de compañía. En realidad, O’Reilly contrata y da soporte a muchos hackers reconocidos (como Larry Wall y Brian Behlendorf) como una vía para construir su reputación en el mercado que han elegido.

Libera el futuro, vende el presente

En este modelo, produce software en código binario y fuente con una licencia cerrada, pero que incluye una fecha de caducidad en sus condiciones. Por ejemplo, puede escribir una licencia que permita la libre distribución, prohíba el uso comercial sin licencia, y garantice que el software se acogerá a la licencia GPL un año después de su lanzamiento o si el fabricante cierra.

Bajo este modelo, los clientes pueden estar seguros de que el producto es adaptable a sus necesidades, porque tienen el fuente. El producto está protegido frente al futuro: la licencia garantiza que una comunidad open source puede adoptar el producto si la compañía original muere.

Debido a que el precio de venta y el volumen están basados en las expectativas de los clientes, la compañía original debería disfrutar de mayores ingresos por sus productos que si los lanzara con una licencia completamente cerrada. Más aún, como el código antiguo tiene licencia GPL, conseguirá una revisión seria, corrección de errores, y pequeños añadidos de funcionalidad, que reducirán parte de la carga del 75% de mantenimiento del fabricante.

Este modelo lo ha seguido con éxito Aladdin Enterprises, fabricante del popular programa Ghostscript (un intérprete de PostScript que puede traducir al lenguaje nativo de muchas impresoras).

El principal inconveniente de este modelo es que las condiciones de cierre de licencia tienden a inhibir la revisión y la participación en las fases tempranas del ciclo del producto, precisamente cuando se necesitan más.

Libera el software, vende la marca

Este es un modelo de negocio teórico. Usted libera una tecnología de software, retiene un juego de pruebas o un conjunto de criterios de compatibilidad, y luego vende a los usuarios una marca que certifica que su implementación de la tecnología es compatible con todos los demás que llevan la marca.

(Así es como Sun Microsystems debería manejar Java y Jini).

Actualización: en Julio de 2.000, Sun anunció que liberaría Star Office, y que vendería el uso de la marca Star Office a desarrollos del código base que pasan el juego de pruebas de Sun.

Libera el software, vende el contenido

Este es otro modelo de negocio hipotético. Imagine algo como un servicio de suscripción a datos de bolsa. El valor no está ni en el software cliente ni en el servidor, sino en proporcionar información objetivamente fiable. Así que libera todo el software y vende suscripciones al contenido. Según los hackers vayan migrando el cliente a nuevas plataformas y lo mejoren de cualquier manera, su mercado se expande automáticamente.

(Esta es la razón por la que AOL debería liberar su software cliente).

Cuándo ser abierto, cuándo ser cerrado

Habiendo revisado modelos de negocio que soportan el desarrollo de software open source, podemos aproximarnos a la pregunta general de cuándo tiene sentido desde el punto de vista económico ser abierto y cuándo ser cerrado. Primero, debemos aclarar cuáles son los beneficios de cada estrategia.

¿Cuáles son los beneficios?

La aproximación de cerrar el fuente le permite obtener rentas de sus bits secretos; por otro lado, cierra la posibilidad de una revisión entre pares verdaderamente independiente. La aproximación open source establece condiciones para la revisión entre pares, pero no consigue rentas de sus bits secretos.

El beneficio de tener bits secretos se entiende bien; tradicionalmente, los modelos de negocio de software se han construido alrededor de ellos. Hasta recientemente, el beneficio de la revisión entre pares independiente no se entendía bien. El sistema operativo Linux, sin embargo, nos trae una lección que deberíamos haber aprendido probablemente hace años de la historia del software central de Internet y otras ramas de la ingeniería: que la revisión entre pares del open source es el único método escalable para conseguir alta fiabilidad y calidad.

En un mercado en competencia, por tanto, los clientes que buscan alta fiabilidad y calidad recompensarán a los productores de software que opten por el open source y descubran cómo mantener una corriente de ingresos en los mercados de servicios, valor añadido y accesorios asociados con el software. Este fenómeno es lo que está detrás del sorprendente éxito de Linux, que surgió de la nada en 1.996 para convertirse en el segundo sistema operativo más popular en el mercado de servidores para empresas a mediados de 2.000 (y algunos estudios muestran que sobrepasó la cuota de mercado de Microsoft a finales de 2.000). A comienzos de 1.999 IDC proyectó que Linux crecería más rápido que todos los demás sistemas operativos juntos hasta 2.003: esta proyección se ha mostrado cierta hasta la fecha.

Un beneficio casi tan importante como del open source es su utilidad como manera de propagar estándares abiertos y construir mercados a su alrededor. El dramático crecimiento de Internet debe mucho al hecho de que nadie es dueño de TCP/IP; nadie tiene un cerrojo propietario en los protocolos centrales de Internet.

Los efectos de red que están detrás del éxito de TCP/IP y Linux están bastante claros y se reducen al final a cuestiones de confianza, y socios potencialmente simétricos que comparten una infraestructura confiarán más en ella si pueden ver cómo trabaja hasta el fondo, y preferirán una infraestructura en la que todas las partes tengan derechos simétricos a una en la que una parte está en una posición privilegiada para extraer beneficios o ejercer el control.

No es, sin embargo, necesario en realidad suponer efectos de red para que las cuestiones de simetría sean importantes para los consumidores de software. Ningún consumidor de software elegirá racionalmente cerrarse a sí mismo en un monopolio controlado por un suministrador haciéndose dependiente de un código cerrado si está disponible alguna alternativa open source de calidad aceptable. Este argumento gana fuerza según el software se hace más crítico para el negocio del consumidor de software: cuanto más vital es, menos puede tolerar el cliente que esté controlado por un tercero.

Hay una cuestión tangencial a esta. Los economistas saben que, en general, la información asimétrica hace que los mercados trabajen con ineficacias. Los bienes de mayor calidad quedan fuera cuando es más lucrativo obtener beneficios de la información privilegiada que invertir en la producción de mejores productos. En general, y no sólo en el software, el secreto es enemigo de la calidad.

Por último, un beneficio importante para el cliente del software open source que tiene que ver con la cuestión de la confianza es que está protegido frente al futuro. Si el fuente está abierto, el cliente tiene algún recurso si el fabricante quiebra. Esto puede ser particularmente importante para el “escarchado de dispositivos”, ya que el hardware tiende a tener ciclos de vida cortos, pero el efecto es más general y se traduce en incremento de valor para todo tipo de software open source.

¿Cómo interactúan?

Cuando el beneficio de los bits secretos es mayor que el retorno del open source, tiene sentido desde el punto de vista económico ser cerrado, Cuando el retorno del open source es mayor que el beneficio de los bits secretos, tiene sentido hacer open source.

Por sí misma, esta es una observación trivial. Se hace no trivial cuando observamos que el beneficio del open source es más difícil de medir y predecir que el beneficio de los bits secretos; y dicho esto, el beneficio es infravalorado mucho más a menudo que sobrevalorado. Sin duda, hasta que el mundo corporativo comenzó a repensar sus premisas siguiendo la liberación de los fuentes de Mozilla a comienzos de 1.998, se suponía, equivocada pero comúnmente, que el beneficio del open source era cero.

¿Así que cómo podemos evaluar el beneficio del open source? Es una pregunta difícil en general, pero podemos aproximarlo como haríamos con cualquier otro problema predictivo. Podemos empezar por los casos observados en los que la aproximación open source ha tenido éxito o ha fracasado. Podemos intentar generalizarlos a un modelo que proporcione al menos una indicación cualitativa para los contextos en los que el open source es una ganancia neta para el inversor o el negocio que intentar maximizar los beneficios. Después podemos volver a los datos e intentar refinar el modelo.

Del análisis presentado en La Catedral y el Bazar, podemos esperar que el open source tenga un beneficio alto cuando (a) la fiabilidad/estabilidad/escalabilidad sean críticas, y (b) la corrección del diseño y la implementación no sean fácilmente verificables por otros medios distintos a la revisión independiente entre pares. (El segundo criterio lo cumplen en la práctica la mayoría de los programas no triviales).

Un deseo racional del consumidor de evitar verse atrapado en el monopolio de un proveedor incrementará su interés en el open source (y, por tanto, el valor competitivo en el mercado de sus proveedores) según el software se hace más crítico para dicho cliente. Así, otro criterio (c) empuja hacia el open source cuando el software es un bien crítico para el negocio (como, por ejemplo, en muchos sistemas de información de gestión corporativos).

Para el área de aplicaciones, observamos antes que la infraestructura open source crea efectos de confianza y simetría que, con el tiempo, tenderán a atraer más clientes y se impondrá a la infraestructura cerrada; y a menudo es mejor tener una porción más pequeña de un mercado en rápida expansión que una mayor de uno cerrado y estancado. Igualmente, para el software de infraestructura, la apuesta del open source por la ubicuidad es muy probable que tenga un mayor retorno a largo plazo que la apuesta del software cerrado por la renta de la propiedad intelectual.

De hecho, la capacidad de los clientes potenciales para razonar acerca de las consecuencias futuras de las estrategias de los fabricantes y su resistencia a aceptar un monopolio de fabricantes implica una restricción más fuerte: sin tener todavía un poder abrumador en el mercado, puede elegir entre una apuesta por la ubicuidad del open source o una apuesta por los ingresos directos a partir del código cerrado; pero no puede apostar por ambas. (Analogías a este principio aparecen en todas partes; por ejemplo, en los mercados de electrónica donde los clientes a menudo evitan comprar diseños de una única fuente). El caso puede expresarse menos negativamente: donde los efectos de red (externalidades de red positivas) dominan, el open source es probablemente la opción correcta.

Podemos resumir esta lógica haciendo notar que el open source parece tener más éxito para generar mayores ingresos que el código cerrado en software que (d) establece o habilita una infraestructura de computación y comunicaciones común.

Por último, podemos observar que los proveedores de servicios únicos o altamente diferenciados tienen más incentivos para temer la copia de sus métodos por sus competidores que los proveedores de servicios para los que los algoritmos críticos y las bases de conocimiento están bien entendidas. Según esto, es más probable que el open source domine cuando (e) los métodos clave (o equivalentes funcionales) son parte de un conocimiento de ingeniería común.

El software nuclear de Internet, Apache, y la implementación de Linux del API estándar de Unix son ejemplos que cumplen los cincos criterios. El camino hacia el open source en la evolución de estos mercados está bien ilustrado por la convergencia de las redes de datos en el TCP/IP a mediado de los 90, después de quince años de intentos fallidos de construir imperios con protocolos cerrados como DECNET, XNS, IPX y similares.

Por otro lado, el open source parece tener menos sentido para compañías que tienen la posesión en exclusiva de una tecnología de software generadora de valor (que cumple estrechamente el criterio (e)) que es (a) relativamente insensible a fallos, que puede (b) ser fácilmente verificada por medios diferentes a la revisión independiente entre pares, que no es (c) crítica para el negocio, y cuyo valor no se vería sustancialmente incrementado por (d) efectos de red o ubicuidad.

Como ejemplo de este caso extremo, a comienzos de 1.999 me preguntaron “¿Deberíamos liberar nuestro código?” desde una compañía que escribe software para calcular patrones de corte para serrerías que quieren extraer el máximo metraje de planchas a partir de los troncos. Mi conclusión fue “No”. El único criterio que se acerca al cumplimiento es el (c); pero en un apuro, un operario con experiencia podría generar patrones de corte a mano.

Observe que mi respuesta podría haber sido muy diferente si el calculador de patrones de corte hubiera sido escrito por un fabricante de maquinaria para serrerías. En ese caso, abrir el código podría haber incrementado el valor de la maquinaria asociada que venden. Observe también que si existiera ya algún calculador de patrones de corte open source (quizás el escrito por el fabricante de herramientas para serrerías) el producto cerrado tendría problemas para competir con él; no tanto por razones de precio, sino porque los clientes percibirían en el software abierto ventajas en cuanto a capacidad de personalización y otros rasgos.

Un punto importante es que dónde un producto o tecnología concretos se asiente en estas escalas puede cambiar con el tiempo, como veremos en el siguiente caso de estudio.

En resumen, los siguientes discriminadores empujan hacia el open source:

(a)

La fiabilidad/estabilidad/escalabilidad son críticas.

(b)

La corrección del diseño y su implementación no puede revisarse fácilmente por otros medios diferentes de la revisión independiente entre pares.

(c)

El software es crítico para el control del negocio del usuario.

(d)

El software establece o habilita una infraestructura de computación y comunicaciones común.

(e)

Los métodos clave (o sus equivalentes funcionales) son parte de un conocimiento de ingeniería común.

Doom: Un caso de estudio

La historia del juego de éxito Doom de id software ilustra vías en las que la presión del mercado y la evolución del producto pueden cambiar de manera crítica las magnitudes del beneficio para el software abierto o cerrado.

Cuando Doom se lanzó por primera vez a finales de 1.993, su animación de primera persona en tiempo real lo hizo único (la antítesis del criterio (e)). No sólo era impresionante el impacto visual de sus técnicas (sobrepasando el mundo de animación plana de su predecesor Wolfenstein 3D), sino que durante meses nadie pudo averiguar cómo se había conseguido en los limitados procesadores de la época. Estos bits secretos suponían un valor muy importante. Además, el beneficio potencial de abrir el fuente era bajo. Como juego individual, el software (a) tenía costes bajos de fallo, (b) no era tremendamente difícil de verificar, (c) no era crítico para el negocio de ningún cliente, (d) no se beneficiaba de efectos de red. Era económicamente racional para Doom ser cerrado.

Sin embargo, el Mercado construido alrededor de Doom no permaneció quieto. Los competidores potenciales inventaron equivalentes funcionales de sus técnicas de animación, y otros juegos de “disparo en primera persona” como Duke Nukem empezaron a aparecer. Según quitaban cuota de mercado a Doom estos juegos, el valor de la renta de los bits secretos disminuía.

Por otro lado, los esfuerzos para expandir esa cuota trajeron nuevos desafíos técnicos: mejor fiabilidad, más funciones, mayor base de usuarios y múltiples plataformas. Con la llegada de juegos multijugador y servicios de juegos de Doom, el mercado empezó a mostrar efectos de red sustanciales. Todo esto requería horas de programador que id hubiera preferido invertir en el siguiente juego.

Desde el momento en que el juego se liberó por primera vez, id había visto con benevolencia la publicación de especificaciones técnicas que ayudaran a la gente a crear objetos de datos para el juego, y ocasionalmente cooperaba directamente con los hackers respondiendo a preguntas concretas o publicando un documento propio de especificaciones, También fomentaban la distribución por Internet de nuevos datos para Doom.

Las tendencias técnicas y de mercado elevaron el beneficio de la liberación del código; la apertura de especificaciones y la potenciación de los añadidos de terceros incrementaron el valor percibido del juego y crearon un mercado secundario a explotar. En algún momento las curvas de beneficios se cruzaron y se hizo económicamente racional para id pasar a hacer dinero en ese mercado secundario (con productos como antologías de escenarios para el juego) y después abrir el código fuente de Doom. Algún tiempo después de este punto, ocurrió. El código fuente completo de Doom se liberó a finales de 1.997.

Sabiendo cuándo liberar

Doom es un caso de estudio interesante porque no es ni un sistema operativo ni un software de comunicaciones o redes; por tanto está lejos de los ejemplos habituales y obvios de éxito en open source. Sin duda, el ciclo de vida de Doom, junto a su punto de cruce, puede convertirse en el modelo para el software de aplicación en la ecología del código actual; una en la que las comunicaciones y la computación distribuida crea tanto problemas serios de robustez/fiabilidad/escalabilidad sólo resolubles mediante la revisión entre pares, y a menudo cruza fronteras entre entornos técnicos y entre agentes competidores (con todas las cuestiones de confianza y simetría que esto implica).

Doom evolucionó del juego solitario al juego en red. Cada vez más, el efecto de red es la computación. Tendencias similares son visibles incluso en las aplicaciones de negocio más pesadas, como los sistemas ERP, según los negocios se relacionan más intensamente con suministradores y clientes; y, por supuesto, están implícitas en toda la arquitectura del World Wide Web. Se sigue que prácticamente en todas partes, el beneficio del open source está incrementándose continuamente.

Si la tendencia actual continúa, el desafío central de la tecnología del software y la gestión de productos en el próximo siglo será conocer cuándo liberar: cuándo permitir al código cerrado pasar a la infraestructura open source para explotar el efecto de la revisión entre pares y capturar mayores ingresos en servicios y otros mercados secundarios.

Hay incentivos obvios para no errar en el punto de cruce demasiado lejos en cualquier dirección. Más allá, hay un riesgo de oportunidad serio al esperar demasiado: podría quedar desplazado por un competidor que pasara a ser open source en el mismo nicho de mercado.

La razón de que esto sea un asunto serio es que tanto el pool de usuarios como el pool de talento disponible para ser reclutado para la cooperación open source en cualquier categoría de producto dada es limitado, y el reclutamiento tiende a ser adhesivo. Si dos productores son el primero y el segundo en liberar código de funcionalidad prácticamente equivalente, el primero es probable que el primero atraiga la mayoría de usuarios y la mayoría de los desarrolladores más motivados; el segundo tendrá que coger las sobras. El reclutamiento tiende a ganar adhesiones, según los usuarios ganan familiaridad y los desarrolladores invierten tiempo en el código.

Open Source como arma estratégica