Chapter 2

Parte de la respuesta radical en el hecho de que la gente no necesita simplemente soluciones, necesita soluciones a tiempo. Raramente es posible predecir cuándo otro terminará una pieza dada de trabajo necesario. Si el pago por arreglar un bug o añadir una funcionalidad es suficiente para cualquier contribuyente potencial, esa persona lo hará (y en ese punto el hecho de que los demás sean egoístas se hace irrelevante).

Otra parte de la respuesta yace en el hecho de que el valor de mercado putativo de los pequeños parches a un código base común es difícil de capturar. Suponiendo que escriba un arreglo para un defecto irritante, y suponiendo que mucha gente se da cuenta de que el arreglo tiene un valor monetario: ¿cómo cobro a toda esa gente? Los sistemas de pago convencionales tienen tantas complicaciones que hacen de esto un verdadero problema para el tipo de micropagos que habitualmente serían apropiados.

Puede ser más acertado incluso observar que este valor no sólo es difícil de cobrar, sino que generalmente es incluso difícil de asignar. Como experimento mental, supongamos que Internet viniera equipado con el sistema seguro de micropagos teóricamente ideal, accesible universalmente, sin sobrecoste. Ahora digamos que ha escrito un parche titulado “Arreglos diversos al kernel de Linux”. ¿Cómo sabe qué precio pedir? ¿Cómo podría un comprador potencial, que todavía no ha visto el parche, saber cuál es un precio razonable?

Lo que tenemos aquí es casi como una imagen en un espejo deformante del “problema de cálculo” de F. A. Hayek: se requeriría un superser, a la vez capaz de evaluar el valor funcional de los parches y respetado como para definir los precios en consecuencia, para lubricar el negocio.

Desafortunadamente, hay una tremenda escasez de superseres, de modo que al autor del parche J. Cualquier Hacker le quedan dos opciones: sentarse en el parche o echarlo al común gratis.

Sentándose en el parche no gana nada. Sin duda, incurre en un coste futuro: el esfuerzo que implica refundir el parche en el código base en cada nueva versión. Así que el pago para esta opción es en realidad negativo (y está multiplicado por la rápida velocidad de publicación característica de los proyectos open source).

Para expresarlo de manera positiva, el contribuyente gana trasladando las cuestiones de mantenimiento del parche a los propietarios del código fuente y el resto del grupo del proyecto. También gana porque otros mejorarán su trabajo en el futuro. Finalmente, ya que no tiene que mantener el parche por sí mismo, puede ser capaz de disponer de más tiempo para otras personalizaciones incluso mayores que se ajusten a sus necesidades. Los mismos argumentos que favorecen la apertura del código para los paquetes completos se aplican también a los parches.

Echando el parche al común puede no ganar nada, o puede animar el esfuerzo recíproco de otros que resolverán alguno de los problemas de J. Cualquiera en el futuro. Esta opción, aparentemente altruista, es en realidad óptimamente egoísta en el sentido de la teoría de juegos.

Al analizar esta clase de cooperación, es importante observar que aunque hay un problema de egoísmo (el trabajo puede estar infraprovisionado en ausencia de dinero o compensación equivalente) éste no escala con el número de usuarios finales (vea la nota final en [ST] para su discusión). La complejidad y el sobrecoste de comunicación en un proyecto open source es casi por entero una función del número de desarrolladores involucrado: tener más usuarios finales que nunca miran el código fuente cuesta en la práctica nada. Puede incrementar el número de preguntas tontas que aparecen en las listas de correo del proyecto, pero esto se mitiga fácilmente manteniendo una lista de Preguntas Frecuentes e ignorando descaradamente a los que preguntan sin haberla leído (y de hecho ambas prácticas son típicas).

Los verdaderos problemas de egoísmo en el software open source son más una función de los costes de fricción al remitir parches que otra cosa. Un contribuidor potencial con poco terreno en el juego de la reputación cultural (ver Colonizando la Noosfera) puede, en ausencia de compensación económica, pensar “no merece la pena remitir este arreglo porque tendré que adecentar el parche, escribir una entrada en el ChangeLog, firmar los papeles de asignación de la FSF...” Es por esta razón que el número de contribuyentes (y, en segundo orden, el éxito de los proyectos) está fuertemente e inversamente correlacionado con el número de pasos por los que cada proyecto obliga a pasar a un usuario que quiere contribuir. Estos costes de fricción pueden ser políticos o mecánicos. Juntos, creo que explican por que la cultura floja y amorfa de Linux ha atraído a órdenes de magnitud más de energía cooperativa que los esfuerzos más estrechamente organizados y centralizados de BSD; y por qué la Free Software Foundation ha retrocedido en importancia relativa con respecto al ascenso de Linux.

Todo esto está bien hasta aquí. Pero es una explicación a posteriori de qué hace J. Cualquier Hacker con su parche después de que lo ha creado. La otra mitad que necesitamos es una explicación económica de cómo JCH pudo escribir ese parche en primer lugar, en lugar de tener que trabajar en un programa cerrado que podría haberle devuelto un valor de venta. ¿Qué modelos de negocio crean nichos en los que el desarrollo open source puede florecer?

Razones para cerrar los Fuentes

Antes de clasificar los modelos de negocio del open source, deberíamos tratar el tema de los beneficios de la exclusión en general. ¿Qué estamos protegiendo exactamente cuando cerramos el código fuente?

Digamos que contrata a alguien para escribir (por ejemplo) un paquete de contabilidad especializado para su negocio. Ese problema no se resolverá mejor si los fuentes están cerrados en lugar de abiertos; los únicos motivos racionales por los que querría que fueran cerrados es si quiere vender el paquete a otra gente, o negar su uso a los competidores.

La respuesta obvia es que lo que está protegiendo es el valor de venta, pero para el 95% del software escrito para uso interno esto no se aplica. Así que ¿qué otras ganancias hay en que esté cerrado?

La segunda opción (proteger la ventaja competitiva) merece un poco de examen. Suponga que abre el código del paquete de contabilidad. Se hace popular y se beneficia de las mejoras hechas por la comunidad. Ahora, su competidor también empieza a usarlo. El competidor tiene el beneficio sin pagar el coste de desarrollo y le quita negocio. ¿Es este un argumento contra la apertura de fuentes?

Tal vez… y tal vez no. La verdadera pregunta es si su ganancia por repartir la carga de desarrollo excede su pérdida debida al incremento de competición del egoísta. Mucha gente tiende a razonar pobremente acerca de este trueque (a) ignorando la ventaja funcional de reclutar más ayuda para el desarrollo y (b) no tratando los costes de desarrollo como ya incurridos. Por hipótesis, tiene que pagar los costes de desarrollo de todas maneras, luego contabilizarlos como coste de abrir los fuentes (si elige hacer esto) es erróneo.

Otra razón citada a menudo es el miedo a que la difusión de los fuentes de una función especial de contabilidad pueda ser equivalente a revelar aspectos confidenciales de su plan de negocio. Este realmente es un argumento no para cerrar el código, sino contra el mal diseño; en un paquete de contabilidad bien escrito, el conocimiento del negocio no debe expresarse de ningún modo en el código sino en el esquema o lenguaje de especificación implementado por el motor de contabilidad (para un caso paralelo, considere la manera en que los esquemas de bases de datos separan el conocimiento del negocio de la mecánica del motor de la base de datos). La separación de la función debería permitirle guardar las joyas de la corona (el esquema) al tiempo que obtiene el máximo beneficio de abrir el código fuente del motor.

Hay otras razones para cerrar el código que son categóricamente irracionales. Puede, por ejemplo, trabajar bajo la ilusión de que cerrar el código hará que sus sistemas de negocio sean más seguros frente a crackers e intrusos. Si es así, le recomiendo una conversación terapéutica con un experto en criptografía inmediatamente. Los paranoicos profesionales saben que no se puede confiar en la seguridad de los programas cerrados, porque han aprendido de experiencias duras. La seguridad es un aspecto de la fiabilidad; sólo los algoritmos e implementaciones que han sido revisados a fondo entre colegas pueden ser considerados seguros.

Modelos de financiación de valor de uso

Un hecho clave que la distinción entre uso y valor nos permite observar es que sólo el valor de venta está amenazado por el cambio de cerrado a abierto; el valor de uso no.

Si el valor de uso más que el valor de venta es en realidad el mayor conductor del desarrollo de software, y (como se argumentó en La Catedral y el Bazar) el desarrollo open source es en realidad más eficaz y eficiente que el desarrollo cerrado, entonces debemos esperar encontrar circunstancias en las que sólo el valor de uso esperado baste para financiar el desarrollo open source.

Y de hecho no es difícil identificar al menos dos modelos importantes en los que los salarios de desarrolladores a tiempo completo para proyectos open source están financiados estrictamente a partir del valor de uso.

El caso de Apache: compartir el coste

Supongamos que trabaja para una firma que tiene un requerimiento crítico para el negocio de un servidor web de alta fiabilidad y capacidad. Quizá es para comercio electrónico, quizá se trata de una publicación de gran visibilidad que vende publicidad, quizá es un portal. Necesita disponibilidad 24x7, necesita velocidad y necesita personalización.

¿Cómo puede conseguir esto? Hay tres estrategias básicas que puede seguir:

Comprar un servidor web propietario. En este caso, está apostando por que la agenda del fabricante coincide con la suya y que el fabricante tiene la competencia técnica para implementar adecuadamente. Incluso suponiendo que estas cosas sean ciertas, es probable que el producto quede corto en personalización; será capaz de modificarlo sólo mediante los enlaces que el fabricante haya elegido proporcionarle. Podemos ver en los estudios mensuales de Netcraft que este camino propietario no es el más popular, y se hace menos popular cada vez.

Lanzar el suyo. Construir su propio servidor web no es una opción para descartar a priori; los servidores web no son muy complejos, ciertamente menos que los navegadores, y uno especializado puede ser muy delgado y pequeño. Siguiendo este camino, tendrá exactamente las funcionalidades y personalización que quiere, aunque pagará por ello en tiempo de desarrollo. Su empresa también podría descubrir que tiene un problema cuando se retire o deje el puesto.

Unirse al grupo de Apache. El servidor Apache fue construido por un grupo de webmasters conectado por Internet que se dio cuenta de que era más inteligente unir sus esfuerzos para mejorar un código base que desarrollar una gran número de esfuerzos de desarrollo paralelos. Haciendo esto fueron capaces de capturar la mayoría de las ventajas del desarrollo propio y el poderoso efecto de depuración de la revisión entre pares masivamente paralela.

La ventaja de la opción Apache es muy fuerte. Exactamente cómo de fuerte, podemos juzgarlo por el estudio mensual de Netcraft, que ha mostrado que Apache está ganando cuota de mercado constantemente frente a todos los servidores web propietarios desde su nacimiento. En noviembre de 2.000, Apache y sus derivados tenían el 60% de cuota de mercado: sin propietario legal, sin promoción, y sin organización de servicios contratada detrás de todo ello.

La historia de Apache se generaliza en un modelo en el que usuarios de software que compiten entre sí encuentran una ventaja en financiar cooperativamente el desarrollo open source porque al hacerlo así obtienen un producto mejor, a menor coste, del que podrían tener de otra manera.

El caso de Cisco: Extender el riesgo

Hace algunos años, a dos programadores de Cisco (el fabricante de equipos de red) les asignaron el trabajo de escribir un sistema de impresión por colas distribuido para su uso en la red corporativa de Cisco. Esto suponía un desafío importante. Además de soportar la capacidad del usuario arbitrario A para imprimir en la impresora arbitraria B (que podría estar en la habitación contigua o a miles de kilómetros), el sistema tenía que asegurarse de que en el caso de falta de papel o de toner el trabajo se redirigiera a una impresora alternativa cercana al objetivo. El sistema también necesitaba ser capaz de reportar estos problemas a un administrador de impresoras.

La pareja salió con un inteligente conjunto de modificaciones al software de colas de impresión estándar de Unix, más algunos scripts, que hacían el trabajo. Entonces se dieron cuenta de que ellos, y Cisco, tenían un problema.

El problema era que no era probable que ninguno de ellos permaneciera en Cisco para siempre. En algún momento ambos programadores se habrían ido, y el software estaría sin mantener y comenzaría a corromperse (esto es, a perder sintonía con las condiciones del mundo real). Ningún desarrollador quiere ver que esto le sucede a su trabajo, y el intrépido dúo sentía que Cisco había pagado por una solución bajo la expectativa razonable de que sobreviviría a su propia situación de empleados allí.

De acuerdo con esto, hablaron con su jefe y le pidieron que autorizara la libración del software de colas de impresión como open source. Su argumento era que Cisco no tenía ningún valor de venta que perder, y sí mucho que ganar. Animando el crecimiento de una comunidad de usuarios y co-desarrolladores extendida en muchas empresas, Cisco podría protegerse efectivamente contra la pérdida de los desarrolladores originales del software.

La historia de Cisco muestra que el open source puede funcionar no sólo para reducir los costes sino para repartir y mitigar el riesgo. Todas las partes encuentran que la apertura del código, y la presencia de una comunidad cooperativa financiada por múltiples fuentes independientes de ingresos, proporciona una protección frente a fallos que es en sí misma económicamente valiosa: suficientemente valiosa como para atraer financiación.

Por qué el valor de venta es problemático

El open source hace bastante difícil capturar el valor de venta directo del software. La dificultad no es técnica; el código fuente no es ni más ni menos fácil de copiar que el binario, y la imposición de las leyes de copyright y licencia para capturar el valor de venta no tiene que ser necesariamente más difícil para los productos open source que para los cerrados.

La dificultad radica más bien en la naturaleza del contrato social que soporta el desarrollo open source. Por tres razones que se refuerzan entre sí, las principales licencias open source prohíben la mayoría de tipos de restricciones en el uso, redistribución y modificación que podrían facilitar la captura de beneficios por la venta directa. Para entender estas razones, debemos examinar el contexto social en el que las licencias evolucionaron: la cultura hacker de Internet.

A pesar de los mitos acerca de la cultura hacker que todavía están muy extendidos fuera de él, ninguna de estas razones tiene que ver con la hostilidad hacia el mercado. Mientras que una minoría de hackers sin duda permanece hostil a la motivación del beneficio, la disposición general de la comunidad para cooperar con paquetes comerciales Linux como Red Hat, SuSE y Caldera demuestra que la mayoría de los hackers trabajarán felizmente con el mundo corporativo cuando sirva a sus intereses. Las verdaderas razones de los hackers para recelar de las licencias de captura directa del beneficio son más sutiles e interesantes.

Una razón tiene que ver con la simetría. Mientras que la mayoría de los desarrolladores open source no tiene intrínsecamente nada que objetar a que otros se beneficien de sus regalos, también demanda que nadie (con la posible excepción del creador de una pieza de código) esté en una posición privilegiada para extraer beneficios. J Cualquier Hacker está dispuesto a que UnaSA se beneficie vendiendo su software o parches, pero sólo si el mismo JCH puede también hacerlo.

Otra tiene que ver con las consecuencias no deseadas. Los hackers han observado que las licencias que incluyen restricciones y tarifas para uso comercial o venta (la manera más normal de intentar recapturar el valor directo de venta, y que en principio parece razonable) tienen serios efectos de congelación. Uno específico es arrojar una sombra legal sobre actividades como la redistribución en recopilaciones baratas en CD-ROM, que idealmente tenderíamos a fomentar. Más generalmente, las restricciones en el uso/venta/modificación/distribución (y otras complicaciones en el licenciamiento) imponen un sobrecoste para el seguimiento de la conformidad y (según aumenta el número de paquetes que maneja una persona) una explosión combinatoria de la incertidumbre percibida y los riesgos legales potenciales. Este resultado se considera perjudicial, y por tanto hay una fuerte presión social para mantener las licencias simples y libres de restricciones.

La razón última y más crítica tiene que ver con la preservación de la dinámica de revisión entre pares y cultura del regalo descrita en Colonizando la Noosfera [HtN]. Las restricciones de licencia diseñadas para proteger la propiedad intelectual o capturar el valor directo de venta a menudo tienen el efecto de hacer legalmente imposible ramificar el proyecto. Este es el caso, por ejemplo, con las licencias de Sun llamadas “Fuentes de la Comunidad” para Jini y Java. Aunque la bifurcación se ve con recelo y se considera el último recurso (por razones discutidas en profundidad en Colonizando la Noosfera), se considera críticamente importante que ese último recurso esté presente en caso de incompetencia o defección del mantenedor (por ejemplo, para pasar a una licencia cerrada).

La comunidad hacker ha cedido algo en la cuestión de la simetría: así, tolera licencias como la Licencia Pública de Netscape (NPL) que concede algunos privilegios a los creadores del código (específicamente en el caso de NPL, el derecho exclusivo a usar el código fuente de Mozilla en productos derivados, que pueden incluir código cerrado). Ha cedido menos en la cuestión de las consecuencias no deseadas, y nada en absoluto en preservar la opción de bifurcar (lo cual es la razón de que las Licencias de Fuente de Comunidad para Java y Jini de Sun hayan sido ampliamente rechazadas por la comunidad).

(Merece la pena repetir aquí que nadie en la comunidad hacker quiere que los proyectos se dividan en líneas de desarrollo competidoras; sin duda (como observé en Colonizando la Noosfera) hay una presión social muy fuerte contra la bifurcación, y por buenas razones. Nadie quiere estar en un piquete, en un juzgado o disparando. Pero el derecho a bifurcar es como el derecho a la huelga, a litigar o el derecho a llevar armas: no quiere ejercitar ninguno de estos derechos, pero es una señal seria de peligro que cualquiera intente quitárselos).

Estas razones explican las cláusulas de la Definición Open Source, que fue escrita para expresar el consenso de la comunidad hacker en lo que respecta a las características críticas de las licencias estándar (la GPL, la licencia BSD, la licencia MIT y la licencia Artística). Estas cláusulas tienen el efecto (aunque no la intención) de hacer que el valor directo de venta sea muy difícil de capturar.

Modelos de Valor de Venta Indirecto

Existen maneras de crear mercados en servicios relacionados con el software que capturan algo semejante al valor de venta indirecto. Hay cinco modelos conocidos y dos potenciales de este tipo (podrían desarrollarse más en el futuro).

Líder en pérdidas / Posicionador de mercado

En este modelo, se usa software open source para crear o mantener una posición de mercado para el software propietario que genere una fuente de ingresos directa. En la variante más común, el software de cliente open source posibilita las ventas de software de servidor, o ingresos asociados a suscripciones o publicidad en un portal.

Netscape Communications perseguía esta estrategia cuando liberó el navegador Mozilla en 1.998. La parte de navegador de su negocio suponía el 13% de los ingresos y seguía descendiendo cuando Microsoft lanzó Internet Explorer (IE). Un marketing intenso de IE (y ciertas prácticas de empaquetamiento que más tarde serían el asunto central de un juicio antimonopolio) redujo rápidamente la cuota de mercado de Netscape, creando la preocupación de que Microsoft pretendía monopolizar el mercado de navegadores y después usar el control de facto de HTML y HTTP para echar a Netscape del mercado de servidores.

Liberando el todavía popular navegador Netscape, Netscape negaba de manera eficaz a Microsoft la posibilidad del monopolio en navegadores. Esperaban que la colaboración open source aceleraría el desarrollo y depuración del navegador, y esperaban que Explorer se viera reducido al papel de segundón, evitando que pudiera definir HTML en exclusiva.

Esta estrategia funcionó. En Noviembre de 1.998 Netscape empezó a recuperar cuota de mercado con respecto a IE. Para cuando Netscape fue comprado por AOL a comienzos de 1.999, la ventaja competitiva de mantener a Mozilla en juego era tan clara que uno de los primeros compromisos públicos de AOL fue continuar soportando el proyecto Mozilla, incluso aunque estaba todavía en estado alfa.

Escarchar dispositivos

Este modelo es para fabricantes de hardware (hardware, en este contexto, incluye cualquier cosa, desde tarjetas Ethernet hasta ordenadores completos). La presión del mercado ha obligado a las compañías de hardware a escribir y mantener software (desde drivers hasta herramientas de configuración, incluso sistemas operativos), pero el software en sí mismo no es un centro de beneficio. Es un sobrecoste; y a menudo uno muy importante.

En esta situación, abrir el código es obvio. No hay una fuente de ingresos que perder, así que no hay inconvenientes. Lo que el fabricante gana es un equipo de desarrollo mucho más grande, respuestas más rápidas y flexibles a las necesidades de los usuarios y mejor fiabilidad mediante la revisión entre pares. Consigue migraciones a otros entornos gratis. Probablemente también gana en mayor lealtad de los usuarios según los técnicos de sus clientes van invirtiendo cada vez más tiempo en el código para mejorarlo según sus necesidades.

Hay un par de objeciones que los fabricantes presentan habitualmente a la liberación de los drivers de hardware. En lugar de mezclar estas objeciones con la discusión de temas más generales aquí, he escrito un epílogo específico sobre este tema.

El efecto de “protección frente al futuro” del open source es particularmente fuerte con respecto al Escarchar dispositivos. Los productos hardware tienen un ciclo de vida de producción y soporte finito; después, los clientes se las tienen que arreglar por sí mismos. Pero si tiene acceso al código del driver y pueden ajustarlo según sus necesidades, es más probable que sean clientes felices que vuelvan a comprar.

Un ejemplo dramático de la adopción del modelo Escarchar dispositivos fue la decisión de Apple Computer en marzo de 1.999 de liberar “Darwin”, el núcleo de su sistema operativo Mac OS X.

Regala la receta y abre un restaurante

En este modelo, uno libera software para crear una posición de mercado, no para el software cerrado (como el caso del líder en pérdidas / posicionador de mercado) sino para los servicios.

(Solía llamar a esto “Regala la maquinilla, vende hojas de afeitar”, pero la relación no es tan precisa como la analogía de la maquinilla de afeitar implica.)