El futuro del código abierto como negocio sostenible no parece estar tan relacionado con Linus Torvals como con Marty Roesch. En 1998, Roesch, entonces con 28 años de edad e ingeniero de la compañía de telecomunicaciones GTE-I, creó un programa de fuente abierta, denominado Snort, para la detección de intrusiones en redes de ordenadores. Hoy, reconoce que es multimillonario gracias a la venta en octubre de 2005 de Sourcefire, la compañía que creó para vender módulos software adicionales desarrollados para Snort por 225 millones de dólares al líder en seguridad Check Point.
El camino a la riqueza seguido por Roesch –utilizar Internet para
distribuir software de código abierto gratis y vender piezas
propietarias (de código cerrado) que mejoran la oferta gratuita- emerge
ahora como uno de los nuevos modelos de negocio más populares en la
industria de software, según los inversores de capital riesgo. Este
modelo, que podríamos llamar de “fuente mixta”, parece reunir lo mejor
de ambos mundos: los CIOs consiguen el software gratis, y las empresas
que desarrollan el código obtienen las direcciones de correo de los
usuarios que lo descargan, pudiendo así intentar venderles después sus
add-ons propietarios. Un modelo de especial interés para el
capital-riesgo, dado que, a fin de cuentas, su dinero se destinará a
software que puede ser vendido directamente, en lugar de a grandes
plantillas de ventas o costosas y no siempre efectivas campañas de
branding y marketing.Modelos de “fuente mixta”
Pero en la carrera para rentabilizar el modelo de código abierto, los intereses de las empresas que pretenden explotar esta nueva forma de negocio, generalmente start-ups, pueden colisionar con las comunidades que las engendraron. Cuando una compañía apoyada por los inversores construye tanto software abierto como propietario bajo un mismo paraguas, incita a la necesidad de un arreglo de cuentas entre la gente que ha contribuido con el componente gratuito (la comunidad de código abierto) y la compañía que busca obtener una ventaja competitiva del elemento propietario. “Es un conflicto de intereses inherente a este modelo”, asegura Jo Tango, de la compañía de capital-riesgo Highland Capital Partners. “¿De quién se aprueban los add-ons al software?, ¿cómo se da prioridad a esos add-ons?, ¿cómo determinar si cualquier nueva mejora o funcionalidad debe considerarse como un avance del producto de código abierto o como un módulo creado con vistas a conseguir beneficios?”.
Lo cierto es que la respuesta a estas preguntas dependerá de diversos factores, no siempre previsibles, y ello crea un espacio de juego indeterminado que puede llevar a situaciones en las que los CIOs se dejen seducir por la idea de utilizar lo que parece ser una tecnología gratuita para descubrir poco después que deberán pagar si desean hacerla funcionar de manera adecuada, indica Michael Goulde, analista senior de Forrester Research. Por su parte, Jo Tango añade que, en realidad, este modelo “lleva existiendo muchos años, dado que no es diferente del seguido por los fabricantes en las versiones de prueba de sus soluciones software comerciales”.
Y si dejamos de lado la condición de “abierto”, así es. Las empresas suministradoras de software propietario han estado lanzando versiones de prueba de su software desde hace años. Aunque en este caso el código es cerrado, y las versiones gratuitas ofrecen menos de lo que el cliente obtendrá si paga el precio por comprar el producto, “realmente no existe diferencia respecto de lo que las denominadas firmas de fuente abierta hacen con las versiones para la comunidad (código abierto) y empresariales (propietarias) de su software”, indica Barry Strasnick, CIO de CitiStreet, compañía dedicada a la gestión de beneficios.
En otras palabras, la parte gratuita se convierte en poco más que una solución de entrada, añade Adds Lee Hughes, CIO de Owens Forest Products, quien también se muestra inquieto ante la posibilidad de que las compañías con modelos mixtos acaben “mutilando” sus ofertas abiertas. “Me preocupa que si una compañía tiene una versión de código abierto gratuita y una versión comercial con funcionalidades mejoradas, la versión libre sufrirá las consecuencias convirtiéndose en una solución de menor gama dentro de la línea”.
En espacios cada vez más críticos
Strasnick y Hughes no se sentirían tan preocupados si el software de fuente abierta continuara siendo, como lo fue durante mucho tiempo en el pasado, un recurso para que sus desarrolladores experimentaran intentando ahorrar dinero en un pequeño número de servidores. Pero poco a poco se ha ido convirtiendo en parte esencial de la estrategia de adquisición de software de muchos CIOs, especialmente en el nivel de software de infraestructura. Tanto es así que la firma de investigación Gartner predice que en el año 2010 las organizaciones de la lista Global 2000 IT verán el código abierto como una opción viable para el 80% de sus inversiones en software de infraestructura. Así pues, los CIOs no puede permitirse ya considerar el código abierto como algo fácilmente desechable, ni dejar de soportar el código abierto convertido en componente vital de sus infraestructuras.
Sin embargo, para no verse metidos en un callejón de salida, conviene que recuerden que la compra de este tipo de software es un proceso muy diferente a la adquisición de software tradicional. La empresa a la que se estará comprando es una comunidad, las referencias que el responsable de compras deberá contrastar no dejarán de ser notas en boletines online, cuyos creadores pueden no ser ni siquiera desarrolladores de la compañía propietaria de la Web donde se publican.
Existen diferentes modelos de negocio emergiendo detrás de lo que aquí
hemos llamado “código mixto”, de manera que los CIOs tendrán que
informarse bien sobre esas empresas y comunidades hasta alcanzar un
grado razonable de certeza sobre si seguirán existiendo dentro de uno o
dos años. Se trata de una investigación de negocio crítica para los
CIOs. Tan importante en realidad como seguir la marcha del precio de
las acciones de Oracle o Microsoft, sus estrategias de adquisición y
sus anuncios de actualizaciones.Bajo las reglas del capital
Roesch se muestra inquieto cuando se le pide su opinión sobre el temor de los CIOs a que un producto de código abierto llegue a convertirse en una versión “lisiada” de la oferta comercial equivalente. Y tiene razones para sentirse aludido. Hace ocho años, él mismo desarrolló el núcleo de Snort. Desde entonces, estima que ha escrito 3.000 postings para la lista de discusión de Snort y ha ido construyendo una importante comunidad de usuarios –más de dos millones de descargas y 100.000 usuarios activos, según datos facilitados por el propio Roesch. A cambio, consiguió rápidamente lo que muchos desarrolladores de código abierto ansían: respeto y reconocimiento. Pero no dinero. “Nunca estuve motivado por intereses financieros”, subraya. “Simplemente, los beneficios han llegado por las decisiones que hemos debido tomar para que la comunidad continuara. Creo que la gente no desarrolla código abierto pensando hacer negocio. Más bien se persigue ganar reputación”.
Roesch podía haber aprovechado su reputación para conseguir un trabajo de alta remuneración en alguna compañía de software, pero le gustaba trabajar en Snort. Por eso, en 2001, inició un acercamiento a los inversores en busca de respaldo económico para sus planes de construir una empresa que soportara el producto. Sin embargo, no lo consiguió. “Quedó claro que sería imposible si no contábamos con algún contenido intelectual propietario relacionado con Snort”.
Una vez hubo desarrollado algunas herramientas de gestión propietarias y una GUI (Graphical User Interface) amigable para correr sobre Snort, Roesch consiguió el dinero para su proyecto. Y nunca miró hacia atrás, según explica, en parte, porque no tenía opción. Snort compite contra compañías bien conocidas y con grandes fondos, como Cisco, y “si se intenta entrar en un área del mercado de software altamente competitiva, como hicimos nosotros, es imprescindible contar con el apoyo del capital-riesgo”, asegura, añadiendo que, en cualquier caso, otros hubieran construido herramientas propietarias alrededor de Snort.
Bleeding Snort
Hasta el momento, según Roesch, nadie en la comunidad Snort ha esgrimido el éxito financiero como un argumento en su contra. “Me gusta escribir código”, explica Glenn Mansfield Keeni, desarrollador profesional que contribuye a enriquecer Snort en su tiempo libre. “Consigo una gran satisfacción personal contribuyendo a construir una Internet segura y el código permanece abierto, por lo que no existe abdicación del objetivo original. Si el elemento comercial permite a Snort sobrevivir, bienvenido sea”.
Pero otros miembros de la comunidad, más suspicaces, quisieron tomar medidas para garantizar que Snort permaneciera abierto. Así, en 2003, se constituyó un grupo denominado Bleeding Snort cuya misión sería proporcionar reglas y definiciones de detección de intrusiones de código abierto para el producto; algo similar a los ficheros de definición de virus que pueden descargarse de los programas antivirus. Fue un movimiento premonitorio. Sourcefire ya ha empezado a hacer diferencias entre usuarios de pago y libres: pone sus actualizaciones primero a disposición de los primeros; el resto deben esperar cinco días. Y, a diferencia de las actualizaciones de Bleeding Snort, las de Sourcefire ya no se suministran bajo una licencia de código abierto: las empresas que han construido software propietario sobre Snort -Sourcefire no es la única- han de pagar ahora una tarifa a Sourcefire para obtenerlas.
Bleeding Snort mantiene en cierta medida el equilibrio en el juego, porque mantiene el derecho a desarrollar nuevas reglas, lo que ha menudo hace, según Alan Shimel, responsable de estrategia de StillSecure, empresa de software de seguridad que utiliza el motor Snort como parte de su software propietario. Shimel asegura que “muchos miembros de la comunidad Snort no celebraron precisamente que Roesch creara y , después, vendiera Sourcefire. He conversado con personas de Check Point que aseguran su deseo de mantener Snort abierto; pero, como ellos mismos reconocen, el camino hacia el infierno está plagado de buenas intenciones”. Como postura oficial al respecto, en su Web, Check Point manifiesta estar “comprometida con la comunidad de código abierto Snort”, y perseguir “la ampliación de la solución Snort y de la comunidad Snort en el futuro”.
Pero lo cierto es que la historia enseña que el peligro existe. No todo el software de seguridad de código abierto ha permanecido como tal. Por ejemplo, el paquete de software Nessus que venía comercializándose desde 1998 bajo licencia open-source, en su versión más reciente (3.0) se ha cerrado y ha empezado a suministrarse bajo licencia comercial (las versiones anteriores permanecen disponibles en código abierto), aunque siga siendo gratis, en cuanto a coste, para los usuarios.
El desarrollador original de Nessus, Renaud Deraison, quien, como Roesch, ha fundado una compañía (Tenable Network Security), indica que fueron sus clientes comerciales quienes le presionaron para que cerrara el código fuente. “Sobre muchos de ellos pesaba la prohibición de utilizar software open-source; otros tenían que superar muchos inconvenientes legales para obtener el permiso necesario para utilizarlo. Lo que ellos desean es calidad, software libre. La licencia es menos importante”. Aunque el cambio en la naturaleza de Nessus ha sido objeto de las críticas de muchos de los defensores del código abierto -pueden seguirse en discusiones dentro de sitios Web como Slashdot.org, el nivel de uso de Nessus parece no haberse visto afectado; al menos, todavía.
Por lo que se refiere a los CIOs –casi siempre escépticos respecto de
las promesas de los suministradores- también se muestran preocupados
por la compra de Snort por Check Point. “Sin lugar a dudas, es algo que
me preocupa”, asegura Kirk Drake, vicepresidente de tecnología en
National Institutes of Health (NIH) Federal Credit Union, organización
que utiliza Snort y los módulos de Sourcefire. “Pero no es muy
diferente de lo que ya hemos visto en otras ocasiones. Compramos un
buen producto, y al cabo de un tiempo la compañía que nos lo suministró
es adquirida. En tal caso, el producto puede cambiar. Y el precio
varía”.De acuerdo con Roesch, aquellos que ven el software de fuente mixta como una alternativa que les llevará inevitablemente de vuelta al software propietario no han entendido realmente el poder de la comunidad open-source. “Check Point consiguió una de las bases de código más probadas y desplegadas del mundo, y si consigue manejar ese potencial adecuadamente también habrá conseguido a la comunidad. Creo que la buena disposición generada por Snort entre usuarios y desarrolladores probablemente supera el valor del software propietario, y también creo que Check Point opina lo mismo”. En otras palabras, continuar con el soporte de un Snort abierto tendrá para Check Point un coste menor que enajenar a la comunidad cerrando el código fuente.
Libre vs. gratis
Como se ha dicho, nadie en la comunidad open-source critica a Roesch o a Check Point por hacer dinero con el software de código abierto. Después de todo, Richard Stallman, el padre del movimiento del software libre (ahora ampliamente conocido como “de código abierto”), fundador de GNU Project y de su principal organización patrocinadora, Free Software Foundation, ha dejado claro que para entender la filosofía del movimiento en “free software” debe interpretarse “free” (termino inglés con la doble acepción de “gratis” y “libre”) con el significado en que tiene en “free speech” (discurso libre) y no en “free beer” (cerveza gratis). Aunque también es cierto que, a menudo, este tipo de software se ofrece a los usuarios de manera gratuita y, de hecho, quizá así deba hacerse para cumplir los objetivos de sus creadores.
De acuerdo con la definición que de “software libre” hace Free Software Foundation (www.fsf.org), de nuevo, la palabra “libre” en esta expresión hace referencia a la libertad de los usuarios para correr, copiar, distribuir, estudiar, cambiar y mejorar el software. No es una cuestión de coste económico, sino de libertad de uso, por lo que no es por sí mismo censurable que alguien pueda hacer dinero con él si con ello no viola la naturaleza abierta de su código fuente.
Sin embargo, la comunidad open-source, pese a estar lejos de huir de posturas monolíticas, estará de acuerdo en una cosa: a ninguno de sus miembros le gustará que empresa alguna intente utilizar el código abierto como una estrategia tipo Caballo de Troja para introducir después entre losusuarios software propietario cuyo uso esté basado en el pago de una cuota.
En algún momento del futuro próximo, algunas compañías sin el suficiente entendimiento de los ideales de la comunicad open-source intentarán probar los límites del modelo de fuente mixta, como advierte Geoffrey Moore, director de la consultora TCG Advisors. “No obstante, creo que la comunidad de código abierto está en condiciones de responder con un contragolpe a aquellas empresas que no respetan sus aspiraciones y su ética”.
El ambiente generado por una tal sublevación de la comunidad
open-source contra los intereses comerciales podría, en cualquier caso,
tener consecuencias negativas sobre la infraestructura de los CIOs. Por
ejemplo, los proyectos de código abierto podrían terminar abandonados
por sus comunidades, sin que quedara nadie para soportarlos. También
podría producirse una bifurcación en la que la base de código
open-source fuera utilizada para iniciar un nuevo proyecto incompatible
con la versión original, o el hacking malicioso de una base de código
abierto.Como las comunidades, más que los modelos “de fuente mixta”, generalmente CIOs prefieren el modelo de negocio de código abierto que Roesch no pudo vender a ningún potencial inversor: un modelo de servicios en el que la compañía vende soporte para una única base de código abierto. “En este tipo de negocio basado en servicios, todo mi dinero iría destinado a soporte e implementación”, argumenta Strasnick. Unas pocas y bien conocidas empresas de código abierto, como Red Hat (Linux), JBoss (middleware) y MySQL (base de datos), han conseguido sustentarse sobre este modelo. Pero, debido a que la base del código software está abierta a cualquiera, las barreras de entrada para los competidores son muy bajas.
Diversas barreras para los modelos más puros
Llegados a este punto, nadie pondrá en duda que las empresas que desarrollan su actividad alrededor del open-source deberán ser extremadamente astutas para competir contra las compañías de software propietario. “Los CIOs esperan pagar menos por el código abierto”, explica Goulde, de Forrester. “En concreto, éstos esperan obtener con ello ahorros de entre el 30% y el 50%”; una “esperanza” que se proyecta también inevitablemente sobre los servicios a él asociados. Podría parecer algo lógico cuando el software es gratis, pero no debemos olvidar que no resulta gratis para las compañías que lo soportan; muchas deben tienen que dedicar sus propios empleados a gestionar y codificar los productos de fuente abierta. Llevó muchos años el desarrollo de la comunidad desinteresada que apareció alrededor de Linux y se trata más de una excepción que de la regla.
Además, los inversores no ven con buenos ojos los modelos basados exclusivamente en servicios porque sus márgenes son siempre menores que los del software propietario. “De alguna manera, la empresa en la que invierta deberá contar con una ventaja competitiva sostenible”, indica Moore. Algo que explica por qué las compañías de fuente abierta han experimentado un crecimiento más lento que el de sus equivalentes en el mundo del software propietario. Sin embargo, es el modelo preferido por los potenciales clientes y por las comunidades de desarrolladores.
Otro factor limitador añadido para el desarrollo del mercado open-source es que resulta prácticamente imposible construir un negocio alrededor del código abierto en segmentos de nicho e industrias verticales. Sólo un pequeño porcentaje de los usuarios que realizan las descargas pagarán por obtener soporte de sus suministradores (por ejemplo, Snort tiene 100.000 usuarios regulares, pero sólo 800 han contratado servicios de soporte), y las comunidades de usuarios y desarrolladores no crecen a menos que el software sea utilizado por elevado número de personas. Por eso, las soluciones de código abierto que han conseguido hacerse un hueco importante entre los usuarios comparten siempre dos características importantes: son ampliamente aplicables a través de muchos tipos de empresas e industrias, y tienden a ser desplegados en áreas que las compañías no consideran generadoras de una ventaja competitiva (como la infraestructura). El motivo de esto último es que cualquiera –incluidos sus competidores- tendrá acceso al código fuente del software.
Grandes suministradores y fuente mixta
Y lo cierto es que, incluso si el software de código abierto sale airoso en todos estos frentes, construir un negocio a su alrededor será difícil a menos que sea complejo y llegue a convertirse en elemento crítico para mantener el negocio en funcionamiento. Es en estos casos cuando los CIOs, especialmente los de empresas de pequeño o mediano tamaño con recursos humanos de TI limitados, no podrán prescindir de soporte comercial. De hecho, el soporte es consistentemente la mayor preocupación de los CIOs de acuerdo los sondeos realizados por Forrester Research, según Goulde. “Necesitamos un suministrador que asuma una parte del riesgo cuando nos comprometemos con cualquier paquete de software”, reconoce Drake, de NIH Federal Credit Union.
Pero los CIOs, cuando de soporte se trata, siempre prefieren ir de la
mano de un suministrador grande y bien establecido que depender de una
pequeña start-up. Esa es la razón por la que MySQL, por ejemplo, ha
establecido acuerdos de servicios con Hewlett-Packard y Dell para su
base de datos de código abierto. MySQL se lleva una parte de lo
recaudado, y los CIOs se sienten tranquilos al saber que un gran
suministrador está detrás del producto, como explica el propio CEO de
MySQL, Marten Mickos.Cabe prever que la inquietud que en los CIOs despiertan los pequeños suministradores unida a las reticencias de la comunidad de capital-riesgo a apoyar los modelos más puros de negocio open-source provocará el crecimiento del mercado de código mixto en los próximos años. Conviene estar al tanto de la evolución de este nuevo tipo de modelos.
Pero, en cualquier caso, Roesch piensa que la comunicad Snort sobrevivirá. “Check Point necesitaba educarse en los motivos por los que es importante mantener la solución abierta, y lo está haciendo”, indica Roesch. Parte de esa educación pasa por entender que el modelo de desarrollo open-source crea relaciones entre los propietarios del proyecto y los usuarios que no pueden darse en el mundo del software comercial tradicional. “Por ejemplo, muchos de los que compran software Sourcefire son personas que comenzaron a utilizar Snort durante su formación y ahora lo han introducido en las empresas donde trabajan”, explica.
Pero este tipo de relaciones, basadas en la confianza y fraguadas durante muchos años, son extremadamente frágiles. Si Check Point cerrara Snort, “perdería la confianza de la comunidad en una noche. Conseguir esa confianza lleva años; perderla, minutos”.