Modelos de Negociopara proveedores de

Software Libre

Sergio Montoro Ten

Objetivos de la sesión

Conocer los modelos de negocio posibles para un fabricante de software o proveedor de servicios tecnológicos.

Evaluar las mejores prácticas y trampas a evitar en cada uno de dichos modelos de negocio.

El objetivo nº1 de cualquier negocio

El objetivo de cualquier negocio

es crear clientes y mantenerlos.

Peter Drucker

Cuando se entra hay que tener un plan para salir

Una gran parte de las empresas no se crean para explotarlas, sino para salir a bolsa o para vendérselas a otro.

Valor del negocio

Los clientes pagarán por la empresa en función del número de clientes que tenga (o que piensen que puede tener).

Ergo el primer factor a maximizar en una empresa que pretenda ser comprada es el número de clientes (reales o potenciales).

El GRAN problema del modelo de negocio del Software Privativo

Para un fabricante, básicamente es igual de caro crear el software que mantenerlo vivo.

Sin embargo, en el modelo privativo clásico, se carga un alto precio por la licencia al principio y (en teoría) menos precio por las actualizaciones.

El modelo es insostenible a menos que:

a) las ventas crezcan todos los años de modo que las licencias cubran los costes de mantenimiento.

o b) se cobre prácticamente lo mismo por la licencia que por las actualizaciones, -lo cual suele ser visto como algo abusivo e ilógico por parte del cliente-.

Valor de uso valor de venta

Lo primero que hay que distinguir es

el valor de uso: beneficios que el cliente obtiene con la utilización del programa;

del valor de venta:dinero que estaría dispuesto a pagar por ese mismo software.

¿Dónde está el valor del software?

Sólo una pequeña fracción del precio que el cliente paga por un software está en el propio código. El resto es un valor que proviene de la posición del producto en el mercado y de la capacidad del proveedor para dar servicio.

En otras palabras el software es una industria de servicios operando bajo la persistente pero infundada ilusión que es una industria de manufacturas.

¿Cómo decidir si se debe abrir o no el código?

1º) Hacer una estimación de las rentas potenciales de los secretos y de las rentas potenciales derivadas de abrir el código.

2º) Si las ganancias de los secretos superan las del código abierto, mantener el software privativo, en otro caso liberarlo.

La joya de la corona

Se tiene tendencia a pensar que el código fuente es la joya de la corona de una empresa de desarrollo, pero...

¿Es así realmente en todos los casos?

Beneficios para el clientede que el código sea abierto

1.Puede sentir su inversión mejor protegida frente al hipotético caso de que el fabricante cierre el negocio.

2.Puede entender mejor cómo funciona el software en el caso de que el vendedor no sepa explicárselo.

3.Puede corregir el mismo errores o agujeros de seguridad que le afecten.

4.Puede hacer él mismo portings a otras arquitecturas.

5.Puede crear extensiones con sus propias funcionalidades.

Por consiguiente:

El Software Libre es mayormente un producto para desarrolladores, no para usuarios. Que el código sea abierto sólo le importa mayormente a aquellos que pueden hacer algo realmente con los fuentes.

Resumen de tres ideas principales

1.Lo más importante es el número total de clientes.

2.El valor de uso y el valor de venta son cosas muy diferentes

3.El Software Libre es una experiencia de desarrollador no de usuario.

Antecedentes

El primer ensayo importante de referencia sobre modelos de negocio de software libre es El Caldero Mágico publicado por Eric Raymond en 1999.

Posterioremente aparecieron ampliaciones reseñables de Franck Hecker y Tim O'Reilly.

Antes del empezar:El peor enemigo de un plan de negocio

El peor enemigo de un plan de negocio presente es el pasado y el futuro.

Modelos de valor de venta indirectos1.Posicionamiento en el mercado

2.Asegurar el futuro

3.Regalar la receta, y abrir un restaurante

4.Integrar componentes commodities

5.Accesorizar

6.Liberar el futuro y vender el presente

7.Liberar el software y vender la marca

8.Liberar el software y vender contenidor

9.Ofrecer licencia duales

Modelos de valor de venta indirectos 1Posicionamiento en el Mercado

Se usa software open-source para crear o mantener una posición de mercado para un software propietario que genera un flujo directo de ingresos.

Caso de IBM WebSphere y Apache.

O en España Bitrock Installer.

Modelos de valor de venta indirectos 2Asegurar el futuroEste modelo es principalmente para fabricantes de hardware.

Los cuales, por ejemplo, abren el código fuente de sus drivers porque no tienen nada que perder y si mucho que ganar.

O como IBM usan GNU/Linux en Mainframes porque lo que en realidad les interesa vender

es la máquina y no el sistema operativo.

Modelos de valor de venta indirectos 3Regalar la receta y abrir un restaurante

En este modelo, uno abre el código del software para crear una posición de mercado, no para software cerrado (como en el modelo de Posicionamiento en el Mercado), sino para servicios.

Este era el modelo original de la mayoría de los vendedores de Linux, y en muchos de ellos fracasó, por motivos que veremos más adelante.

Modelos de valor de venta indirectos 4Integrar componentes commodities

En este modelo se crea un paquete basados en otros componentes y se vende todo como un conjunto.

Un ejemplo son los vendedores de aplicaciones bajo stack LAMP.

Modelos de valor de venta indirectos 5Accesorizar

En este modelo, se venden accesorios para software open-source.

Este es un caso muy típico, por ejemplo de fabricantes de CRM que ganan dinero vendiendo conectores con Outlook o LDAP.

Modelos de valor de venta indirectos 6Liberar el futuro y vender el presente

En este modelo, se distribuye software como binarios y fuentes con una licencia cerrada, pero que incluye una fecha de expiración en las previsiones de cierre.

La principal desventaja de este modelo es que su naturaleza cerrada tiende a inhibir la revisión y participación en las primeras fases del ciclo de vida, que es precisamente cuando más se las necesita.

Modelos de valor de venta indirectos 7Liberar el software y vender la marca

Se abre el código de una tecnología de software, se retiene una suite de pruebas o un conjunto de criterios de compatibilidad, y se le vende a los usuarios una marca certificando que su implementación de tecnología es compatible con todas las demás que lleven esa marca.

Esto es lo que ha hecho, por ejemplo Sun con Java.

My SQL es otra de las empresas que ofrece franquicias de su marca.

Modelos de valor de venta indirectos 8Liberar el software y vender contenidos

Se abre el código y se venden contenidos necesarios para que dicho software sea útil.

Caso Doom:

Cuando Doom fue lanzado a fines de 1993, su animación de tiempo real lo hacía algo totalmente único No sólo era por el impacto visual de la técnica, sino que por muchos meses nadie podia darse cuenta como podía ser logrado en los microprocesadores de baja potencia de la época. Esos secretos valían una seria ganancia. Además, la potencial ganancia de abrir las fuentes eran bajas.

Sin embargo, el mercado alrededor de Doom no se mantenía quieto. Competidores inventaron equivalentes funcionales de sus técnicas de animación (como Duke Nukem). Cuando estos juegos se comenzaron a devorar la porción de mercado de Doom, el valor de ganancia de los secretos se desvaneció.

Además, los esfuerzos pasa expandir esa porción de mercado trajeron nuevos desafíos tecnológicos - mejor confiabilidad, mas características de juego, partidas multijugador, etc. El mercado comenzó a desplegar ciertos efectos de red substanciales.

Todas estas tendencias aumentaron las ganancias de abrir las fuentes. En algún punto las curvas de ganancias se cruzaron y fué economicamente razonable abrir el código de Doom y cambiar el rumbo hacia hacer dinero en negocios secundarios, como antologías de escenarios de juegos. Y en un tiempo después de ese punto, la trancisión ocurrió. El código completo de Doom fue abierto a fines de 1997.

Modelos de valor de venta indirectos 9Licencia dual

Se ofrece una licencia libre a los clientes que no hagan uso comerial del software, y una licencia privativa a aquellos que lo exploten comercialmente.

Modelos híbridos

Los modelos híbridos consisten en retirar selectivamente alguna de las 4 libertades básicas, a un grupo de usuarios o a un uso concreto del producto.

Commercial Open Source

Consiste básicamente en una táctica de marketing engañoso, en la cual se ofrece un producto 100% privativo, y en modalidad Open Source otra versión muy inferior de dicho producto a la cual se han retirado precisamente las funcionalidades imprescindibles para los clientes que realmente pagan. El producto libre suele ser muy difícil de instalar (y a veces hasta de encontrar) y la empresa fabricante hace todo lo posible para que sólo se use como gancho para comprar el producto privativo.

Resumen de modelos de negocio1.Usar un producto libre para vender otro propietario

2.Usar un producto libre para vender otra cosa que no es software

3.Vender servicios y actualizaciones

4.Vender integración de otros componentes

5.Vender accesorios y piezas de recambio

6.Ofrecer licencias con temporalidad

7.Capitalizar una marca

8.Vender contenidos para un software libre

9.Ofrecer distintas licencias según el nº de usuarios.

10.Ponerse la etiqueta de Open Source sin serlo realmente.

Caso MySQL AB

MySQL AB tiene sus líneas de negocio basadas en tres diferentes áreas:

a)- soporte comercial y servicios de suscripción a los usuarios de MySQL.com,b) venta de licencias a terceros,c) franquicia de la marca.

Concretamente MySQL AB ofrece su aplicación de base de datos bajo dos licencias diferenciadas, una bajo GPL y otra bajo licencia EULA.

1. Libre para aquellos que son 100% compatibles con GPL. Si una empresa quiere redistribuir MySQL lo podrá hacer siempre de una manera libre y gratuita, siempre y cuando la aplicación sobre la que se distribuirá también sea GPL.

2. Libre para aquellos que nunca copien, modifican o distribuyan el código. La aplicación también será libre siempre y cuando el usuario no copiará, modificará o distribuirá el código de MySQL ni interna ni externamente, independientemente de la licencia que tenga la aplicación sobre la que se monte.

3. Uso comercial para todo el mundo. Si la aplicación no está licenciada bajo la GPL o algunas de las licencias compatibles con la OSI y aprobadas por MySQL AB, y se tiene la intención de distribuir el código interna o externamente, se necesitará una licencia comercial.

De esta manera obtiene ingresos no solamente por el modelo de Soporte, sino que la distribución de la aplicación bajo una doble licencia, permite la entrada de ingresos por esta vía.

Caso Oracle Unbreakable Linux I

En la Oracle OpenWorld de 2006 Larry Ellison presentó el nuevo programa Unbreakable Linux con el cual Oracle se lanzaba a competir en los servicios de soporte para RHEL contra la propia Red Hat.

Ellison plateó 3 grandes problema abiertos de las distros actuales:

1. El soporte y corrección de bugs es lento y precario.2. El soporte es caro (Red Hat cobra 1.499$ por una máquina con 2 procesadores)3. No existe protección legal frente a demandas por infracción de propiedad intelectual.

Y Oracle ofrecía:

1. Soporte de “miles de técnicos especializados”2. Mitad de precio que Red Hat3. Todo el stack disponible de un único proveedor

Pero el objetivo real es probablemente: devaluar Red Hat para comprarla barata y luego ir a por Novell. Lo cual se ve reflejado incluso en su política promocional. En las FAQ anuncian que todos los clientes de Red Hat y Novell que decidan cambiar a Oracle no tendrán que pagar nada durante el periodo de tiempo que su último contrato con Red Hat o Novell esté en vigor. En principio, las acciones de Red Hat cayeron 26% de un plumazo, suculento ahorro para un depredador potencial, sólo gracias al anuncio de una línea de negocio competitiva.

Caso Oracle Unbreakable Linux II

¿Qué hace Red Hat con sus precios en respuesta?

Absolutamente NADA. Lo mismo que Ferrari ignora la competencia de Kia.

El precio no es un factor determinante para vender software corporativoaunque algunos piensen lo contrario.

Resultado de los primeros 90 días:

Oracle Unbreakable Linux: 9.000 descargasRed Hat Enterprise Linux: 1.000.000 de descargas

Caso Oracle Unbreakable Linux III

¿Qué pasa realmente aquí?

1. Se está solucionando el problema que no es (un único stack del mismo proveedor). Funcionó para IBM en los 60-80 y para Microsoft, pero no es en realidad una necesidad acuciante de los clientes.

2. Falta de credibilidad en la oferta. Los clientes no se acaban de creer que el soporte de Oracle vaya a ser mejor que el de Red Hat.

3. Canal de ventas pobre frente a Microsoft e IBM. Los intermediarios no se fían de las tendencias fagocitarias de Oracle sobre el nicho de servicios.

4. Solución a los problemas de Oracle, no de los clientes.

(a) Los mercados de bases de datos y ERP de Oracle están muy maduros.

(b) Es difícil vender productos individuales (1+1=1,2)

(c) Facilita integrar otros productos también comprados por Oracle (BEA).

El problema con la venta de servicios

Existen dudas acerca de la sostenibilidad de negocios exclusivamente basados en vender soporte.

En diciembre de 2005 Jonathan Schwartz, CEO de Sun, defendía de la decisión de Sun de liberar Java Enterprise System como manera de aumentar los ingresos en los contratos de soporte porque ninguno de los clientes de JES lo usaría sin soporte.

Los argumentos de Schwartz fueron criticados por Matt Asay poniendo a Red Hat como ejemplo de empresa que aparentemente vende soporte pero en realidad vende actualizaciones de software, las cuales, además, cada vez le cuesta más que los clientes acepten pagar en forma de pre-pago de contratos de mantenimiento.

Lo que al parecer está sucediendo es que desde que se popularizó Internet, el soporte técnico humano tiene menos valor.

Problemas asociados a liberar un software propietario

1.Limpiar un código que nunca se pensó para ser escrutado.

2.Exposición a litigios por infracción de patentes.

3.Falsa imagen de que el producto va a ser abandonado.

4.A la mayoría de los clientes no les importan los fuentes, prefieren “builds oficiales” precompiladas.

5.El producto puede fragmentarse en forks incompatibles.

6.¿Cómo se da soporte técnico a clientes con versiones modificadas?

7.Miedo a que la competencia adquiera know-how de cómo está hecho.

8.Miedo a que la competencia saque forks substitutivos.

Necesidad de un marco regulatorio global para la propiedad intelectual

Si las leyes de propiedad intelectual fuesen homogéneas y se cumpliesen efectivamente en todo el mundo, habría mucha menos necesidad de mantener los fuentes cerrados, ya que se podrían imponer a los clientes los usos permitidos mediante contratos legales.

Resumen de 3 ideas clave

Confiar en la venta de soporte y servicios sin una marca sólida que los respalde no es buena idea.

No es fácil liberar un código que no se pensó

desde el principio para ser libre.

El marco legal vigente juega un papel crucial en los posibles modelos de negocio.

Parámetros que determinan si un proyecto libre tendrá éxito

1º) Comunidad.

2º) Innovación.

3º) Liderazgo.

4º) Transparencia.

5º) Netiqueta.

6º) Documentación.

7º) Licencia.

8º) Soporte.

9º) Desarroladores a tiempo completo.

Buenas prácticas para vender un software abierto

1ª) Debe ser una solución completa.

2ª) Debe contener una propuesta de valor concreta para el cliente final.

3ª) Debe haber un modelo de negocio para los revendedores e intermediarios.

4ª) Debe ser más barato de adoptar que de fabricar.

5ª) Debe dirigirse al nicho de mercado apropiado.

6ª) Debe contar con el apoyo de otros fabricantes.

7ª) Debe ser lo más global posible.

El mito del desarrollo en Comunidad

El mito del desarrollo en Comunidad es falso.

El 99% de los proyectos son desarrollados íntegramente por un grupo muy reducido de personas.

Incluso si se desarrolla en Comunidad, el modelo sólo funciona si estás dispuesto a perder el control sobre la evolución de las versiones de tu producto (caso Debian - Ubuntu)

Cómo mover a la gente a que participe1. La gente contribuye más cuando cree que sus aportes son únicos y especiales.

2. La gente contribuye más cuando cree que sus aportes serán reconocidos.

3. La gente contribuye más cuando cree que sus aportes serán de utilidad para otros miembros de La Comunidad.

4. La gente contribuye más cuando cree que recibirá una recompensa.

5. La gente contribuye más cuando existen objetivos claros.

5.1. Corolario: Los objetivos individuales motivan más que los grupales.

6. Si las metas fijadas no son creíbles la gente no se animará a participar.

7. La gente contribuye más cuando cree que el resultado de la cooperación colectiva será de utilidad directa para ellos mismos.

Tácticas anti-Open Source que empleantípicamente los fabricantes de Sw Privativo

1º) Otorgar licencias corporativas

2º) Ofrecer versiones gratuitas a los no-clientes

3º) Comprar la competencia

4º) Bajar los precios poco a poco

5º) Cerrar todos sus APIs y protocolos

6º) Amenazar con pleitos por patentes

7º) Cambiar a un modelo SaaS

8º) Crear un keiretsu (coalición de empresas unidas por intereses económicos, ej. Mitsubishi o LG)

Resumen global de la sesión

El Software Libre ofrece modelos de negocio que se ha demostrado que son viables, pero no es nada trivial ponerlos en práctica.

Las mismas reglas que han funcionado en otros mercados se pueden aplicar (con adaptaciones a los modelos de negocio de Sw Libre)

El Sw Libre tiene algunas ventajas intrínsecas, pero no son las que la mayoría de la gente piensa.