El impacto del FLOSS en el concepto de "valor"

En los artículos previos de esta serie sobre FLOSS, he analizado las diferencias de licenciamiento y distribución entre el Free/Libre Open Source Software (FLOSS) y el software propietario, así como algunos ejemplos del impacto del FLOSS en la interoperabilidad y los estándares. También identificamos algunos modelos que dan origen a los proyectos y sus formas de financiamiento.

En este artículo analizaré algunos de los impactos comerciales que ha provocado el FLOSS en la industria del software y mi opinión sobre algunos cambios que provoca en ciertos ámbitos particulares.

El impacto en el concepto de "valor"

Tal como analizamos en el artículo anterior, el enfoque FLOSS (en forma independiente de las consideraciones filosóficas) tiende a asegurar la interoperabilidad, permitiendo la interconexión entre sistemas disímiles, mediante protocolos abiertos y definidos por la Comunidad. Eso en sí, indudablemente es un gran beneficio desde un punto de vista técnico.

Pero otro impacto del FLOSS, tan "visible" e importante como el anterior, es la modificación del concepto de "valor" de las diversas aplicaciones de software. Y aquí no estoy hablando de precio, sino de qué tan importante para el usuario es una aplicación.

Esta distinción es crítica, ya que el "valor" incidirá en otro aspecto fundamental para el desarrollo de la industria del software: cuánto está dispuesto a pagar el usuario por ese valor.

La continua destrucción del valor agregado
(O cómo los clientes cada vez exigen más)

Una característica del mundo tecnológico y en particular en la industria del software, es la continua modificación del concepto de "valor", en forma mucho más profunda que la evolución del "valor agregado" aplicado en otras industrias.

Un ejemplo básico es cuando junto con un pack de latas de bebida de Coca Cola y como forma de promoción, se incorpora como "valor agregado", un vaso con la imagen conmemorativa del último mundial de fútbol. En ciertos casos será un regalo, y en otros el cliente estará dispuesto a pagar un pequeño sobreprecio. Pero el hecho es que dicho "valor agregado" temporal, no modifica la esencia del "producto": La Coca Cola per se sigue siendo un producto de buena calidad. Y para el cliente, el "valor" de la Coca Cola seguirá siendo alto, en forma independiente de cuantos vasos, chapitas u otros promocionales se incorporen para aumentar la fidelidad.

Pero en el caso de la tecnología y particularmente el software, es muy distinto.

Por ejemplo, el "control remoto" de un televisor era un elemento de "alto valor", incorporado como una gran innovación a un televisor tradicional. El "cliente/consumidor" reconocía en esta nueva funcionalidad un gran avance, y estaba dispuesto a pagar "mucho" para tener la opción del control remoto, en los televisores que lo incorporaban inicialmente.

Pero en un mercado con múltiples competidores y consecuencia del continuo desarrollo tecnológico, el "control remoto" pasó a ser un elemento inherente al "producto televisor", pasando a formar parte de la "oferta básica". El "valor" de dicha funcionalidad dejó de ser un diferenciador. Un televisor que hoy no incorpore un "control remoto" como parte de sus prestaciones básicas es un mal producto, y al perder dicha capacidad diferenciadora su "valor", indudablemente el cliente no estará dispuesto a pagar por eso.

En el caso de la industria financiera, a mediados de la década del '90, un cliente estaba dispuesto a "pagar más" en un banco que ofreciera sistemas de consulta remota por vía telefónica o vía Internet. Hoy, un banco que no ofrezca dichos servicios, simplemente no tiene opción de competir. Ni tampoco puede cobrar por ellos.

Por ello, las ventajas competitivas generadas en cualquier industria sobre la base de "desarrollos tecnológicos", son temporales y empatables, con el tiempo suficiente y los recursos adecuados.

Y en el mediano plazo, esas ventajas competitivas tienden a ser un "commodity", es decir, dejan de generar un factor diferenciador de "valor", desde el punto de vista del cliente.

Un producto que cae a la categoría de "commodity" es la pesadilla de un Gerente de Marketing. Y por ello, en particular en la industria tecnológica y de servicios, los responsables de la estrategia de diseño de productos, viven con las zapatillas de correr puestas, tratando de liderar los procesos de "destrucción de valor" en forma continua.

Como último antecedente, es relevante considerar que al existir múltiples ofertas que responden al mismo "valor" para el cliente, siendo algunas de esas opciones de "precio cero" (ahora sí que podemos decir "gratis"), por un razonamiento y un comportamiento económico "racional", la demanda optará por las soluciones "gratuitas" (siempre y cuando respondan al mismo nivel de exigencias que requiere el "negocio" del cliente).

El FLOSS sin lugar a dudas ha modificado los parámetros tradicionales sobre los cuales se ha creado la industria de software. La inmensa oferta de aplicaciones basadas en la colaboración y el enfoque FLOSS, con millones de programadores distribuidos en el planeta colaborando en la construcción de "commodities" de software, ha hecho que la industria de los "constructores de productos propietarios" se vea afectada.

Pero no en forma total. Y solamente en algunos nichos específicos.

Es en esas áreas donde focalizaré ahora mi análisis.

Cuando lo que antes era de "alto valor" se transforma en un commodity

Muchas aplicaciones que en los "antiguos tiempos" eran de "alto valor" para un cliente (por ejemplo, un editor de texto, un compilador, una calculadora o una base de datos sencilla), con el paso del tiempo y con una gran base de "conocimiento empaquetado de libre disposición", han ido perdiendo su valor.

De una u otra forma, las "prestaciones básicas" de software (y por las cuales antes se podía "cobrar bien") se han transformado gradualmente en un "commodity" y con múltiples alternativas para elegir.

Pero ese fenómeno no es exclusivo por causa del FLOSS.

Mi opinión es que la "commoditización" surge en primer lugar producto de la alta competencia de la propia industria tecnológica.

La natural competencia entre los proveedores de plataformas básicas, las cuales fueron incorporando diversas herramientas como parte de la oferta básica y sin exigir al cliente que tuviera que "pagar adicionalmente" por ello, genera en forma continua productos más complejos, modificando la esencia de la oferta inicial, haciendo que los antiguos diferenciadores pasen a formar parte esencial de los nuevos productos.

Por ejemplo, la aparición del Macintosh a mediados de los '80 (y previamente Lisa), nos sorprendió a muchos, ya que Apple incorporaba como parte del suite básico del sistema operativo MacOS, una serie de herramientas que históricamente en otras plataformas, eran productos "caros" y (en esos tiempos) de "alto valor".

Por ejemplo, aplicaciones de diseño gráfico como MacPaint y procesadores de texto como MacWrite, incluidas como parte del suite de herramientas básicas con MacOS y el Macintosh, ofrecían prestaciones básicas de diseño, formateo e impresión muy avanzadas para ese tiempo, como parte del bundle del equipo. Esas prestaciones eran más que suficientes para resolver las necesidades del mercado SOHO (Small Office, Home Office), iniciando la revolución del "desktop publishing". A través de la plataforma básica del Macintosh, cualquier usuario podía hacer una carta simple o diseñar una invitación de cumpleaños.

La respuesta del proveedor dominante de sistemas operativos de escritorio, en ese momento Microsoft, no se dejó esperar. Y la versión inicial de Windows incorporó una serie de prestaciones mínimas para "tratar de empatar" esa oferta básica, sin llegar a incorporar las funcionalidades de los suites de ofimática de avanzada, pero ya marcaba el inicio de la "commoditización" de los productos de ofimática, tema que analizaremos en detalle más adelante en este artículo.

FLOSS en la infraestructura básica

Hoy día vivimos un fenómeno similar al que ocurrió en los viejos tiempos del '80, como explicamos en el artículo anterior, cuando los dominantes de la industria del hardware y el software de sistemas "rechazaban" esta amenaza llamada TCP/IP (porque en el mediano plazo les hacía perder sus "ventajas comparativas" obtenidas gracias al lock-in tecnológico).

Lo mismo ocurre hoy con la industria del software de aplicaciones, en aquellos ámbitos donde la aparición del FLOSS "transforma" productos que antiguamente eran de "alto valor agregado" en commodities. Y en muchos casos, gratuitos.

Hay ejemplos claros de este proceso de competencia creciente entre productos propietarios y soluciones FLOSS, en el ámbito de la "infraestructura".

Por ejemplo, Linux y Apache (o en general lo que se conoce como el stack LAMP) aumentan gradualmente su participación de mercado para el desarrollo e implementación de soluciones WEB, en reemplazo de otras "arquitecturas propietarias". ¿Hasta dónde? No lo podemos predecir, porque depende de muchos otros factores adicionales, como por ejemplo, la estabilización de las participaciones de mercado a nivel de sistemas operativos, la disponibilidad de recursos humanos calificados, consideraciones políticas, disponibilidad de aplicaciones especializadas, etc.

Hasta ahí, todo iba más o menos bien, estando hasta hace un par de años la competencia en la infraestructura básica, restringida a los proveedores de hardware y de sistemas operativos.

Pero una situación que era fácil de predecir y tarde o temprano iba a llegar, es la creciente oferta FLOSS que empieza a "invadir" el mundo de las "aplicaciones de usuario final", donde hay mucho dinero en juego y de muchos actores relevantes.

Y eso provoca otro impacto importante en la industria, particularmente en el segmento de la ofimática, que en mi opinión es otro segmento de commoditización creciente.

FLOSS en las aplicaciones de usuario final

La creciente penetración (con una notable y sorprendente evolución) de soluciones de ofimática como OpenOffice, ha provocado que en este tiempo, empresas como IBM liberen en forma gratuita su plataforma de ofimática Lotus Symphony, con la esperanza de obtener "valor" por la vía de otros productos complementarios o servicios por los cuales cobrar.

Por otro lado, Microsoft ha impulsado en forma fallida su formato propietario OOXML hacia un estándar internacional, con el claro fin de proteger su plataforma de productos Office, que representa un importante segmento de sus ingresos.

Personalmente, y a diferencia de algunos analistas, no creo que la reacción de IBM sea una estrategia "contra" Microsoft.

Simplemente, creo que es una continuidad de la estrategia de BigBlue para acercarse al mundo FLOSS y moverse junto con las tendencias de la industria, generando alianzas temporales para privilegiar y defender sus soluciones de hardware, sus servicios de consultoría y sus aplicaciones propietarias de "alto valor agregado" ... y de "alto precio".

IBM, a pesar de la constante sátira que se hace, no es un dinosaurio decadente. En absoluto.

Personalmente pienso que IBM es una empresa muy inteligente en la definición de sus estrategias de largo plazo y que la mantiene como un actor relevante y vigente, a pesar de todos los vaivenes de la industria, que ven aparecer y desaparecer actores en forma continua.

IBM es un enorme elefante astuto, pero que se mueve ágilmente en patines y si es necesario aprende a subirse a un skate, que reconoce tendencias irrevocables, algunas veces con mucha anticipación y otras en la cúspide de un fracaso rotundo. A su pesar, enterró en algún momento OS/2 con todo el costo económico y de imagen asociado, reconociendo la tendencia en el desktop con un actor dominante como Microsoft. Enterró su modelo de red SNA abrazando la causa de TCP/IP. Y desechó sus arquitecturas de microcanal moviendo sus arquitecturas hacia ISA. Y así, podríamos continuar. IBM es un ejemplo de adaptación en los modelos competitivos de "destrucción de valor", moviéndose a segmentos más altos en la cadena de "valor", adaptándose a las tendencias y estándares naturales de la industria, a pesar de asumir altos costos.

Y se adapta a las tendencias irrevocables que tarde o temprano llegarán, pero con una ventaja fundamental ... aprende de sus errores y sale fortalecido.

Al igual que como TCP/IP y las plataformas LAMP, las soluciones FLOSS de ofimática (en mi opinión en un horizonte máximo de 3 años), terminarán siendo commodities integrados o disponibles como parte de los sistemas operativos subyacentes.

Y no me extrañaría que en algunos años, IBM decida seguir declinando en algunos casos o liberando soluciones propietarias en otros, en la medida que las tendencias de la industria las definan como un commodity, manteniendo su posición dominante en los segmentos de "alto valor" de la industria ... y por consecuencia, de los bolsillos de los clientes.

Así como el básico editor de archivos de texto y una calculadora fueron "integradas" como parte de las componentes mínimas en cualquier sistema operativo de usuario, sobre la base de aplicaciones portables, las plataformas de ofimática formarán parte del "paquete estándar", ya sea en un notebook, un PDA o un computador de escritorio, más temprano que tarde.

Necesidades comunitarias

Había terminado de redactar este artículo, pero no me habría quedado tranquilo sin dejar de identificar otro escenario en el cual el FLOSS genera también modificaciones a la industria del software. Y es en aquellos escenarios donde se pueden identificar modelos en los cuales la competencia y la colaboración coexisten, fusionados en el neologismo de la "coopetición". En dicho caso, los modelos FLOSS pueden surgir como una consecuencia natural de la "agregación de demanda" de una industria específica.

Un ejemplo es el anuncio hace un tiempo de un proyecto colaborativo en la industria automovilística japonesa, quienes crearon la Japan Automotive Software Platform Architecture (JasPar), con el fin de definir una única arquitectura de software para el control interno de los vehículos, y que sea común a diversos fabricantes de autos de Japón.

No sé si el modelo final será Open Source o no. Y la apertura podría generar impactos importantes y oportunidades interesantes para incluso nosotros como desarrolladores de tecnología en Latinoamérica.

Pero el razonamiento detrás de esta iniciativa es bastante simple. No es un problema filosófico ni político. Es simplemente una muy adecuada decisión estratégica de negocios.

Al momento de la redacción de este artículo, las compañías que forman este consorcio son Toyota, Nissan, Honda y Denso. Estas compañías llegaron a la conclusión de que "competir" en el sistema operativo básico y la interacción de componentes internas en un vehículo no es un modelo eficiente. La competencia entre dichas compañías estará dada por el precio, las prestaciones en la cabina, la cadena de dealers, los servicios de pre y post venta, el "luxury" y la imagen, etc.

Los modelos de programación dinámica que definen el nivel de carburante y control de inyectores, son modelos físicoquímicos públicos y que mal que mal, son de amplio conocimiento y pueden ser configurados caso a caso, por lo cual para las plataformas de software básico, no hay "valor agregado" en que cada compañía diseñe, construya, mantenga y soporte arquitecturas propietarias de software básico para la inyección de carburantes. Y así, suma y sigue.

Por lo tanto, es mucho más eficiente definir un proyecto colaborativo, que asegure un uso eficiente de los recursos, seguridad y estabilidad. Y principalmente, un modelo de interoperabilidad, que integre a todos los proveedores de partes y piezas de la industria, en una cadena de valor integrada y que permita una alta flexibilidad en la oferta. Este modelo de negocios está claramente descrito en la estrategia global del proyecto, en competencia al modelo estadounidense y europeo, que optan por la competencia e integración vertical, a partir de una oferta quizás más robusta pero menos flexible.

Así como el caso de JasPar, podemos encontrar múltiples otros ejemplos y en diversas industrias y dominios del conocimiento, en los cuales es posible diseñar modelos tecnológicos de coopetición, que permitan el desarrollo de plataformas tecnológicas colaborativas, manteniendo el "valor agregado" como parte de la diferenciación de cada actor.

Este modelo en particular, fue enunciado por Verónica Achá (querida amiga y otra SushiKnight ;-), representante de Innova-Corfo en la mesa FLOSS del Ministerio de Economía hace un par de semanas.

Verónica planteó una iniciativa incipiente para generar oportunidades de desarrollo tecnológico en industrias productivas en Chile, aplicando modelos FLOSS para las plataformas tecnológicas base, permitiendo modelos de competencia en las aplicaciones de "alto valor" generadas por la industria. Este modelo muchos lo consideramos muy interesante, ya que toma lo "mejor de los mundos", aportando capacidades de competencia internacional para la industria tecnológica y de software nacional, y capacidades competitivas importantes para segmentos productivos de nuestro país.

En términos más simples, un modelo tipo JasPar (el de los fabricantes de automóviles japoneses) pero aplicado a la industria del salmón, el vino, la minería, etc.

¿Y qué queda para los que vivimos en esta industria?

Finalmente, en este escenario de tendencias dado por la continua "destrucción de valor" y "commoditización" permanente del software ... ¿qué queda en el largo plazo para los que vivimos de esta industria?

¿Deberemos transformarnos en lemmings suicidas para asegurar la supervivencia de algunos pocos afortunados que logren vivir a partir de servicios altamente especializados, o peor aún, dejar de trabajar en los temas que nos apasionan y dedicarnos a la agricultura básica o la alfarería?

No creo que sea así. Muy por el contrario. Y tampoco es necesario presentar un bonito Curriculum Vitae en el sitio WEB de IBM y posteriormente comprarse un par de trajes, lindas camisas blancas y sobrias corbatas. :-)

En el próximo artículo de esta serie, discutiré el por qué en mi opinión los modelos de desarrollo de software futuro, serán un permanente complemento entre soluciones FLOSS para los "commodities" de aplicación, soluciones propietarias para "requerimientos específicos de negocio" y plataformas de "servicio" basadas en estándares de interoperabilidad.

Por ahora, para mis colegas de la industria de software (y sólo para mantener el suspenso) hay "buenas noticias", pero deberán esperar algunos días hasta el próximo artículo. :-)

Stay tuned!