Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo obtener ganancias con el código abierto, sin caer en problemas

[19/07/2010] ¿Quiere obtener una pequeña fortuna con el software de código abierto? Es simple, dice el chiste, solo tiene que comenzar con una gran fortuna. La revolución del código abierto comenzó por lo menos hace dos décadas, pero las empresas y los programadores aún se encuentran luchando para entender la mejor forma de compartir maravillosos códigos y a la vez pagar la renta.

Han habido algunos notables éxitos: Sun pagó mil millones de dólares por MySQL, una gigantesca cifra dado que MySQL se encontraba rozando los 50 millones de dólares en ingresos muy poco tiempo antes. Red Hat tiene una capitalización de mercado de más de seis mil millones de dólares.
A pesar de todas estas cifras, queda la sensación de que estas empresas tuvieron éxito porque fueron híbridas. Usaron la visión del código abierto para atraer a los usuarios, pero el éxito de sus negocios llega debido a que fomentaron opciones propietarias. Entonces, el oscuro secreto es que sus versiones de código abierto son meramente una forma de márketing.
Decir que esto es publicidad engañosa podría ser muy fuerte, pero todos los usuarios pueden sentir que hay algo malo en la parte comercial. Muchas compañías, por ejemplo, encuentran que es más económico comprar una licencia comercial completa de MySQL que contratar un abogado para ver si se encuentran en cumplimiento con la licencia de código abierto. Hay una gran diferencia entre la versión libre de Red Hat, distribuida bajo el nombre de Fedora, y sus productos empresariales que se venden bajo el nombre de Red Hat. Como para aclarar cualquier duda acerca de que su software es realmente gratuito, tanto MySQL como Red Hat ofrecen periodos de prueba de 30 días, una frase que usualmente no se asocia con los ideales del código abierto. Recordemos la famosa entrevista de Larry Ellison, CEO de Oracle, con el Financial Times en donde dijo: si un producto de código abierto es lo suficientemente bueno, simplemente lo tomamos.
Otras compañías que intentan ser puras y comparten su código abiertamente descubren que los usuarios comparten de buena gana el software pero no se encuentran listos para pagar lo suficiente para mantener a los programadores.
Zack Urlocker, director y ejecutivo de varias compañías de código abierto, resalta el intercambio entre grado con el que se comparte algo y los ingresos: Apache tiene un buen modelo de licenciamiento que permite una amplia adopción del software de código abierto, pero hna habido pocas empresas significativas -ninguna de las cuales se aproxima siquiera a los 100 millones de dólares en ingresos- que se basen en un modelo de licenciamiento permisivo, como el de Apache.
El debate de negocios en la comunidad de código abierto
El debate sobre la permisividad se encuentra en todas las discusiones de los modelos de negocios de código abierto. Algunas compañías se mantienen pequeñas a propósito, mientras que otras argumentan que no hay nada de malo con la opción propietaria si ésta anima a todos los usuarios a compartir los costos del desarrollo. No hay almuerzo gratis, señalan.
Zak Greant, ex organizador de comunidades de MySQL y consultor de código abierto, señala que el modelo de código abierto funciona solo cuando existe un justo intercambio entre trabajo y software: el software gratuito y el código abierto existen en un mercado (o ecosistema) en donde cada uno de los participantes necesita dar y recibir valor. Para entender qué modelos de negocios funciona alrededor del código abierto, necesitamos entender qué espera ganar cada participante del mercado, que intercambio está realizando y cuál es el efecto sobre el mercado.
Aunque este enfoque parezca algo creado por un contador, Greant señala que las ganancias y los intercambios podrían no ser obvios. Puede que un usuario que realiza descargas de software sin pagar por ellas y que hace públicas sus quejas de manera abierta sea fastidioso, pero sus demandas son también una fuente gratuita de reportes de bugs. El desafío para las empresas es encontrar mecanismos viables para alinear los intereses de los usuarios y los de los programadores; toda una compleja tarea de ingeniería social.
A continuación presentamos, en orden decreciente de pureza, ocho modelos de negocios de código abierto que son exitosos. La mayoría no ofrecen un valor superior a los mil millones de dólares, pero representan una buena oportunidad de ofrecer software útil que resuelve problemas reales. ¿Acaso no es ese el verdadero objetivo del código abierto?
Modelo de negocios de código abierto 1: Trabajar con los amigos
Muchos proyectos de código abierto son solamente pasatiempos que unen a grupos de amigos. Todos son programadores o por lo menos hábiles con el software. La mayoría de las personas resuelven los problemas que tienen, así que se encuentran muy comprometidos y recompensados por su tiempo.
En pocas ocasiones los resultados se pulen lo suficiente como para que sean usados por alguien que no sea un programador, y la documentación o no existe o no se encuentra actualizada con la última versión. Pero este modelo económico aún es útil para los programadores: ellos pueden tomar el código e incorporarlo en su propio trabajo, produciendo nuevo software para sus clientes o jefes. Eben Moglen, abogada que ayudó a Richard Stallman a hacer el esbozo de la General Public License (GPL), afirma que los paquetes de software de código abierto proporcionan materia prima económica.
Todos son ciudadanos de primera clase con todos los privilegios de propiedad. Los participantes pueden obtener ganancias cuando pueden vender el servicio, no el código. No hay costos generales, no hay reglas contables, y ninguna batalla de propiedad intelectual porque todos comparten el título.
Modelo de negocios de código abierto 2: Trabajar con los colegas
Algunas de las más sofisticadas herramientas, relacionan a varios colegas de diferentes compañías en el mismo trabajo. Este modelo opera como los modelos que relacionan a los amigos, solo que en cambio lo hace con los colegas.
Por ejemplo, el servidor Apache Web, fue creado por un grupo de programadores que vendieron sitios web y decidieron construir algo que fuera fácil de configurar y extremadamente económico con los ciclos del reloj. El proyecto Apache ahora incluye millones de líneas de código construídas y utilizadas por programadores.
De la misma forma, Lucene se encuentra muchas veces en el back end de los servidores web en todo lugar. Las herramientas Commons son parte de muchos stacks de Java. Todas conforman las contribuciones de los programadores para que otros programadores se puedan beneficiar.
Modelo de negocios de código abierto 3: Vender documentación
Mientras que a muchos gerentes y profesores personalmente les gustaría patear al programador que cree código sin presentar los comentarios, algunas compañías de código abierto obtienen ingresos por la venta de libros y manuales que explican cómo funciona el código.
Este modelo podría quedar muy limitado a medida que la documentación sea reemplazada por las instrucciones digitales. Por ejemplo, el paquete iText, un conjunto de rutinas para manipular archivos PDF, solía ser distribuido bajo la Lesser GPL (LPGPL) y todos los mensajes de la lista de correo venían con un recordatorio (Compre el libro iText). Los libros aún se encuentran disponibles, pero la versión 5.0 del software fue lanzada bajo la Affero General Public License (AGPL): las personas que querían hacer el upgrade necesitaban liberar el código fuente para su total aplicación o comprar una licencia comercial.
Modelo de negocio de código abierto 4: Vender soporte
Hay variadas opiniones en cuanto a si todos pueden ganar mucho dinero por vender un conocimiento profundo del código, pero es el enfoque que la mayoría de los proveedores de código abierto comercial utilizaron a inicios del 2000.
Bob Bickel, asesor y director de varias compañías de software, señala que no hay buenos ejemplos de compañías de soporte que ofrezcan rentabilidad y crecimiento. Los nombres que primero se le vienen a la mente, como Red Hat y Swing, se basan fuertemente en mejoras propietarias como Red Hat Network y tcServer para convencer a los clientes a pagar por una versión mejorada, no es por el soporte.
El soporte es algo difícil de vender porque los costos parecen ser extremadamente altos: 200 dólares por una llamada suena excesivo hasta que uno se da cuenta que un ingeniero necesita visitar a dos o tres por día para cubrir los costos salariales y gastos generales.
Luego también existe el problema de la competencia. Las acciones de Red Hat se desplomaron en el 2008 luego de que Oracle comenzó a ofrecer soporte a mitad de precio. Las compañías puede que odien este tipo de competencia, pero a los clientes les encanta. Y al final del día, es mejor encontrarse en un campo competitivo en donde hay clientes que tener un candado sobre un costoso producto sin clientes.
Conociendo la pobre historia económica del código abierto financiado por el soporte, la nueva compañía de Monty Widenius, MariaDB, no va a manejar el soporte, sino que en cambio se concentrará en lo que él llama ingeniería de personalización. Esta es una forma de soporte con bastante escritura adicional de código mezclada; en otras palabras, contratos por grandes montos con empresas que quieren versiones especialmente adaptadas.
Pero otros señalan que el soporte es un negocio pequeño, sostenible y perfectamente viable. Nunca va a ofrecer un crecimiento explosivo, pero aún alcanza para pagar la renta. El soporte y los servicios profesionales pueden ser buenos negocios, sostiene Luke Kanies, CEO de Puppet Labs. Son negocios para los que es difícil encontrar financiamiento, lo cual significa que su construcción es más lenta y salir de ellos es más difícil.
El problema, señala, es que no pueden crecer sin contratar a más personas, y estas personas cuestan dinero. Pueden ser sostenibles, pero no tienen mucho retorno -si es que tienen alguno- para los inversionistas. En un mundo ideal, tendríamos miles de negocios pequeños y medianos de código abierto con uno saludables 10 a 50 millones de dólares en ingresos y consideraríamos eso como un gran éxito, sostiene Kanies. Es el mundo de los capitalistas de riesgo el que no considera que el soporte sea un modelo suficientemente bueno, pero eso es una cuestión de escala y potencial de salida, no de viabilidad.
Modelo de negocio de código abierto 5: Vender hardware
Los más grandes devotos del movimiento de software de código abierto han sido siempre las compañías de hardware. Ya sea que busquen negociar con Microsoft lanzando netbooks con Linux o construir los dispositivos para productos como el TiVo, a las compañías de hardware les encanta el software de código abierto porque reduce el costo de lanzar sus productos.
Linus Torvalds trabajó para una compañía de chips mientras florecía Linux, y muchos de sus compatriotas hicieron lo mismo. ¿Unix BSD? Muchos contribuyentes trabajaron para Sun o Apple. Y Hewlett-Packard e IBM no tuvieron problema en contratarlos.
La licencia de código abierto es perfecta para las compañías de hardware: ellas pueden tomar lo que quieran de la distribución común y mantener pleno control. No hay temor a quedarse atrapados o algún problema con que la compañía del SO central, como Microsoft o Apple, quiera mayores pagos, más control, más comoditización, o las tres cosas.
Debido a que piden poco más allá del reconocimiento de la autoría, algunas licencias, como BSD, son más fáciles de pasar. Otras, como GPL, pueden requerir que todo el nuevo código sea devuelto al grupo común, aunque hay generalmente formas de evadir esto. TiVo, por ejemplo, lanza algunos de sus cambios a la distribución Linux, pero la aplicación principal es eso: una aplicación. No se enlaza fuertemente con el código Linux, así que escapa a la GPL.
Las compañías de hardware no necesitan preocuparse por tener un convincente argumento de ventas para hacer que la gente contribuya cuando bajan una aplicación en forma gratuita. No hay necesidad de un tarro de propinas o de un contrato anual de soporte, porque las personas no tienen otra opción que soltar el dinero si es que quieren un dispositivo.
Modelo de negocios de código abierto 6: No vender software
La mejor solución de código abierto podría ser no ser un negocio de software, después de todo. Un ejecutivo de Google me dijo abiertamente: nosotros no distribuimos, así que la GPL no se aplica a nosotros. (Estaba hablando acerca de sus paquetes de código abierto, no de aquellos que Google aloja en Google Code).
Google podría desplegar sus cambios en la distribución general de los proyectos que usa -o podría no hacerlo-. No es venta de software, después de todo. Tiene un modelo de negocio totalmente distinto: Google y muchos otros sitios web no venden software per se; simplemente venden los resultados de usar el software de código abierto, de tal forma que todos los confusos temas sobre compartir su código fuente e incluso sobre la duplicación, desaparecen. Google no necesita preocuparse acerca de si alguien toma su trabajo y establece otro motor de búsquedas. Sin embargo, esto no significa que Google no contribuya de otras formas. Generalmente promueve a estudiantes que trabajan en software de código abierto bajo los auspicios de proyectos como el Summer of Code.
La cloud computing y el software as a service son tendencias de enfoques tecnológicos que funcionan fácilmente con todas las licencias excepto con las de código abierto. Esta flexibilidad molesta a algunos devotos que creen que las compañías que ofrecen sitios web deberían estar obligadas a distribuir su código fuente si usan código abierto, una actitud que llevó a la GNU Software Foundation a crear la Affero General Public License (AGPL). Sin embargo, a pesar de que hay varios proyectos como la plataforma de juegos Ryzom lanzados bajo la AGPL, serán necesarios muchos años antes de que alguien pueda tomar alguna decisión acerca de su éxito o fracaso.
Modelo de negocio de código abierto 7: Vender miedo, incertidumbre y duda
Las principales licencias de software de código abierto no diferencian entre usos comerciales y no comerciales, pero eso no ha impedido que algunas compañías de código abierto den a entender que las compañías comerciales deberían comprar alguna forma de licencia.
De hecho, muchos equipos de ventas de código abierto han aprendido sobre la belleza de personificar al policía bueno, y policía malo cuando hablan con los usuarios. El pago por la licencia puede que sea necesario o no, sugieren, sembrando las semillas de la confusión. Luego de un poco de debate sobre si es aplicable la GPL, ellos sugieren con toda cordialidad que comprar una licencia comercial liberará al usuario de cualquier preocupación legal y al mismo tiempo proporcionará soporte al producto.
Modelo de negocio de código abierto 8: Mutile su producto
La palabra mutilar suena negativa, así que nadie usa esa palabra. Es mejor mejorar la versión empresarial y dejar a un lado la versión comunal; es mutilar sin usar la desagradable palabra.
Por su puesto, este modelo se acerca bastante al enfoque de código abierto como táctica de márketing que es tan pesado para los creyentes del código abierto. James Phillips, uno de los fundadores de NorthScale, afirma: existen compañías que piden una relación de proveedor y pagan por software de código abierto. Retrasar el establecimiento de las características, en mi opinión, simplemente confunde al cliente.
Kanies de Puppet Labs refuta a estos puristas: Siempre tienes que tener algo que vender; nadie te va a pagar simplemente porque usa tu maravilloso software. Y añade: si creas un software simple y útil que simplemente queda fuera de su camino, ni siquiera te vas a dar cuenta que los usuarios existen. Así que sugiere que en lugar de quitar características de la versión gratuita, uno podría obtener los mismos incentivos al pago haciendo que la versión gratuita sea difícil de usar.
La riqueza se encuentra en el ojo del que la mira
Esencialmente, los ocho modelos de negocio de código abierto intentan equilibrar la cantidad de apertura con la necesidad de ingresos. En un lado se encuentran las empresas que permanecen pequeñas y muy abiertas, y en el otro lado se encuentran aquellas que usan el código abierto para vender un producto propietario.
A los usuarios les puede gustar la libertad del código abierto, pero casi siempre pagan por él a través de la responsabilidad de apoyar su desarrollo. En algunos casos, los paquetes propietarios son mejores ya que distribuyen en forma más eficiente el costo del desarrollo entre todos los usuarios; este enfoque generalmente es el mejor cuando la comunidad no incluye a muchos programadores que no pueden contribuir mucho con el mix. Sin embargo, el código propietario puede ser un verdadero dolor de cabeza para aquellos con la habilidad o la necesidad de cambiar o mejorar el software.
Al final del día, ¿alguien se hará rico en el negocio del código abierto? Todo depende de su la riqueza es medida en dólares o en líneas de código.
Peter Wayner, InfoWorld (US)