Chapter 5

Otro desarrollo muy interesante es el comienzo de intentos sistemáticos de crear mercados de tareas en los proyectos de desarrollo open source. SourceXchange y CoSource representan maneras ligeramente diferentes de intentar aplicar un modelo de subasta inversa para financiar el desarrollo open source.

Las tendencias generales son claras. Mencionamos antes la proyección de IDC de que Linux crecerá más rápido que todos los otros sistemas operativos juntos hasta 2.003. Apache tiene una cuota del mercado del 61% y crece continuamente. El uso de Internet está explotando, y los muestreos como el Internet Operating System Counter muestran que Linux y otros sistemas operativos open source son ya multitud entre los hosts de Internet y ganan cuota continuamente frente a los sistemas cerrados. La necesidad de explotar la infraestructura open source de Internet condiciona cada vez más no sólo el diseño de otro software sino las prácticas de negocio y los patrones de uso/compra de software de todas las empresas. Estas tendencias, en todo caso, parece probable que se aceleren.

Conclusión: Vida después de la revolución

¿Cómo será el mundo del software cuando la transición al open source sea completa?

Algunos programadores temen que la transición al open source pueda eliminar o devaluar sus trabajos. La pesadilla estándar es lo que llamo el escenario “Apocalipsis Open Source”. Comienza con el valor del mercado del software aproximándose a cero por todo el código gratis que está ahí fuera. El valor de uso por sí mismo no atrae a los suficientes clientes como para soportar el desarrollo de software. La industria del software comercial se derrumba. Los programadores se mueren de hambre o dejan el sector. El apocalipsis llega cuando la propia cultura open source (que depende del tiempo libre de estos profesionales) se derrumba, sin dejar a nadie que sepa programar. Todos mueren. ¡Qué vergüenza!

Ya hemos visto bastantes razones por las que esto no ocurrirá, comenzando por el hecho de que los sueldos de la mayoría de los programadores no dependen del valor de venta del software. Pero la mejor, y que merece la pena resaltar aquí, es esta: ¿cuándo fue la última vez que vio a un grupo de desarrollo de software que no tuviera por delante un montón de trabajo? En un mundo que cambia sutilmente, en una economía que se hace cada vez más compleja y más centrada en la información, habrá siempre abundancia de trabajo y una demanda saludable de gente que pueda conseguir que los ordenadores hagan cosas; sin importar cuánto tiempo y cuántos secretos se publiquen.

Para el propósito de examinar el propio mercado del software, sería útil clasificar los tipos de software según la capacidad para describir el servicio que ofrecen mediante estándares técnicos abiertos, lo que se correlaciona bien con cómo de comoditizado se ha hecho el servicio subyacente.

Este eje se corresponde razonablemente bien con lo que la gente normalmente piensa cuando habla de “aplicaciones” (no comoditizados, estándares técnicos abiertos débiles o inexistentes), “infraestructura” (servicios comoditizados, estándares fuertes) y “middleware” (parcialmente comoditizado, estándares técnicos efectivos pero incompletos). Los casos paradigmáticos en la actualidad serían un procesador de textos (aplicación), una pila TCP/IP (infraestructura) y un motor de bases de datos (middleware).

El análisis de beneficio que hicimos antes sugiere que las infraestructuras, aplicaciones y middleware se transformarán de manera diferente y presentarán diferentes equilibrios entre código abierto y cerrado. También sugirió que la prevalencia del open source en un área particular de software sería una función de si hay efectos de red sustantivos que operen ahí, cuáles son los costes del fallo, y hasta qué punto el software es un bien crítico para el negocio.

Podemos aventurar algunas predicciones si aplicamos estas heurísticas no a productos individuales sino al segmento completo del mercado de software. Vamos allá:

La infraestructura (Internet, la Web, los sistemas operativos y los niveles inferiores del software de comunicaciones que tiene que traspasar fronteras entre agentes en competencia) será casi todos open source, mantenidos cooperativamente por consorcios de usuarios y por organizaciones de distribución y servicios que actúan por beneficio, con un papel semejante al de Red Hat hoy.

Las aplicaciones, por otro lado, tendrán la mayor tendencia a permanecer cerradas. Habrá circunstancias en las que el valor de uso de un algoritmo o tecnología secretos serán lo suficientemente altos (y los costes asociados con la falta de fiabilidad suficientemente bajos, y los riesgos asociados con un monopolio del fabricante suficientemente tolerables) como para que los consumidores sigan pagando por software cerrado. Esto es más probable que siga siendo cierto en aplicaciones individuales para mercados verticales donde los efectos de red son débiles. Nuestro ejemplo anterior del aserradero es uno de estos; el software de identificación biométrico parece, de entre los candidatos de 1.999, ser otro.

El middleware (como bases de datos, herramientas de desarrollo, o los extremos personalizados de las pilas de protocolos de las aplicaciones) estará mas mezclado. Si las categoría de middleware tienden a ser cerradas o abiertas parece probable que dependa del coste de los fallos, donde los mayores costes crean presión del mercado hacia una mayor apertura.

Para completar la imagen, sin embargo, necesitamos observar que ni las “aplicaciones” ni el “middleware” son en realidad categorías estables. Anteriormente vimos que las tecnologías de software parecen atravesar un ciclo de vida natural de racionalmente cerrado a racionalmente abierto. La misma lógica se aplica en general.

Las aplicaciones tienden a convertirse en middleware según se desarrollan técnicas estandarizadas y porciones del servicio de comoditizan. (Las bases de datos, por ejemplo, se convirtieron en middleware después de que el SQL desacopló los front end de los motores). Según se comoditicen los servicios middleware, tenderán a su vez a convertirse en infraestructuras open source; una transición que estamos viendo en los sistemas operativos ahora mismo.

En un futuro que incluye la competición del open source, podemos esperar que el destino final de toda tecnología de software sea o morir o formar parte de la propia infraestructura abierta. Aunque esto no sea muy buena noticia para los emprendedores a los que les gustaría obtener rentas del software cerrado para siempre, sugiere que la industria del software en general seguirá siendo empresarial, con nuevos nichos abriéndose constantemente por arriba (aplicaciones) y un ciclo de vida limitado para los monopolios cerrados según sus categorías de productos se conviertan en infraestructura.

Por ultimo, por supuesto, este equilibrio será estupendo para los consumidores de software que están dirigiendo el proceso. Más y más software de calidad estará permanentemente disponible para ser usado y construir sobre él, en lugar de ser discontinuado o cerrado en el cofre de alguien. El caldero mágico de Ceridwen es, al final, una metáfora demasiado débil; porque la comida se consume o caduca, mientras que el software puede durar para siempre. El mercado libre, incluyendo en su más amplio sentido libertario todas las actividades no forzadas, sean negocios o regalos, puede producir para todos una riqueza de software que crezca incesantemente.

Epílogo: Por qué cerrar un Driver hace perder dinero a su fabricante

Los fabricantes de hardware de periféricos (tarjetas ethernet, controladores de disco, tarjetas de video y similares) han sido históricamente reacios a abrirse. Esto está cambiando ahora, con jugadores como Adaptec y Cyclades que comienzan a liberar de manera rutinaria especificaciones y código fuente de drivers para sus tarjetas. Sin embargo, todavía hay resistencia ahí fuera. En este apéndice intentaré disipar varios de los malentendidos económicos que la sostienen.

Si eres un fabricante de hardware, puedes temer que al liberar los fuentes estés revelando cosas importantes acerca de cómo trabaja tu hardware que los competidores podrían copiar, ganando así una ventaja competitiva injusta. En los días de los productos con ciclos de vida de tres a cinco años esto era un argumento válido. Hoy, el tiempo que los ingenieros de tu competencia necesitaría invertir en copiar y entender la copia es una porción dañinamente grande del ciclo de producto, un tiempo que no están invirtiendo en innovar o diferenciar su propio producto.

Esta no es una visión nueva. El antiguo jefe de la KGB Oleg Kalugin plantea el caso bien:

Por ejemplo, cuando robamos IBM en nuestros proyectos, o algunas otras áreas en la electrónica donde el Oeste hacía grandes avances y nosotros íbamos por detrás, nos llevaba años implementar los resultados de nuestros esfuerzos de inteligencia. Para entonces, en cinco o siete años, el Oeste había avanzado, y nosotros teníamos que robar una y otra vez, y quedábamos más y más atrás.

Pero Rudyard Kipling lo dijo mejor en su poema El Mary Gloster, hace casi un siglo. Escribió:

Y me preguntaron cómo lo hice, y yo les di el texto de la Escritura,“Mantén tu luz de manera que brille un poco por delante de lo siguiente” Ellos copiaron todo lo que pudieron seguir, pero no pudieron copiar mi mente,y les dejé sudando y robando un año y medio por detrás.

La aceleración del tiempo en Internet hace que este efecto muerda más fuerte. Si estas de verdad por delante del juego, ¡el plagio es una trampa en la que tú quieres que caigan tus competidores!

En cualquier caso, estos detalles no permanecen ocultos mucho tiempo en estos días. Los drivers de hardware no son como los sistemas operativos y las aplicaciones; son pequeños, fáciles de desensamblar y fáciles de clonar. Incluso un programador novato adolescente puede hacer esto; y a menudo lo hacen.

Hay literalmente miles de programadores de Linux y FreeBSD ahí fuera con la capacidad y la motivación para construir drivers para una tarjeta nueva. Para muchas clases de dispositivo que tenga interfaces relativamente simples y estándares bien conocidos (como controladores de discos y tarjetas de red) estos hackers ansiosos pueden a menudo prototipar un driver casi tan rápido como podría hacerlo tu propia empresa, incluso sin documentación y sin desensamblar un driver existente.

Incluso para dispositivos más complejos como tarjetas de video o de sonido, no hay mucho que puedas hacer para frustrar a un programador listo armado con un desensamblador. Los costes son bajos y las barreras legales porosas; Linux es un esfuerzo internacional y siempre hay una jurisdicción en la que la ingeniería inversa sea legal.

Para tener mayor evidencia de que todo esto es cierto, examina la lista de dispositivos soportados en el kernel de Linux y observa el ritmo al que se añaden otros nuevos, incluso sin el soporte del fabricante.

Otra buena razón para abrir tus drivers es que puedes concentrarte en la innovación. Imagina que ya no tienes que gastar el tiempo y el sueldo de tu equipo interno en reescribir, probar y distribuir nuevos binarios para cada nuevo kernel según aparece. Seguramente tendrás cosas mejores que hacer con todo ese talento.

Otra buena razón más: nadie quiere esperar seis meses para que salga un parche. Si tienes alguna competencia open source, es probable que te entierren sólo por esta razón.

Por supuesto, está el efecto de protección frente al futuro al que ya nos hemos referido. Los clientes quieren open source porque saben que extenderá el ciclo de vida del hardware más allá del punto hasta el que es efectivo desde el punto de vista del coste para ti soportarlo.

La mejor razón, sin embargo, es porque vender hardware es lo que produce dinero para ti. No hay ninguna demanda en el mercado para tu secreto; de hecho, es más bien al contrario. Si tus drivers son difíciles de encontrar, si tienen que ser actualizados frecuentemente, o si (lo peor de todo) se ejecutan mal, esto se refleja mal en tu hardware y venderás menos. Abrir los fuentes puede resolver estos problemas e incrementar tus ingresos.

¿El mensaje? Mantener tu driver secreto parece atractivo a corto plazo, pero es probablemente una mala estrategia a largo plazo (y más aún si estás compitiendo con otros fabricantes que ya son abiertos). Pero si debes hacerlo, graba el código en una ROM en la placa. Después publica el interfaz de la ROM. Libera tanto como sea posible para construir tu mercado y demostrar a los clientes potenciales que crees en tu capacidad para pensar e innovar más que tus competidores allí donde importa.

Si permaneces cerrado normalmente tendrás lo peor de los dos mundos: tus secretos podrán ser revelados, no tendrás ayuda para el desarrollo gratuita, y no habrás malgastado el tiempo de tus competidores más estúpidos en la clonación. Pero lo más importante, perderás una vía para extender la adopción temprana. Un mercado grande e influyente (la gente que gestiona los servidores que ejecutan Internet y muchos CPDs de empresas) identificarán a tu compañía como estúpida y defensiva, porque no eres consciente de estas cosas. Entonces comprarán sus placas a alguien que lo sea.

Notas

[SC] El problema de la infraprovisión en realidad escalaría linealmente con el número de usuarios si suponemos que el talento de programación está distribuido uniformemente en la población de usuarios del proyecto cuando este se expande en el tiempo. Este no es, sin embargo, el caso.

Los incentivos discutidos en [HtN] (y algunos otros más convencionales desde el punto de vista económico) implican que la gente cualificada tiende a buscar proyectos que satisfagan sus intereses, además de los proyectos que les buscan a ellos. Según esto, la teoría sugiere (y la experiencia tiende a confirmar) que las personas más valiosas (más cualificadas y motivadas) tenderán a descubrir proyectos para los que encajen bien relativamente pronto en el ciclo de vida del proyecto, con una caída correspondiente más adelante.

Faltan datos empíricos, pero en base a la experiencia sospecho fuertemente que la asimilación de talento sobre la vida de un proyecto en crecimiento tiende a seguir una clásica curva logística.

[SH]Shawn Hargreves ha escrito un buen análisis de la aplicabilidad de los métodos open source a los juegos: Jugando al juego Open Source.

[DPV] Nota para contables: el argumento de que los costes del servicio al final inundan el precio fijo inicial todavía funciona si pasamos de dólares constantes al valor presente descontado, porque el futuro ingreso por ventas se descuenta en paralelo con los futuros costes de servicio.

Una replica similar pero más sofisticada a este argumento es observar que, por copia, los costes de servicio pasan a ser cero cuando el comprador deja de usar el software: por tanto, todavía puedes ganar si el usuario se para antes de que haya generado demasiado coste de servicio. Esta es básicamente otra forma del argumento de que la asignación de precios según el modelo de fábrica recompensa la producción de shelfware. Quizá una manera más instructiva de expresarlo sería que el riesgo de que sus costes de servicio inunden los ingresos por compra aumenta con el periodo esperado de utilidad del software. Así, el modelo de fábrica penaliza la calidad.

[WG] Wayne Gramlich [email protected] ha propuesto que la persistencia del modelo de fábrica se debe parcialmente a reglas de contabilidad anticuadas, formuladas cuando las máquinas y los edificios eran más importantes y las personas menos. Los libros de contabilidad de las compañías de software muestran los ordenadores, el mobiliario de oficina y los edificios como activos y los programadores como costes. Por supuesto, en realidad, los programadores son los verdaderos activos y los ordenadores, equipos de oficina y edificios no tienen la menor importancia. Esta valoración perversa se sostiene por la presión de los IRS y el mercado de valores hacia reglas de contabilidad estables y uniformes que reduzcan la complejidad de asignar una cifra en dólares al valor de la compañía. El arrastre resultante ha provocado que las reglas se alejen de la realidad.

Desde este punto de vista, asignar un precio alto a los bits del producto (independiente del valor del servicio futuro) es parcialmente una forma de mecanismo de defensa, una manera de acordar entre todas las partes implicadas la pretensión de que los cimientos ontológicos no se han derrumbado bajo las reglas estándar de contabilidad.

(Gramlich también señala que estas reglas subyacen en la extraña y a menudo autodestructiva manía de adquisición en la que caen muchas compañías de software después de salir a bolsa. “Normalmente las compañías de software lanzan algunas acciones adicionales para construir un equipo de guerra. Pero no pueden gastar este dinero para mejorar su plantilla de programadores, porque las reglas de contabilidad mostrarían que están incrementando los gastos. En lugar de eso, la compañía de software tiene que crecer comprando otras compañías de software, porque las reglas de contabilidad le permiten tratar la adquisición como una inversión.”)

Para ver un ejemplo paradigmático de bifurcación que sigue a la defección, consulte la historia de OpenSSH. Este proyecto fue tardíamente bifurcado de una versión temprana de SSH (Secure Shell) después de que ésta pasara a una licencia cerrada.

Bibliografía

[CatB] La Catedral y el Bazar.

[HtN] Homesteading the Noosphere.

[DL] De Marco y Lister, Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6)

Agradecimientos

Varias conversaciones estimulantes con David D. Friedman me ayudaron a refinar el modelo de “comunes inverso” de la cooperación open source. También estoy en deuda con Marshall van Alstyne por señalar la importancia conceptual de los bienes de información rivales. Ray Ontko del Indiana Group proporciono crítica constructiva. Muchas personas en auditorios ante los que he dado charlas en el año que va hasta Junio de 1.999 también ayudaron: si es una de ellas, usted sabe quién es.

Todavía es otro testimonio del modelo open source que este ensayo haya sido mejorado sustancialmente por el feedback del email que he recibido en los días siguientes al lanzamiento inicial. Lloyd Word señaló la importancia de que el open source estuviera “a prueba de futuro”, y Doug Dante me recordó el modelo de negocio “Libera el Futuro”. Una pregunta de Adam Moorhouse condujo a la discusión de los beneficios de la exclusión. Lionel Oliveira Gresse me dio un nombre mejor para uno de los modelos de negocio. Stephen Turnbull me llamó la atención sobre el descuidado tratamiento de los efectos de los aprovechados. Anthony Bailey y Warren Young corrigieron algunos datos en el caso de estudio de Doom. Eric W. Sink contribuyó con la visión de que el modelo de fábrica recompensa al shelfware.

Fuente original

Categoría:Derechos de autor