Chapter 1

Resumen

Este ensayo analiza el sustrato económico evolutivo del fenómeno open source. Primero exploro algunos mitos dominantes sobre la financiación del desarrollo de programas y la estructura de precios del software. Después presento un análisis basado en la teoría de juegos de la estabilidad de la cooperación open source. Presento nueve modelos para una financiación sostenible del desarrollo open-source; dos no comerciales y siete comerciales. Después continúo desarrollando una teoría cualitativa de cuándo es económicamente racional para el software ser cerrado. Examino algunos mecanismos novedosos adicionales que el mercado está inventando ahora para financiar desarrollos open-source comerciales, incluyendo la reinvención del sistema de patronazgo y los mercados de tareas. Concluyo con algunas tentativas de predicción del futuro.

Indistinguible de la Magia

En el mito galés, la diosa Ceridwen tenía un gran caldero que, por arte de magia, producía comida cuando se lo mandaba un hechizo conocido sólo por la diosa. En la ciencia moderna, Buckminster Fuller nos dio el concepto de “efimeralización”, según el cual la tecnología se hace a la vez más eficaz y menos cara según los recursos físicos invertidos en los diseños iniciales son sustituidos por más y más contenido de información. Arthur C. Clarke conectó las dos ideas observando que “cualquier tecnología suficientemente avanzada es indistinguible de la magia”.

Para mucha gente, el éxito de la comunidad open-source parece una improbable forma de magia. Software de alta calidad se materializa “gratis”, lo que está bien mientras dura, pero difícilmente parece sostenible en el mundo real de competición y recursos escasos. ¿Dónde está la trampa? ¿Es el caldero de Ceridwen sólo un truco? Y si no, ¿cómo funciona la efimeralización en este contexto, es decir, qué hechizo está usando la diosa?

Más allá de los regalos de los empollones

La experiencia de la cultura open-source ha trastocado ciertamente muchas de las asunciones de la gente que aprendió sobre el desarrollo de software fuera de ella. La Catedral y el Bazar describió las maneras en las que el desarrollo de software cooperativo y descentralizado da un vuelco a la Ley de Brook, alcanzando niveles de fiabilidad y calidad sin precedente en proyectos individuales. Colonizando la Noosfera examinó la dinámica social en la que se sitúa este desarrollo de tipo “bazar”, argumentando que se entiende de manera más eficaz no en términos convencionales de economía de intercambio, sino en lo que los antropólogos llaman una “cultura del regalo”, en la que los miembros compiten por el estatus regalando cosas. En este ensayo comienzo explorando algunos mitos comunes acerca de la economía de la producción de software; después continúo la línea de análisis de estos ensayos adentrándome en el reino de la economía, la teoría de juegos y los modelos de negocio, desarrollando nuevas herramientas conceptuales que se necesitan para entender la manera en que la cultura del regalo de los desarrolladores open-source puede sostenerse a sí misma en una economía de intercambio.

Para seguir esta línea de análisis sin distracción, necesitaremos abandonar (o al menos acordar ignorar temporalmente) el nivel de explicación de la “cultura del regalo”. Colonizando la Noosfera postuló que el comportamiento de cultura de intercambio aparece en situaciones en las que los bienes para la supervivencia son tan abundantes que ya no hacen el juego de intercambio interesante; pero aunque esto parece suficientemente poderoso como explicación psicológica del comportamiento, le falta entidad como explicación del contexto económico mixto en el que muchos desarrolladores open-source operan en realidad. Para la mayoría, el juego de intercambio ha perdido su atractivo pero no su poder de limitación. Su comportamiento tiene que tener el suficiente sentido en una economía de recursos materiales escasos como para mantenerlos en una zona de excedentes que soporta una cultura del regalo.

Por tanto, este ensayo considerará (completamente dentro del reino de la economía de escasez) los modos de cooperación e intercambio que sostienen el desarrollo open-source. Haciendo esto se responderá a la pregunta práctica “¿Cómo gano dinero con esto?” en detalle y con ejemplos. Primero, sin embargo, mostraré que mucha de la tensión que hay detrás de esta pregunta deriva de que los modelos más populares de economía de la producción de software no responden a la realidad.

(Una última observación antes de la exposición: la discusión y promoción del desarrollo open-source en este ensayo no debe utilizarse como argumento para establecer que el desarrollo cerrado es intrínsecamente malo, ni como tesis contra los derechos de propiedad intelectual en el software, ni como una llamada altruista a “compartir”. Aunque estos argumentos son todavía adorados por una minoría en la comunidad de desarrollo open source, la experiencia desde que La Catedral y el Bazar fue publicado ha dejado claro que son innecesarios. Hay suficientes argumentos a favor del desarrollo open source basándonos sólo en sus beneficios económicos y técnicos: mejor calidad, mayor fiabilidad, menor coste y mayores opciones.)

La Ilusión de la Fabricación

Necesitamos comenzar observando que los programas de ordenador, como todos los otros bienes de capital o herramientas, tienen dos tipos diferentes de valor económico. Tienen valor de uso y valor de venta.

El valor de uso de un programa es su valor económico como herramienta, un multiplicador de productividad. El valor de venta de un programa es su valor como algo vendible. (En la jerga de los economistas, el valor de venta es el valor como bien final, y el valor de uso el valor como bien intermedio).

Cuando la mayoría de la gente intenta razonar acerca de la economía de la producción de software, tiende a asumir un “modelo de fábrica” que se basa en las siguientes premisas fundamentales:

1. La mayoría del tiempo de desarrollo se paga mediante el valor de venta.

2. El valor de venta del software es proporcional a su coste de desarrollo (esto es, el coste de los recursos requeridos para replicarlo funcionalmente) y a su valor de uso.

En otras palabras, la gente tiene una fuerte tendencia a suponer que el software tiene las características de valor de cualquier bien manufacturado. Pero estas suposiciones son falsas, como se demuestra fácilmente.

Primero, el código escrito para ser vendido es sólo la punta del iceberg de la programación. En la era pre-microordenador solía ser habitual que el 90% de todo el código del mundo fuera escrito internamente en bancos y compañías de seguros. Probablemente ya no sucede esto; otros sectores hacen un uso mucho más intenso del software ahora, y la parte del sector financiero con respecto al total debe haber caído, pero veremos pronto que hay evidencia empírica de que aproximadamente el 95% del código todavía está desarrollado internamente.

Este código incluye la mayoría de temas de MIS , y las personalizaciones de software financiero y de bases de datos que todas las compañías medianas y grandes necesitan. Incluye código técnico especializado como los drivers de dispositivos. Casi nadie gana dinero vendiendo drivers, un asunto al que volveremos más adelante. Incluye todo tipo de código embebido para nuestras máquinas que cada vez más están controladas por microchips, desde herramientas de maquinaria y aviones a reacción hasta microondas y tostadoras.

La mayoría de este código está integrado en su entorno de maneras que hacen su reutilización o copia muy difícil. (Esto es cierto tanto si el entorno es un conjunto de procedimientos de negocio como el sistema de inyección de combustible de una cosechadora). Así, cuando el entorno cambia, se requiere trabajar continuamente para mantener el software a la par.

A esto se le llama “mantenimiento”, y cualquier ingeniero de software o analista de sistemas le dirá que conforma la inmensa mayoría (más del 75%) de lo que los programadores hacen para que les paguen. Igualmente, la mayoría de las horas de programador se gastan (y la mayoría de los sueldos de programador se pagan) para escribir o mantener código interno que no tiene ningún valor de venta; un hecho que el lector puede comprobar fácilmente examinando las ofertas de trabajo de programador en cualquier periódico con sección de Ofertas de Empleo.

Ojear la sección de empleo del periódico local es un experimento ilustrativo que conmino al lector a realizar por sí mismo (o por sí misma). Examine los trabajos que aparecen con el título programador, proceso de datos e ingeniería de software para identificar puestos que implican desarrollo de software. Clasifique cada trabajo según el software sea desarrollado para uso interno o para venta.

Rápidamente aparecerá claro que, incluso utilizando la definición más amplia de “para la venta”, por lo menos 19 de cada 20 de los salarios ofertados se financian estrictamente con su valor de uso (esto es, su valor como bien intermedio). Esta es nuestra razón para creer que sólo un 5% de la industria está dirigida por el valor de venta. Observe, sin embargo, que el resto del análisis en este ensayo es relativamente indiferente a este número; si fuera un 15% o incluso un 20%, las consecuencias económicas permanecerían esencialmente las mismas.

Cuando hablo en conferencias técnicas, normalmente empiezo mi charla preguntando dos cosas: cuántos en la audiencia cobran por escribir software, y para cuántos sus salarios dependen del valor de venta del software. Normalmente consigo un bosque de manos para la primera pregunta, algunas o ninguna para la segunda, y una sorpresa considerable en la audiencia por la proporción.

Segundo, la teoría de que el valor de venta del software está ligado a sus costes de desarrollo o sustitución es todavía más fácilmente demolida examinando el comportamiento real de los clientes. Hay muchos bienes para los que una proporción de este tipo se mantiene (antes de la depreciación): alimentos, coches, máquinas. Hay incluso muchos bienes intangibles para los que el valor de venta está ligado fuertemente a los costes de desarrollo y sustitución: derechos de reproducción de música, mapas o bases de datos, por ejemplo. Estos bienes pueden retener o incluso incrementar su valor de venta después de que su fabricante original haya desaparecido.

En cambio, cuando un fabricante de productos de software deja el negocio (o si meramente discontinúa el producto), el precio máximo que los clientes pagarán por él cae rápidamente a casi cero, independientemente de su valor de uso teórico o el coste de desarrollo o un equivalente funcional. (Para comprobar esta afirmación, puede ver los estantes de saldos de cualquier tienda de software cercana).

El comportamiento de los distribuidores cuando un fabricante cierra es muy revelador. Nos dice que ellos saben algo que los fabricantes no. Lo que saben es esto: el precio que un cliente pagará está limitado en la práctica por el valor futuro esperado del servicio del fabricante (donde “servicio” se usa aquí de manera amplia para incluir mejoras, actualizaciones y nuevos proyectos).

En otras palabras, el software es principalmente una industria de servicios que opera bajo la persistente pero infundada ilusión de que es una industria de fabricación.

Merece la perna examinar por qué normalmente tendemos a creer lo contrario. Puede ser simplemente porque la pequeña parte de la industria del software que fabrica para la venta es también la única parte que anuncia sus productos. La tendencia mental común que considera la fabricación más “real” que los servicios, porque produce cosas que puedes tocar, puede estar actuando aquí [WG]. También, algunos de los productos más visibles y más fuertemente anunciados son efímeros, como los juegos, que tienen pocos requisitos de servicios continuados (la excepción, más que la regla) [SH].

También merece la pena observar que la ilusión de la facturación favorece estructuras de precios que están patológicamente desalineadas con la composición actual de los costes de desarrollo. Si (como se acepta generalmente) más de un 75% de los costes del ciclo de vida de un proyecto típico de software se dedicarán a mantenimiento, depuración y extensiones, entonces la política habitual de precios de cargar un coste de adquisición alto y tarifas de mantenimiento relativamente bajas o incluso cero está abocada a conducir a resultados negativos para todas las partes.

Los consumidores pierden porque, incluso aunque el software es una industria de servicios, los incentivos en el modelo de fábrica trabajan en contra de que un fabricante ofrezca un servicio competente. Si el dinero del fabricante viene de vender bits, la mayoría del esfuerzo irá a fabricar bits y echarlos por la puerta; el centro de soporte a usuarios, que no es un centro de beneficio, será un vertedero donde colocar a los empleados menos eficaces y tendrá los mínimos recursos necesarios como para no perder un número crítico de clientes.

Todavía es peor. El uso real significa llamadas de soporte, que minan el margen de beneficio a menos que cobre por el servicio. En el mundo open-source, buscará la base de usuarios mayor posible, para tener el máximo feedback y los mercados secundarios más vigorosos posible; en el mundo cerrado buscará tantos compradores pero tan pocos usuarios como sea posible. Por tanto la lógica del modelo de fábrica recompensa con mayor fuerza a los fabricantes que producen shelfware : software con un marketing suficientemente bueno como para conseguir ventas pero inusable en la práctica.

La otra cara de esta moneda es que la mayoría de los fabricantes que creen en este modelo fracasarán a largo plazo. Financiar gastos de soporte que crecen indefinidamente por un precio fijo es sólo viable en un mercado que se expande tan rápido como para cubrir los costes de soporte y de ciclo de vida que implican las ventas de ayer con los ingresos de mañana. Una vez que el mercado madura y las ventas se desaceleran, la mayoría de los fabricantes no tendrán más opción que cortar los gastos dejando huérfano el producto [DPV].

Tanto si esto se hace explícitamente (discontinuando el producto) o implícitamente (haciendo el soporte difícil de obtener), tiene el efecto de derivar a los clientes hacia la competencia, porque destruye el valor futuro esperado del producto, que es dependiente de este servicio. A corto plazo, uno puede escapar de esta trampa haciendo que las versiones de corrección de errores parezcan nuevos productos con un nuevo precio aparejado, pero los consumidores se cansan rápidamente de esto. A largo plazo, por tanto, la única manera de escapar es no tener competidores: esto es, tener un monopolio efectivo en el propio mercado. Al final, sólo puede haber uno.

Y, sin duda, hemos visto repetidamente a este fallo de privación de soporte matar incluso a competidores fuertes que tenían una segunda posición en un nicho de mercado. (El patrón debería ser particularmente obvio para cualquiera que haya analizado la historia de los sistemas operativos de PC, los procesadores de texto, programas de contabilidad, o software de negocios en general.) Los incentivos perversos establecidos por el modelo de fábrica conducen a una dinámica de mercado del tipo “el ganador se lleva todo” en la que incluso los clientes del ganador salen perdiendo.

¿Y si no vale el modelo de fábrica, entonces cuál? Para manejar la estructura real de costes del ciclo de vida del software de manera eficiente (tanto en el sentido informal como en el económico de “eficiencia”), necesitamos una estructura de precios basada en contratos de servicios, suscripciones, y un intercambio continuo de valor entre el fabricante y el cliente. Esta es ya la estructura de precios de los mayores fabricantes de productos de software como los sistemas ERP (Planificación de Recursos Empresariales), para los que los costes de desarrollo son tan grandes que ningún precio fijo de compra podría cubrirlos; compañías como Baan y Peoplesoft en realidad ganan su dinero en las tarifas de consultoría post-venta. Bajo las condiciones de búsqueda de eficiencia en el mercado libre podemos predecir que este es el tipo de estructura de precios que la mayor parte de una industria del software madura seguirá al final.

Lo anterior comienza a darnos alguna intuición acerca de por qué el open-source, cada vez más, aparece no solamente como un reto tecnológico sino también económico al orden establecido. El efecto de hacer el software “gratis”, parece, es obligarnos a entrar en este mundo dominado por las tarifas de servicios; y desvelar que apoyo más débil era después de todo la propuesta de valor de venta de los bits secretos del software cerrado.

Esta transición no será tan violenta como parece en un principio. Muchos consumidores saben que las copias piratas del software empaquetado (especialmente juegos, sistemas operativos y herramientas de productividad populares) son muy fáciles de conseguir. Por tanto, el precio de venta del software propietario, desde el punto de vista del consumidor, sólo merece la pena ser pagado si se obtienen otros bienes: soporte del fabricante, manuales en papel, o un sentimiento de virtud. Las distribuciones comerciales del llamado “software libre” a menudo justifican su precio a los clientes exactamente de la misma manera; la única diferencia es que sus fabricantes no se engañan pensando que los bits por sí mismos tienen valor para el cliente.

El término “gratis” es equívoco en otro sentido también. Bajar el coste de un bien tiende a incrementar, más que decrementar, la inversión total en las personas y la infraestructura que lo soportan. Cuando el precio de los coches baja, la demanda de mecánicos sube; lo que significa que incluso ese 5% de programadores que ahora recibe compensación por el valor de venta tiene muy pocas probabilidades de sufrir en un mundo open-source. La gente que pierda en la transición no serán programadores, serán inversores que han apostado en estrategias de código cerrado cuando no son económicamente viables.

El mito “La Información quiere ser gratis”

Hay otro mito, igual y opuesto a la ilusión del modelo de fábrica, que a menudo confunde la opinión de la gente acerca de la economía del software open source. Es el que establece que “la información quiere ser gratis”. Normalmente esto conduce a la pretensión de que como el coste marginal de la reproducción digital es cero esto implica que su precio de salida debe ser cero (o que un mercado lleno de duplicadores le obligará a ser cero).

Es verdad que algunos tipos de información quieren ser libres, en el sentido débil de que su valor crece cuanta más gente tenga acceso a ella: un documento técnico de estándares es un buen ejemplo. Pero el mito de que toda la información quiere ser libre se viene abajo al considerar el valor de la información que constituye un indicador privilegiado para conseguir un bien valioso: el mapa de un tesoro, por ejemplo, o el número de cuenta de un banco suizo, o un derecho para acceder a servicios tal como una contraseña de una cuenta de ordenador. Incluso aunque la información para cobrar pueda duplicarse a coste cero, el bien que se consigue con ella no. De aquí que el coste marginal distinto de cero para el bien pueda ser heredado por la información que sirve para conseguirlo.

Mencionamos este mito principalmente para afirmar que casi no tiene relación con los argumentos de utilidad económica para el open source; como veremos más tarde, éstos en general se sostienen incluso bajo la suposición de que el software en realidad tiene la estructura de valor de un bien manufacturado. Por tanto no tenemos necesidad de abordar la cuestión de si el software “debería” ser libre o no.

Los Comunes Inversos

Habiendo echado un ojo escéptico en un modelo prevalente, veamos si podemos construir una explicación económica afinada acerca de lo que hace a la cooperación open source sostenible.

Esta es una cuestión que requiere ser examinada en un par de niveles diferentes. En un nivel, necesitamos explicar el comportamiento de los individuos que contribuyen a los proyectos open source; en otro, necesitamos entender las fuerzas económicas que sostienen la cooperación en proyectos open source como Linux o Apache.

De nuevo, primero debemos demoler un modelo popular que interfiere con nuestra comprensión. Sobre cada intento de explicar el comportamiento cooperativo se cierne la sombra de la “tragedia de los comunes” de Garret Hardin.

Hardin nos pide que imaginemos un campo que es propiedad común de un pueblo de campesinos, que llevan a su ganado a pastar en él. Pero el pastar degrada el campo, arrancando la hierba y dejando trozos de barro, donde la hierba tarda en volver a crecer. Si no hay ninguna política acordada (e impuesta) para asignar derechos de pasto que eviten la sobreexplotación, todos los incentivos empujan a llevar tanto ganado y tan rápidamente como sea posible, intentando extraer el máximo valor antes de que el campo común se degrade hasta convertirse en un mar de barro.

La mayoría de la gente tiene un modelo intuitivo del comportamiento cooperativo que funciona de manera muy semejante a este. La tragedia de los comunes en realidad surge de dos problemas ligados, uno de sobreexplotación y otro de infraprovisión. Por el lado de la demanda, la situación de los comunes anima a una carrera hasta el fin hacia la sobreexplotación: lo que los economistas llaman un problema de bien público congestionado. Por el lado de la oferta, los comunes recompensan el comportamiento egoísta, eliminando o disminuyendo los incentivos para que los actores individuales inviertan en desarrollar más pastos.

La tragedia de los comunes predice sólo tres posibles resultados. Uno es el mar de barro. Otro es que algún actor con poder coercitivo imponga una política de asignaciones por el bien del pueblo (la solución comunista). El tercero es que el campo común se deshaga cuando los habitantes del pueblo vallen parcelas que pueden defender y gestionar de manera sostenible (la solución de los derechos de propiedad).

Cuando la gente aplica este modelo a la cooperación open source, esperan que sea inestable y que tenga una vida corta. Como no hay una manera evidente de imponer una política de asignación para el tiempo de programador en Internet, este modelo conduce directamente a la predicción de que el común se romperá, varios fragmentos de software se volverán cerrados y decrecerá rápidamente la cantidad de trabajo dedicada al fondo común.

En realidad, es empíricamente claro que la tendencia es opuesta a esto. La tendencia en amplitud y volumen de desarrollo open source puede medirse por las remisiones diarias a Metalab y SourceForge (los sitios líderes en código para Linux) o los anuncios por día en freshmeat.net (un sitio dedicado a anunciar nuevas versiones de software). El volumen en ambos está creciendo constante y rápidamente. Claramente hay un aspecto crítico en el que el modelo de la “tragedia de los comunes” falla a la hora de interpretar lo que está pasando en realidad.

Parte de la respuesta, por supuesto, yace en el hecho de que el uso del software no decrementa su valor. Sin duda, el uso extendido del software open source tiende a incrementar su valor, cuando los usuarios aportan sus propias mejoras (parches en el código). En este común inverso, la hierba crece más alta cuando se pasta.

Que este bien público no pueda degradarse por el sobreuso da cuenta de la mitad de la tragedia de Hardin, el problema de los bienes públicos congestionados. No explica por qué el open source no sufre infraprovisión. ¿Por qué la gente que sabe que la comunidad open source existe no muestra universalmente un comportamiento egoísta, esperando a que otros hagan el trabajo que necesitan o (si hacen el trabajo por sí mismos) sin molestarse en contribuir con su trabajo al común?