En el ámbito del software, los procesos de estandarización más relevantes están basados en el modelo de RFP (Request For Proposals), que implica la selección y adopción de especificaciones basadas en implementaciones ya existentes o en avanzado estado de desarrollo. Estos modelos han demostrado con el tiempo ser más eficaces que aquellos procesos basados en la existencia de comités de trabajo encargados de definir una especificación sin contar con una implementación de referencia. Podemos afirmar que hoy en día, la capacidad de cualquier empresa o entidad de influir en las especificación de cualquier estándar software está condicionada a que ésta pueda justificar que sus propuestas están soportadas en implementaciones de referencia.

A pesar de la bondad de los procesos abiertos de estandarización, la experiencia traslada que no todos los estándares acaban consolidándose. Por otro lado, la apuesta por estándares que no cuenten con un soporte suficientemente amplio por parte de la industria ha implicado un elevado riesgo hasta la fecha. Como ejemplo, basta considerar el elevado coste pagado por aquellas organizaciones que, durante el período 1993-1995, apostaron fuertemente por la adopción de OSF/DCE como middleware estándar sobre el que apoyar el desarrollo de sistemas distribuidos o por aquellas organizaciones que, durante el período 1994-1998, apostaron por la adopción de estándares como ODMG-93 (estándar sobre gestión de bases de datos orientadas a objeto) o como CMIP (estándar sobre gestión de elementos de red.) Este riesgo se acentúa teniendo en cuenta que los suministradores tradicionales de componentes software (ISVs – Independent Software Vendors) a menudo retiran su apoyo a cualquier estándar cuando no se encuentren sólidamente posicionados como suministradores frente a la competencia, creando, si es preciso, alianzas con otros suministradores en las mismas circunstancias para la creación de estándares alternativos. Este fenómeno de continuo enfrentamiento entre suministradores en áreas no suficientemente consolidadas de la plataforma, conocido como “batalla de estándares”, ha implicado que, hasta la fecha, ni la bondad técnica de un nuevo estándar ni el apoyo por parte de los usuarios haya sido garantía suficiente de su soporte por parte de la industria a lo largo del tiempo. Por contra, esperar a que un estándar esté definitivamente consolidado para asegurar así que su adopción no implica riesgo no parece la solución más adecuada, por cuanto implica renunciar a la posibilidad de aprovechar las ventajas diferenciales que puede conllevar una nueva tecnología frente a sus predecesoras.

En esta situación, el software de código abierto se está configurando como un instrumento eficaz en a la hora de acelerar la definición de cualquier estándar software. En efecto, la disponibilidad del código fuente de una implementación de las especificaciones de un estándar elimina la ambigüedad que puede existir en torno a la interpretación de dichas especificaciones, lo que agiliza el proceso de estandarización enormemente. El impacto en este punto ha sido reconocido explícitamente por entidades como el IDA Open Source Software Observatory de la Unión Europea:

“Open Source Software (OSS) tends to use and help define open standards and publicly available specifications. OSS products are, by their nature, publicly available specifications, and the availability of their source code promotes open, democratic debate around the specifications, making them both more robust and interoperable.”

Así mismo, la disponibilidad de implementaciones de referencia de código abierto se está revelando una herramienta eficaz a la hora de consolidar los estándares software. Por un lado, la participación en el desarrollo de proyectos de software de código abierto está abierta a cualquier agente, de forma que el testigo de quién haya participado en el desarrollo y decida abandonarlo puede ser cogido por otros miembros de la comunidad. Esto es posible ya que, esencialmente, el código fuente está disponible. En la medida en que la tecnología sea adecuada y atraiga un número suficiente de desarrolladores con talento o de empresas que vean oportunidades de negocio a su alrededor, existen grandes garantías de continuidad. En este punto, cabe señalar que la barrera de inversión inicial requerida para que cualquier empresa apueste por implicarse en la evolución de la implementación de referencia de código abierto de cualquier estándar es reducida (en realidad, la mínima posible) y tiene que ver con el esfuerzo necesario para conocer suficientemente el software ya desarrollado. Por otro lado, cuando la implementación de referencia de código abierto tiene asociada una licencia de tipo permisivo (como Apache) que permita la fabricación de productos cerrado, la aparición de un número suficiente de productos que implementen el estándar está mejor garantizada ya que la barrera de inversión inicial requerida para desarrollar un producto es mucho menor: la inversión empleada en el desarrollo de la parte del software reaprovechada en la construcción del producto (aquella sobre la que el fabricante no se plantea la capacidad de diferenciarse con un desarrollo propio) ha sido realizada por otros y su uso no exige contraprestación alguna.

MyMobileWeb es ejemplo de proyecto dentro de la comunidad Morfeo donde estamos experimentando las premisas que acabamos de mencionar. Dicho proyecto contempla como objetivo impulsar la definición de estándares que serán claves en la materialización del concepto de la Web en Movilidad. Así, en el marco del proyecto se están desarrollando implementaciones de referencia de código abierto de especificaciones de los estándares W3C cuyo desarrollo se pretende acelerar y consolidar. Los partners implicados en el desarrollo de las tecnologías en el proyecto MyMobileWeb (Telefónica I+D) consideran que el desarrollo y estandarización de tecnologías que estimulen la proliferación de sitios web accesibles en movilidad conllevará un importante beneficio por la vía de ingresos indirectos (mayor demanda en Telefónica móvil).

Creación de nuevas oportunidades en la integración de soluciones

La aparición de nuevos productos en segmentos donde ya estén presentes los grandes fabricantes de software actuales es complicada siguiendo el modelo tradicional de comercialización de productos software que se centra en la paquetización de los productos, su distribución a través de canales comerciales y la obtención de ingresos vía licencias de uso y cánones de mantenimiento. En dicho modelo, la inversión que es preciso realizar en actividades de marketing para dar a conocer el producto, en actividades de paquetización del producto o en el desarrollo de un canal de soporte y distribución similar al de los competidores, es demasiado elevada. La obtención de un ROI en plazos aceptables exige la definición de precios de licencia de uso elevados que pueden frenar el interés por arriesgarse a probar un nuevo producto.

El modelo de comercialización asociado al software de código abierto rompe las reglas del modelo de comercialización tradicional y abre oportunidades a cualquier nuevo entrante en la fabricación de productos software. Efectivamente:

• El nuevo entrante ‘libera’ su producto bajo licencia abierta, rompiendo barreras de entrada respecto a su uso en los segmentos de menor capacidad adquisitiva (individuos, PYMEs) gracias al precio (es gratis).
• No es preciso esfuerzo en marketing: si el producto tiene calidad, los propios usuarios difundirán sus bondades (efecto red). En este punto, hay que subrayar que los segmentos de poca capacidad adquisitiva que adopten en primer lugar el producto y difundan sus bondades pueden ser segmentos a los que en ningún caso el fabricante aspiraría a dirigirse (incluso adoptando un modelo tradicional de comercialización del software.) Por tanto, la estrategia no significa necesariamente la pérdida de clientes
• No es preciso esfuerzo en el desarrollo de canales de distribución: la red es el canal (el software se descarga de la red).
• Cuando el producto comience a convertirse en un referente, las grandes empresas comenzarán a estar interesadas en adoptar el producto pero exigirán que éste esté arropado por servicios (soporte, mantenimiento, consultoría) que alguien con las credenciales adecuadas ofrece. En la comercialización de este tipo de servicios directamente hacia el cliente o hacia terceros que mantengan la relación directa con el cliente es donde el fabricante localizará los ingresos que permiten en primera instancia cubrir el esfuerzo de fabricación y, más tarde, cosechar beneficios.
• Las licencias abiertas no excluyen que un producto también se distribuya bajo licencia comercial (pago por uso): para versiones más avanzadas o para eliminar ciertas restricciones en el uso.

Es preciso puntualizar que el nuevo entrante puede ser una compañía concreta o un conjunto de compañías que apuestan por compartir los esfuerzos de desarrollo y mantenimiento de un producto, centrando las oportunidades de negocio en los ingresos derivados de ofrecer servicios, aliados o en competencia, a clientes que forman parte de sus respectivas carteras.

La dimensión y proyección que el software de código abierto ha alcanzado es indiscutible. Sin embargo, hoy en día estamos aún hablando de productos software en cuyo desarrollo no han participado ni están participando compañías u organismos de nuestro país. Empresas fundamentalmente norteamericanas como RedHat, IBM o HP están captando mejor las oportunidades de negocio basadas en la comercialización de servicios alrededor de productos software de código abierto (servicios de soporte, consutoría, integración de soluciones) y esto ocurre no sólo en España sino en el resto de Europa, como han llegado a hacerse eco miembros de la propia Comisión Europea⁴. Estas empresas participan activamente en las comunidades de desarrollo asociadas a los productos software de código abierto sobre los que posteriormente desarrollan su oferta de servicios, capitalizando las ventajas competitivas que esa participación activa conlleva y que hemos desarrollado en puntos anteriores.

La ausencia de productos software de código abierto en relación con tecnologías software básicas cuyo proceso de estandarización está poco maduro aún (tecnologías asociadas a Web Services, tecnologías asociadas al concepto de Web Semántica, tecnologías BPM y de workflow, etc) o en relación con plataformas de soporte a procesos de negocio donde no existen productos alternativos a los comerciales (productos como Siebel en relación con soluciones CRM, SAP en relación con soluciones ERP, JD Ewards en relación con soluciones de Gestión de la Cadena de Suministro, MDSI en Gestión de Fuerzas de Trabajo, etc.) constituye una oportunidad que se puede aprovechar. Aprovechar esta oportunidad pasa por impulsar el desarrollo de una comunidad de software abierto que centre su actividad en áreas sin explotar como las mencionadas e implique la participación activa de empresas, universidades y centros de investigación nacionales. Dicha comunidad instrumentaría el desarrollo de una industria nacional de fabricación de tecnologías y productos software que hoy no existe. Las empresas implicadas activamente en la comunidad explotarían el tipo de ventajas competitivas que empresas como IBM o RedHat están explotando en relación con productos software de código abierto en cuyo desarrollo participan.

Las empresas implicadas en el desarrollo de implementaciones de referencia de estándares adoptando un modelo de software abierto cuentan con las credenciales necesarias para participar activamente en los procesos de estandarización relevantes y para desarrollar una oferta de servicios sobre dichas implementaciones (o productos software equivalentes) con máximas garantías para los clientes. Dichas credenciales representan un factor diferencial frente a empresas competidoras que no hayan participado en el desarrollo de implementaciones de referencia. Empresas como IBM están adoptando una estrategia en esta línea y están alcanzando un notable éxito en el creciente negocio de servicios alrededor de productos software de código abierto.

Es preciso subrayar que el desarrollo de oportunidades de negocio en torno a la oferta de servicios sobre las tecnologías desarrolladas bajo una fórmula de código abierto no se restringe a las empresas involucradas directamente en el desarrollo de dichas tecnologías. En este sentido, es posible experimentar una prometedora fórmula de relación win-win entre las empresas desarrolladoras de la tecnología y PYMEs que estarían implicadas en la comercialización pero no directamente en las actividades de desarrollo dentro de las comunidades. En este modelo de relación:

• La PYME actúa como canal de ventas, en coordinación con las empresas fabricantes de la tecnología, explotando oportunidades de comercializar servicios soporte y mantenimiento, consultoría, integración de soluciones o formación entre su cartera de clientes. En este punto, la PYME y las empresas fabricantes buscarán esquemas de reparto de los ingresos derivados de la comercialización de esos servicios
• A cambio la PYME logra enriquecer la cartera de servicios que pueden ofrecer basados en plataformas de software abierto avalada con alianzas establecidas con los fabricantes de la tecnología.

Nuevamente, algunos de los proyectos dentro de la comunidad Morfeo están sirviendo como banco de pruebas para experimentar la bondad de las anteriores premisas. Concretamente, caben destacar los proyectos relacionados con las plataformas MyMobileWeb, dirigida a facilitar la construcción de aplicaciones y portales web accesibles desde dispositivos móviles, y SMARTFlow, dirigida a facilitar la construcción de sistemas de gestión de expedientes/tareas. En ambos casos, un número creciente de PYMEs están sumándose a realizar actividades de comercialización de la tecnología desarrollada, en colaboración con las empresas que están detrás del desarrollo de la tecnología.

Impulso al desarrollo de actividades de I+D+i

La creación de una comunidad de software de código abierto que sirva de marco para la realización de proyectos de I+D+i ofrece importantes ventajas. En primer lugar, los proyectos que se llevan a cabo en la comunidad se ejecutan “en vivo y en directo” y, por tanto, representan un foro donde los miembros de la comunidad puede hacer visible fácilmente cuales son las áreas de investigación en las que tiene interés por colaborar con otros agentes tales como empresas del sector y Organismos Públicos de Investigación.

En segundo lugar, el planteamiento de proyectos dentro de una comunidad de software de código abierto favorece que grupos de investigación destacados en el ámbito universitario se impliquen más fácilmente en proyectos de I+D+i de interés para las empresas. Esto es así porque el modelo facilita la consecución de objetivos que sin duda resultan relevantes para cualquier grupo de investigación como son el reconocimiento de la propiedad intelectual sobre los trabajos realizados y la capacidad de difundir los resultados obtenidos. En relación con el primer aspecto, recordemos que en los desarrollos software realizados bajo la fórmula de código abierto habitualmente se contempla el reconocimiento de la propiedad intelectual sobre el trabajo realizado por cualquier contribuyente al proyecto, incluso en el caso en se contemplen al mismo tiempo fórmulas que permitan al fabricante original del producto explotar modelos de licenciamiento duales. En relación con el segundo aspecto, sin duda resulta atractivo para un grupo de investigación contar con una plataforma (web site de la comunidad donde se lleva a cabo el proyecto) donde difundir sus trabajos, acompañándolos de un sello de aplicabilidad por parte de empresas, sobre todo si se trata de empresas que cuentan con una posición de marca fuerte (como es el caso de Telefónica).

En tercer lugar, la adopción de un modelo desarrollo de software de código abierto representa una vía para acelerar la disponibilidad de productos finales derivados de proyectos de I+D+i realizados en colaboración por distintos agentes. Hasta la fecha, fundamentalmente se han seguido dos modelos diferentes a la hora de abordar proyectos de I+D+i en colaboración que contemplen el desarrollo de software que pueda servir de base para la fabricación de productos alrededor de los cuales realizar una oferta comercial:

• En algunos proyectos, directamente no se contempla el desarrollo de software final que las empresas implicadas en el proyecto puedan comercializar. Los desarrollos planteados en el proyecto tiene carácter de prueba de concepto o experimentación y se consideran lejos de lo que un producto final representa: el foco se centra en investigar los aspectos ligados a la definición de especificaciones, arquitectura, forma de integrar tecnologías, etc. Cada empresa podrá aprovechar los resultados del proyecto como base para la construcción de un producto pero lo hará a posteriori, de forma ajena al consorcio. Este modelo evita problemas de gestión de la propiedad intelectual y de los derechos de explotación, modificación o distribución del software desarrollado pero, por el contrario, supone un retardo en la disponibilidad de productos comercializables.
• En otros proyectos, sí se contempla el desarrollo de código fuente integrable en productos comercializables. Sin embargo, en dichos proyectos resulta trascendental establecer un marco contractual entre los miembros del consorcio que precise desde el primer momento como van a gestionarse aspectos tales como la propiedad intelectual, o los derechos de explotación, modificación y distribución. El mayor inconveniente en este caso reside en la dificultad de configurar este tipo de acuerdos, lo que puede implicar un retardo en el inicio del proyecto y, por tanto, en la aparición final de productos, cuando no un bloqueo definitivo que implique que el proyecto no se lleve a cabo.

El modelo de desarrollo de software de código abierto introduce una nueva alternativa a los modelos citados anteriormente. Los proyectos pueden contemplar el desarrollo de código fuente finalmente comercializable en el marco del proyecto partiendo de un marco claro y bien definido de gestión de la propiedad intelectual y de los derechos de explotación, modificación o distribución que no es preciso negociar porque ya existe: es el marcado por el tipo de licencia de código abierto adoptado, como puede ser GNU/GPL. La única condición que implica es que las empresas que participan en el proyecto tengan asumido que las oportunidades de negocio derivadas de explotar los resultados del proyecto no girarán en torno a la obtención de ingresos vía pago por uso de los productos desarrollados sino alrededor de otros aspectos (servicios complementarios, venta de hardware o equipos donde el software estará instalado, etc.) Como ventaja adicional, dicho modelo además facilita la incorporación gradual de nuevos participantes en el proyecto.

La comunidad de software libre Morfeo contempla como objetivo experimentar la bondad de estas premisas actuando como incubadora de proyectos de I+D+i y como campo de experimentación de un modelo de relación win-win entre las empresas y los grupos de investigación (ubicados universidades y centros tecnológicos). Varios son los proyectos que se han incubado con éxito en torno a esta comunidad refrendándose la validez de los planteamientos descritos en esta sección, pero se considera preciso seguir avanzando en esta vía.

Es importante destacar que la comunidad Morfeo ha sido identificada como uno de los nodos que formarán parte de la red paneuropea de centros de competencia en desarrollo de software abierto que se defina en el marco del proyecto IP del VI programa marco IST Qualipso. La comunidad de software abierto ObjectWeb, importante referencia en el ámbito de Servidores de Aplicación Java J2EE, también formará parte de esta misma red. Esta red paneuropea puede constituirse como la “fábrica virtual” donde se desarrollen implementaciones de referencia de tecnologías y productos que favorezcan la creación, la explotación y el acceso de los servicios electrónicos del futuro. En este punto, uno de los objetivos fundamentales planteados en Morfeo consiste en que un buen número de competencias dentro de la red paneuropea Qualipso se ubiquen dentro de la comunidad Morfeo.

Conclusiones

Optar por desarrollar software bajo un modelo de código abierto no significa estar en contra de desarrollar software bajo un modelo que implique el pago de licencias de uso. Ambos modelos son totalmente legítimos y válidos.

Desarrollar software bajo un modelo de código abierto simplemente implica explorar nuevas formas de hacer las cosas. Nuevas formas que pueden cristalizar en nuevas oportunidades que a algunas empresas o entidades les pueda resultar más sencillo capitalizar.

Morfeo es un proyecto de innovación donde empresas, universidades y otras entidades estamos explorando las nuevas oportunidades que puede implicar desarrollar software bajo un módelo de código abierto.

1 http://www.dwheeler.com/oss_fs_why.html
2 http://www.libroblanco.com/document/255-2004.pdf
3 “Predicts 2005: Open-Source Software Proliferates” Informe del Gartner Group
4 Discurso de Jesús Villasante, Holland Open Software Conference 2005. Breve nota resumen y enlace a artículo publicado por Computer Business Review OnLine disponibles en: http://istresults.cordis.lu/index.cfm/section/news/tpl/news/Briefs/briefs/ID/76994

Páginas: 1 2 3