En javalobby he escrito un artículo reflexionando sobre el futuro del software de código abierto (que ha motivado una réplica). La motivación de este artículo es la reciente compra de Sun por parte de Oracle, dicha compra ha preocupado a mucha gente acerca del futuro de los productos de código abierto de Sun, uno de los más importantes conjuntos de software de código abierto del mundo (o sencillamente el más importante).
Esta compra ha promovido muchas especulaciones acerca del futuro y la viabilidad del modelo de desarrollo de código abierto en general, por una parte porque algunos plantean que esta compra es la constatación del fracaso de la apuesta por un modelo de negocio basado en código abierto constatando que el comprador, Oracle, a pesar de que es un importante contribuidor al ecosistema del código abierto (por ejemplo con ADF Faces), el núcleo de su software, fundamentalmente la base de datos Oracle y los productos de Bea son productos de código cerrado y de pago, incluso las versiones de “entrada” como es el caso de Oracle Express. Otro nubarrón llega en la forma del cloud computing, una tendencia en donde se apuesta por el desarrollo del software como servicio (Software as a Service or SaaS), un modelo que no suele ser amigo del código abierto pues ni siquiera existe distribución del código fuente.
En un artículo previo de JavaLobby, Rod Johnson, CEO de SpringSource, la empresa que posee el ecosistema basado en Spring, plantea que Oracle, a pesar de la compra de Sun, no va a dirigir la innovación del mundo empresarial en Java, debido a que la mayor parte de esta innovación tiene lugar desde hace tiempo fuera de Sun y dirigida por la comunidad de programadores de proyectos de código abierto.
Yo no se si Oracle va a mantener el buen trabajo que ha estado haciendo Sun en el ámbito del código abierto, quizás el camino a seguir sea una estrategia en donde se mezcle software gratuito y de código abierto con software cerrado y de pago, en donde los primeros sirven como una puerta para los segundos. Actualmente Oracle tiene muchas opciones para hacer esto tal y como las parejas: MySQL-OracleDB, GlassFish-WebLogic, Sun JVM-JRockit, NetBeans-JDeveloper etc.
En un comentario al artículo de Rod Johnson, Jacob Jenkov hace públicas sus preocupaciones acerca del futuro del código abierto como modelo de negocio; él plantea dos problemas del código abierto desde esa perspectiva:
1) Hacer negocio desarrollando código abierto es difícil y no debería porque normalmente el producto añade valor que merece una compensación.
2) Como la mayoría de los proyectos de código abierto son totalmente gratuitos, las barreras para publicar cualquier cosa son muy bajas y no hay garantías de futuro. Esto da a lugar a montones de opciones para hacer lo mismo en donde es difícil de elegir la herramienta adecuada a tus necesidades con la incertidumbre añadida de si seguirá existiendo (continuada) el año siguiente.
Ante todo, nadie puede decir que las reflexiones de Jacob vayan en contra del código abierto pues él mismo es el autor de un producto de código abierto, el Butterfly DI Container, por tanto él ha aportado mucho más a este ámbito que el programador medio. Lo mismo se aplica a éste ártículo y su autor (es decir yo).
¿Es el desarrollo de software código abierto un modelo de negocio viable?
Desde luego SpringSource está en ese camino, por citar la empresa de Rod Jonson, Sun también intentó ese camino también. Es algo injusto decir que Sun falló en hacer dinero del código abierto porque no le dio mucho tiempo a producir un mundo de servicios en torno a productos más o menos nuevos o recientemente adquiridos tal y como MySQL y GlassFish. Quizás sin esta terrible crisis Sun sería rentable de nuevo como lo fue hace muy poco, antes de las compras de StorageTek y MySQL que supusieron obviamente pérdidas en la cuenta de resultados.
En mi opinión el futuro del código abierto como modelo de negocio es el licenciamiento dual, una mezcla de licencia no liberal y licencia comercial. El licenciamiento dual no excluye otros modelos de negocio “periféricos” tal y como la consultoría, la formación, el soporte o la venta de libros, pero el licenciamiento dual es un retorno al producto como el foco, un retorno a un modelo de negocio basado en licencias con precios asequibles y con todas las bondades del código abierto.
El objetivo del licenciamiento dual es alinear los ingresos de los usuarios con el licenciamiento comercial. Una analogía es el modelo de negocio de PayPal, PayPal es gratuito para los vendedores, no hay cuota de mantenimiento, pero cuando se obtiene un ingreso a través de PayPal, PayPal cobra una pequeña comisión. Este modelo funciona, “escala” (más ingresos implica más comisiones) y beneficia a ambos lados.
El producto de código abierto no debería ser una simple excusa para otro tipo de negocios. No hay ningún problema ético por mi parte para estas “excusas” (consultoría, formación etc), si funcionan ¡perfecto! El problema es que estos modelos tienen dificultades para “escalar” debido a que prácticamente cualquiera puede conseguir ser un experto de un producto concreto de código abierto sin recurrir a soporte, formación etc.
La solución no debería ser un retorno a software de código cerrado, de hecho el dar gratuitamente una versión de código abierto muy limitada es realmente un retorno al modelo de código cerrado, pues el programa “de verdad” no es de código abierto.
De hecho el modelo de negocio basado en código cerrado y con pago antes del uso tampoco es ya una alternativa convincente. Normalmente el código cerrado implica registros normalmente con datos falsos, un tiempo de evaluación, chequeo de fecha expiración, cambios en los registros del disco duro etc para proteger la inversión. En este contexto el usuario final es considerado a priori como un potencial delincuente.
Este modelo podría ser seductor de nuevo para una nueva empresa pensando en como distribuir su software y a la vez proteger su inversión, pero en la era Internet, es como tratar de dividir el mar con un muro. Cualquier puede abrir el eMule y buscar "WebSphere" y encontrará cientos de fuentes, es decir, es posible usar WebSphere también de forma totalmente gratuita. Si uno quiere ser un “mal chico” el código abierto y el cerrado y los tipos de licencias no son un problema. De hecho hay quienes prefieren obtener una copia de un programa de lugares piratas con un fin de evaluación o de aprendizaje evitando el lío de registrarse con datos falsos y los cambios a veces problemáticos en el registro del sistema operativo para obtener una versión de evaluación.
El modelo de software como servicio en la nube es incluso más cerrado.
En mi opinion el problema no es el excesivo número de opciones un tipo de tecnología, porque normalmente muchas opciones son muy parecidas (por ejemplo en desarrollo web). El problema es el número de “opciones soportadas”, opciones con un compromiso de futuro. El mundo del desarrollo de software se beneficiaría del licenciamiento dual mejorando la calidad al existir un compromiso detrás y asegurando un futuro a medio o largo plazo si el producto es satisfactorio.
Como anécdota me gustaría citar un ejemplo, JACE, JACE fue un producto muy popular para programar en Java pero en C++ evitando JNI. JACE ha sido muy útil a muchos programadores cuando Java era demasiado pobre y el código nativo era necesario. Hoy día prácticamente nadie necesita este tipo de producto, de hecho la última versión de JACE tiene fecha de 2003 y basada en Java 1.3 y la web está caída. ¿Qué pasa si necesito este tipo de software? SourceForge indica que todos los días hay descargas de JACE. Hay dos opciones, intentar usar JACE que quizás no funcione en JVMs actuales (los tipos genéricos pueden ser un problema) o existe la opción de comprar JunC++ion que la alternativa de pago de código cerrado.
¿Por qué pongo este ejemplo? Porque yo mismo tengo una alternativa a JACE y JunC++ion que uso internamente en JNIEasy para chequear la licencia desde C++ usando las APIs de Java. Es similar a JACE y JunC++ion pero tiene alguna ventaja tal y como el uso del “new” en C++ de forma simétrica a Java que hace que el código sea más natural para un programador Java y quizás alguna ventaja más. Podría publicar esta herramienta interna como código abierto, pero cuando pienso en el tiempo que necesitaría para publicar algo decente (pulir cosas, añadir algunas más características, hacer javadocs, tutoriales, pensar nuevas versiones, mantenimiento, resolver dudas etc) de forma totalmente gratuita… cambio rápidamente de idea. Lo pongo como un ejemplo de que a veces el camino del código abierto totalmente gratuito paradójicamente puede dificultar la innovación. Esta es una razón por la que el licenciamiento dual puede beneficiar al mundo del código abierto.
¿Qué pensais?
¿Cuál es el futuro del Sofware Libre y/o Código Abierto?
¿Es el código abierto un modelo de negocio viable?
¿Es el licenciamiento dual un modelo de negocio viable?
¿Cómo afectará el cloud computing a los modelos de negocio basados en software?
sábado, abril 25, 2009 at 4:16AM