Oportunidades de Negocio en el Software Libre 30 Octubre
He asistido a muchas ponencias, congresos y seminarios que hablaban de cómo la pequeña y mediana empresa de este país podía aprovechar las ventajas del software Open Source. Sin embargo en todas ellas he echado en falta ejemplos concretos, normas de aplicación y recomendaciones para aquellas empresas que quieran subirse a ese barco.
Durante los últimos 2 meses he estado mirando qué podía ofrecer la iniciativa este tipo de software a la PYME española (y cómo las empresas desarrolladoras o implantadoras de software podrían aprovecharse de ello). Escribo el resultado de esas averiguaciones con el objetivo de que no se pierdan en el olvido cuando una nueva “ola” llame mi atención.
Clases de Software
Todos sabemos que el software de una empresa se estructura en capas, como las de una cebolla. La primera capa es el sistema operativo (Windows, Linux, Unix, etc.) Encima de esta capa podríamos encontrar el llamado “middleware” (software destinado a integrar aplicaciones entre sí), aunque este tipo de aplicaciones no se encuentran demasiado en la PYME española (no conozco ninguna con BizTalk).
Una vez superado el ámbito de los “sistemas base”, empezamos a encontrar aplicaciones más específicas de cada negocio: ERP’s, CRM’s, aplicaciones de gestión documental, etc. Estas aplicaciones son las que contienen la lógica de negocio de la empresa (las que implementan las reglas propias de cada empresa en su funcionamiento). Para una empresa, aquí está el verdadero valor añadido…y sin embargo no todas las empresas tienen esta capa.
La última capa, y que todas las empresas tienen, es la de la ofimática (alias Office). Se trata de aplicaciones de poco valor añadido en lo que respecta a la lógica de negocio, pero de gran flexiblidad e interoperatividad entre empresas (he visto cientos de empresas que utilizan Excel como sistema de facturación, contabilidad, etc, y que tienen todas sus facturas en Word). Desgraciadamente las empresas que no poseen la capa anterior se basan en esta para sus procesos de negocio (perdiendo valiosas ventajas en lo que respecta a la trazabilidad, control, etc. de la información)
Evidentemente, AQUI está la oportunidad de negocio para cualquier empresa de Software que se dirija a la PYME: ofrecer soluciones de valor añadido (es decir, con lógica de negocio incluida) a las empresas que ahora están supliendo esas necesidades con aplicaciones “neutras” (ofimática tradicional). Esta es la nuestra primera pista en la búsqueda de oportunidades de negocio dentro del Software Libre: buscamos aplicaciones verticales, o lo que es lo mismo, específicas de un negocio concreto.
Además de los motivos expuestos, hay que añadir que para una PYME un cambio en cualquier otro sentido es demasiado arriesgado. Muy pocas empresas cambiarían hoy por hoy sus sistemas Windows por Linux. Muchas menos abandonarían su MS-Office (no tanto por las ventajas que este tiene, sino por la compatibilidad con otras empresas que lo utilizan). En general, es más difícil desplazar algo existente y que cumple correctamente con sus objetivos (Windows, Office) que implantar nuevas soluciones para necesidades que no estaban bien cubiertas (ERP’s, CRM’s, Gestión Documental).
La búsqueda de una buena solución
Ahora que ya sabemos que tipo de aplicaciones pueden ser una oportunidad de negocio dentro del Software Libre, nos ponemos a buscar en Internet. Lo primeros resultados son desalentadores…tanto por la escasez de resultados como por la disparidad de “formas” que adopta el software en el mundo del Open Source.
Se impone una criba. Hay que tener en cuenta que en el Software libre no podemos suponer NADA. Hay que comprobarlo TODO.
¿Verdad que cuando uno compra un programa a una empresa (licencia), supone que habrá una buena documentación de soporte? ¿Verdad que es obvio que existirá un departamento de soporte en caso de dudas? ¿No es cierto que sería casi un delito que no hubiesen diseñadores y expertos en usabilidad en el diseño de la aplicación?
Sin embargo en software libre todo eso puede ser falso. Y nadie puede quejarse, porque es gratis (ahora es cuando los empresarios que leían esto empiezan a buscar el botón que cerrará la ventana). Sin embargo, y aunque no exista una obligación para ello, existe mucho software libre que cumple estas expectativas (a veces superando a sus competidores comerciales).
Para hacer esta criba podemos establecer 10 preguntas clave que hay que hacerse sobre cualquier aplicación que vayamos a adquirir o implementar en una empresa:
- ¿En qué fase se encuentra la aplicación? Las aplicaciones de Software Libre son muy estrictas con la nomenclatura de las versiones al contrario que en el mundo comercial, en el que uno pasa de Windows NT a Windows 2000, de ahí a Windows XP y finalmente a Lonhorn (¿Qué demonios significa eso?). Las aplicaciones tienen un ciclo de vida definido de la siguiente manera:
- Alpha: Se acaba de iniciar el desarrollo. Se trata de una varsión inestable en la que se trabaja de forma intensiva. Nada de lo que vemos es definitivo, y el equipo de desarrollo suele estar formado por programadores muy hábiles en busca de un reto intelectual (y poco dado a las explicaciones o a la documentación)
- Beta: Se trata de una versión más estable en cuanto a funcionalidades (lo que vemos es lo que probablemente será definitvo), aunque con contantes modificaciones y el mismo equipo de desarrollo que la versión alpha. En esta etapa es probable que ya existan los primeros usuarios y foros de consulta, aunque seguramente se trata de particulares que están probando la aplicación (pocas empresas se lanzan a una beta). en algunos casos el equipo de desarrollo mantiene la denominación “beta” durante años (aunque la aplicación esté siendo usada por millones de usuarios). Es la idea mal entendida de “la eterna mejora continua” o “esto podría ser un poquito mejor”, por lo que algunas versiones beta pueden ser utilizadas en ámbitos empresariales.
- Versiones 0.XX: Versiones 0.998 y cosas similares son el equivalente a una beta a efectos prácticos (una beta muy madura y estable en la mayoria de los casos)
- Versiones X.Y.Z: Por ejemplo 3.7.2, la variación de Z indica pequeños ajustes y parches; la Y significa nuevas funcionalidades menores y cada cambio en X significa una nueva versión completa, con nuevas funcionalidades de gran importancia. Cuando llegamos a este punto (por ejemplo, Mambo CMS con versión 4.5.3) estamos ante una aplicación madura.
- ¿Cual es la base de usuarios y desarrolladores? El hecho de que 10.000 personas utilicen una aplicación no significa que sea mejor que otra utilizada por 10. Lo mismo se aplica a la comunidad de desarrollo: 500 cabezas pueden no ser mejor que 50 superdotados. Sin embargo hay algo que tenemos que tener en cuenta más allá de la calidad del software y de sus desarrolladores: el soporte post-implantación, tanto para usuarios como para desarrolladores.
Cuando una aplicación tiene miles de usuarios y una gran comunidad de desarrollo, es normal encontrar foros, comunidades y blogs sobre la aplicación. Es más facil encontrar nuestro problema reflejado en el mensaje de otro, y su solución. No hay nada más deseperante que descubir “a solas” todos los errores del sistema (y tener que encontrar a solas su solución).
Por lo tanto, antes de decidirse por una herramienta, tenemos que hacernos esta pregunta: ¿Seremos capaces de manejar al 100% los problemas de esta aplicación? Si la respuesta es NO, hay que asegurarse de que habrá una comunidad a la que dirigir nuestras consultas. - ¿Cual es el modelo de crecimiento de la aplicación? Existen 2 modelos de crecimiento: centralizado y descentralizado. En el modelo centralizado, los desarrolladores de la solución son los únicos que pueden añadir nuevas funcionalidades. En el descentralizado existe la posibilidad de que cualquiera desarrolle “módulos”, “componentes”, “plugins”, etc. que se “enchufan” a la aplicación dotándola de nuevas funcionalidades. Este tipo de planteamiento es el más habitual en Software libre, y permite aprovechar el potencial de comunidades dispersas y desarrolladores particulares.
Este es el modelo a seguir, aunque no todas las aplicaciones lo hacen. La capacidad de una aplicación de ser modular llega en la madurez de la aplicación. Existen muchas aplicaciones que no contemplaron esa posibilidad en sus inicios y ahora estan condenadas a un crecimiento centralizado. A la larga eso significa DEPENDENCIA para la empresa, que tendrá que esperar a que un único equipo de desarrollo implemente la funcionalidad que desea.
Por último, las aplicaciones que crecen de esta forma se ven rápidamente superadas a lo largo del tiempo por otras alternativas modulares (por ejemplo Internet Explorer será superado por Firefox en un futuro no muy lejano) - ¿Cual es su plataforma tecnológica? Hay que elegir la mejor plataforma posible (aquí es cuando juntamos en una sala a los partidarios de LAMP, J2EE, ZOPE y .NET y les damos cuchillos desafilados). En serio, no se trata de comenzar la típica confrontación friki “PHP es mejor que ASP” ni “MySQL es de juguete”. Por si no se ha notado, el público objetivo de este artículo no son los programadores, sino las empresas, y para una empresa lo que importa no es si el lenguaje maneja bien las excepciones o si soporta stored procedures. Lo que importa en este caso es:
- ¿Voy a tener que pagar algo en licencias? La respuesta es sencilla: si utilizamos aplicaciones .NET esta corren sobre Windows y normalmente utilizan SQL Server. Si bien podemos conseguir un “motor” de SQL Server gratuito (con algunas condiciones), nadie nos salva de pagar a Microsoft por su sistema operativo. Además, si queremos hacer modificaciones sobre el código lo más normal sería hacerlo con Visual Studio, que también tiene su precio. Aqui estoy descartando alternativas tipo MONO (.NET sobre linux) porque me parecen aún poco maduras, y en la empresa, los experimentos con gaseosa. La alternativa gratuita es LAMP (Linux + Apache + MySql + PHP), sobre la que se desarrollan la mayoría de las aplicaciones Open Source.
- ¿Cuanto me va a costar encontrar a alguien que me modifique/mantenga el código? Encontrar un programador que domine Perl no es lo mismo que encontrar uno que sepa PHP (por lo menos en el mercado español). La dificultad para encontrar un programador es más o menos esta:
Python + ZOPE > Python > Perl > Java + JSP > Java > .NET > PHP = ASP
Es decir, que tendré que buscar mucho más para encontrar a alguien que domine Python bajo framework ZOPE que a un programados PHP o ASP. Y eso se traduce en euros y en dependencia de una persona. Por contra, quien sepa Python o Perl será seguramente un “crack”, mientras que hay mucho inútil manejando PHP.
- La escalabilidad de la plataforma. La tecnología que puede ser buena ahora puede ser poco estable cuando tenga 1 millon de registros (por ejemplo, Access como base de datos). Muchas empresas no se plantean esto, y sin embargo la migración de los datos que van a poner en esta nueva aplicación es algo realmente traumático, que habría que evitar a toda costa. La aplicación que elijamos debería tener como mínimo una vida de 3 a 5 años.
- Curva de aprendizaje La asignatura pendiente de las aplicaciones GNU es la usabilidad. En la mayoría de los casos son los programadores los que diseñan las interfaces de la aplicación, y por consiguiente estas siguen un modelo mental distinto al del usuario medio. Este es uno de los filtros más duros que deben pasar las aplicaciones GNU, y su importancia radica en el efecto negativo que tiene una aplicación difícil de usar y entender en el seno de una empresa (horas de formación, errores frecuentes, menor productividad, etc.)
- Documentación Por muy fácil que sea de utilizar una aplicación, cierta documentación NO es opcional. Cualquier aplicación que quiera tener un hueco en una empresa debe tener como mínimo la siguiente documentación asociada:
- Manual de Usuario
- Manual de Instalación y Requisitos Mínimos
Y de forma opcional pero muy recomendable
- Tutoriales
- Documentación sobre la arquitectura del sistema
- API documentada (si la tiene)
- Problemas más frecuentes
- Actualizaciones Hay aplicaciones que requieren actualizaciones periódicas (gestor de nóminas, contabilidad, antivirus, etc.) y otros que podrían permanecer inalterados a lo largo del tiempo y para los cuales las actualizaciones son simplemente correcciones o mejoras. Hay que tener en cuenta que muy pocas iniciativas Open Surce garantizan las actualizaciones necesarias, y que en cualquier caso no se pueden exigir responsabilidades.
Existen casos realmente ejemplares (Clamav Antivirus, con actualizaciones diarias), aunque la norma es que si uno quiere actualizaciones regulares y necesita garantías, debe haber una empresa detrás. Quizás sea por eso que no hay gestores de nóminas GNU (a pocos amantes de la programación les atrae la idea de leerse todos los días el BOE) - Seguridad Este es un aspecto muy controvertido. Existen 2 posturas al respecto:
- En contra: Puesto que el código de la aplicación está abierto al resto del mundo, cualquier hacker puede ver las “entrañas” del sistema y encontrar fallos que podría aprovechar en todas las aplicaciones instaladas y accesibles.
- A favor: Por el mismo motivo (código disponible), cualquier fallo puede ser resuelto en muy poco tiempo, ya que hay muchos ojos que lo estan controlando. Además, tener el código nos permite ver qué hace realmente el sistema, incluso auditarlo a nivel de seguridad.
Lo cierto es que a la hora de la verdad lo que os hackers aprovechan son las vulnerabilidades de las plataformas de base (Apache, Linux, PHP, IIS, Windows, etc.) y no las de las aplicaciones verticales que estas soportan. Por eso, cuando hablamos de seguridad en estas aplicaciones hablamos en realidad de seguridad DENTRO de la empresa (roles, perfiles, permisos, etc.) o lo que es lo mismo, la capacidad de la aplicación para determinar quién tendrá dentro de la empresa acceso a qué información.
- Enfoque empresarial El ciclo de vida de las aplicaciones GNU es muy previsible:
- Comienza con una iniciativa personal (normalmente una o varias personas muy capaces y con ganas de inovar)
- Cuando la aplicación madura atrae a otros desarrolladores que la hacen crecer
- La aplicación (si triunfa) se hace popular y comienzan a incorporarse otros perfiles al equipo: diseñadores, expertos en usabilidad, documentalistas, etc.
- La aplicación se convierte en una oportunidad de negocio. Comeinzan a aparecer empresas especializadas en su implantación
- Los fundadores de la iniciativa constituyen una empresa especializada en la implantación de esta aplicación
- Aparecen las primeras versiones comerciales de la aplicación (manteniendo una versión GNU sin soporte)
Evidentemente existen casos muy diferentes, aunque este es el ciclo más común. Evidentemente, nos interesa que la aplicación esté lo más avanzada posible en el ciclo. En la última etapa contamos con una red de implantadores y una empresa que da soporte al producto, sin renunciar por ello a las ventajas del Software Libre.
- Idioma No es nada trivial que sus sistemas de infromación estén en inglés. Lo mismo se aplica a la documentación y al soporte post-implementación. Hay muy buenos sistemas que sólo se utilizan en Alemania (con lo que ello supone). Muchas aplicaciones permiten que nosotros las traduzcamos fácilmente (y de paso colaboramos con el desarrollo)
Algunos ejemplos prácticos
Ahora que tenemos 10 puntos evaluables, estableceremos valores para cada uno de ellos y buscaremos oportunidades de negocio en www.sourceforge.net (la mayor base de datos de software Open Source)
Utilizaremos 3 estados (como los de un semáforo) para determinar la idoneidad de un parámetro (verde > amarillo > rojo)
- ¿En qué fase se encuentra la aplicación?
Estable > Beta > Aplha - ¿Cual es la base de usuarios y desarrolladores?
Amplia > En desarrollo > Escasa - ¿Cual es el modelo de crecimiento de la aplicación?
Descentralizado > Centralizado con API > Centralizado sin API - ¿Cual es su plataforma tecnológica?
Después de analizarlas, a efectos empresariales y en el mercado español podemos decir LAMP y .NET > J2EE > ZOPE - Curva de aprendizaje
Se puede usar sin leer el manual > Hay que estudiar un poco > Hay que descifrar su funcionamiento en el manual - Documentación
Toda la documentación > Documentación básica > Por debajo de la mínima o inexistente - Actualizaciones
Periódicas y regulares, con cierta responsabilidad > Periodicas sin responsabilidad > Esporádicas - Seguridad
Sistema de seguridad robusto (ACL’s, etc.) > Sistema básico (perfiles, roles, etc.) > Sin gestión de permisos - Enfoque empresarial
Marca comercial y red de partners > Red de especialistas > Sin enfoque empresarial - Idioma
Aplicación, documentación y soporte en castellano > Aplicación en castellano > Aplicación y documentación en inglés
Las aplicaciones seleccionadas para el estudio son:
- Hipergate CRM
- Compiere ERP
- OpenXpertya ERP
- KnowledgeTree (Gestión documental)
- Anjelica (Gestión de empresas cárnicas)
- Tina POS (TPV)
Todas ellas son candidatas a ser buenas oportunidades de negocio en diferentes ámbitos y tipologías de empresa. La matriz que resulta del análisis de los 10 parámetros es la siguiente:
Este análisis puede hacerse extensible a otras aplicaciones OpenSource para detectar oportunidades de negocio para PYMES españolas y mercados similares. Como nota adicional, cabe destacar que las aplicaciones tipo HiperGate pueden ser comercializadas en modalidad ASP, lo que las hace más atractivas desde el punto de vista del implementador que otras como Compiere.
Es fantástico dejar una idea abierta y abstracta, pero en la que es facil creer (las aplicaciones existentes son la evidencia de que la Web 2.0 existe) pero difícil acotar. Se está produciendo un esfuerzo masivo a nivel mundial que sería imposible coordinar de otro modo, y que tendrá por resultado una idea que ninguna persona o empresa podría haber desarrollado por su cuenta en años.