Curso sobre modelos de negocio basados en Software Libre. Tercera Parte: Modelos de negocio para proveedores de Software Libre.

1. Modelos de Negocio
para proveedores de
Software Libre
Sergio Montoro Ten

2. 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.

3. El objetivo nº1 de cualquier negocio
El objetivo de cualquier negocio
es crear clientes y mantenerlos.
Peter Drucker

4. 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.

5. 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).

6. 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-.

7. 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.

8. ¿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.

9. ¿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.

10. 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?

11. Beneficios para el cliente
de 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.

12. 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.

13. 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.

14. 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.

15. Modelos de valor de venta indirectos
1.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

16. Modelos de valor de venta indirectos 1
Posicionamiento 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.

17. Modelos de valor de venta indirectos 2
Asegurar el futuro
Este 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.

18. Modelos de valor de venta indirectos 3
Regalar 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.

19. Modelos de valor de venta indirectos 4
Integrar 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.

20. Modelos de valor de venta indirectos 5
Accesorizar
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.

21. Modelos de valor de venta indirectos 6
Liberar 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.

22. Modelos de valor de venta indirectos 7
Liberar 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.

23. Modelos de valor de venta indirectos 8
Liberar 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.

24. Modelos de valor de venta indirectos 9
Licencia 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.

25. 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.

26. 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.

27. Resumen de modelos de negocio
1.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.

28. 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.

29. 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 Hat
3. 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.

30. 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 corporativo
aunque algunos piensen lo contrario.
Resultado de los primeros 90 días:
Oracle Unbreakable Linux: 9.000 descargas
Red Hat Enterprise Linux: 1.000.000 de descargas

31. 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).

32. 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.

33. 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.

34. 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.

35. 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.

36. 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.

37. 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.

38. 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)

39. 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.

40. Tácticas anti-Open Source que emplean
tí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)

41. 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.