El documento discute los cambios en el modelo de relaciones entre usuarios y proveedores bajo el nuevo modelo de software libre. Señala que el software libre se ha consolidado como una opción válida para las organizaciones y que trae beneficios como la gratuidad y menores costos. Sin embargo, también trae mayores responsabilidades para los usuarios en términos de gestionar el software como un activo y asegurar su mantenibilidad a largo plazo.
1. SOFTWARE LIBRE Y RELACIONES
USUARIO-PROVEEDOR:
CAMBIOS DE PARADIGMA BAJO EL NUEVO
MODELO
Ricardo Eito-Brun
Universidad Carlos III de Madrid
29 de marzo 2012
2. Código abierto
• El código abierto / libre, se ha consolidado opción válida en la
estrategia de TI/SW de las organizaciones.
• Principal característica:
• Disponer del código fuente de las aplicaciones para poder evolucionarlo
“libremente”, con independencia de las actividades planificadas por el
creador de dicho SW.
• Principal beneficio percibido (aparentemente):
• Gratuidad, o al menos…
• Menores costes (debido al hecho de obtener el SW sin tener que pagar
licencias)
• Áreas de éxito:
• Sistemas operativos (Linux)
• Bases de datos: MySql
• SGC: Drupal, Plone…
• Ofimática y escritorio.
4. Código abierto. Algunos datos
• INE, Encuesta de uso de las TIC y Comercio Electrónico en las
empresas (ETICCE) . 1
• Muestra: 28.980 empresas (16.715 de 10 ó más asalariados y 12.265
de menos de 10).
• En las grandes empresas: uso de los sistemas operativos libres (47, 2%),
los servidores web (47%) y las aplicaciones de tipo ERP o CRM (34%).
• Las aplicaciones ofimáticas de código abierto son las soluciones libres
más utilizadas (53,9% de las pequeñas empresas y 51,5% de las
medianas).
• 9 de cada 10 empresas TIC apuestan por el uso del software de código
abierto en sus infraestructuras TI.
• El porcentaje de empresas que utilizan sistemas operativos libres ha
aumentado del 9,5% en enero de 2010 al 26,40% en enero de 2011.
Fuente: CENATIC “Software Libre en Cifras: Empresas Usuarias. 2011”
5. Código abierto. Algunos datos
• AGE:
• 68% de organismos ha obtenido SW OS de manera gratuita desde
repositorios de software o “forjas”;
• 46% ha realizado desarrollos propios basados en OS soluciones de
fuentes abiertas
• 33% ha licitado la adquisición de software de código abierto comercial;
• 27% afirma haber reutilizado las soluciones de fuentes abiertas de otra
Administración Pública.
• Volumen de software desplegado en los servidores de AGE 40% es
software libre. Software de escritorio, 15%.
• 2 de cada 10 organismos valoran positivamente las ofertas que
contemplan soluciones libres (aunque no las exijan).
Fuente: CENATIC “Encuesta sobre el Software de Fuentes Abiertas en la Administración General del
Estado (ESFA-AGE). 2011”
7. Código abierto.
Connotaciones tradicionales
• Percepciones asociadas al “movimiento libre”:
• Software social:
• SW desarrollado por la comunidad, para la comunidad.
• Altruismo, afán por colaborar.
• Existencia de redes dispuestas a colaborar y a solucionar problemas de
otros…
• Más calidad:
• SW de mayor calidad.
• SW libre de virus.
• “Demonización” de modelos de negocio tradicionales.
• Si estos no me cobran…, los otros me estaban “engañando”.
• Connotaciones “positivas” de la palabra libertad.
8. Código abierto.
Connotaciones tradicionales
• Realidades asociadas al “movimiento libre”:
• Estrategias de márketing:
• Empresas que invierten en comunidades libres para atacar a
competidores directos.
• Empresas que adoptan el modelo para:
• Poder generar actividad a partir de SW inicialmente “cerrado” que no
obtenía resultados positivos comerciales.
• Obtener beneficios de la venta de servicios / redes de socios.
• Dar mayor visibilidad a SW.
• Licencias gratuitas para entidades “no lucrativas” y pago para entidades
lucrativas.
• Desarrollar un “ecosistema”/red en torno a sus productos o servicios.
• Comunidades “dirigidas”, fuertemente jerarquizadas, cuyos
beneficios se basan en la gestión de la marca (trademarks)
9. Código abierto.
En conclusión…
• Ideas / realidades asociadas al “movimiento SW libre”:
• Reducción de costes (no debería ser el factor principal, pero en
ocasiones lo es)
• Mayor transparencia y visibilidad de los problemas (más personas lo
usan y analizan):
• “OS as a development method for SW that harnesses the power of
distributed peer review and transparency process” (OSI)
• Dinamización de la industria
• Se pueden desarrollar iniciativas “locales” sin tener que establecer
acuerdos costosos con el creador del SW.
• Se eliminan “barreras de entrada” en la adopción de la tecnología/SW.
• El último punto es especialmente relevante en SW para gestión de
información, normalmente considerado “no crítico” o “prescindible”:
• Sistemas de gestión de documentos
• Sistemas de gestión de contenidos.
• Sistemas de RI, indexación, etc.
10. El suministrador…
• Tipos (D. Riehle):
• “Single-vendor OS”: poseen la propiedad del código pero lo
discribuyen como OS (ej., Alfresco, Jaspersoft, MySQL)
• “Distribuidores OS”: integran componentes OS y los distribuyen a
cambio de un precio (SUSE, RedHat…). Poseen la propiedad de la
“configuración que generan a partir de distintos componentes”.
• Factores competitivos
• Uso de SW libre para reducir costes de desarrollo/despliegue.
• Venta de servicios de adaptación, mantenimiento y soporte.
• Restricción de la versión “gratuita” a ciertos casos.
• Inclusión de “componentes SW cerrados” dependiendo de la
licencia, como factor diferenciador / competitivo.
• Habilidad para configurar e integrar componentes OS.
11. El suministrador…
• Entrega código fuente como riesgo:
• El problema no está en entregar el código fuente al cliente…
• Acuerdos “escrow” – protección de la inversión del cliente.
• “Do at your risk”
• El problema está:
• Mercados cautivos para mantenimiento.
• Riesgo competitivo derivado de la redistribución.
• Asociación SW cerrado y venta de licencias:
• Reducción de fuente de ingresos.
• ¿Hasta cuándo se puede mantener el código cerrado?
• “Hasta que el mercado lo permita”
• Hasta que alguien ofrezca una alternativa libre equivalente.
• Mientras tu SW siga teniendo un factor diferenciador respecto a los
demás.
13. El usuario…
• Beneficios:
• Evita la “cautividad” respecto al suministrador del SW.
• El mantenimiento puede ser hecho por otras organizaciones, personal
propio, etc.
• Menor coste derivado del no-pago de licencias.
• Si se permite la redistribución copias y su uso, se reducen costes
de forma ostensible.
• Interoperabilidad con otros productos, la facilidad de
personalización, o los costes de migración, soporte y
mantenimiento**.
** Fuente: CENATIC “Encuesta sobre el Software de Fuentes Abiertas en la Administración General del
Estado (ESFA-AGE). 2011”
15. El usuario…
• Dudas y aspectos a considerar Riesgos en la
adopción:
• Violación de licencias
• ¿Cuándo adoptar SW OS?
• Nivel de compromiso de la organización con SW OS
• En qué medida el SW es fácil de mantener.
• Quién puede mantener y evolucionar ese SW con garantías.
• Se adquieren mayores responsabilidades para gestionar ese SW
como un activo de mi organización.
16. El usuario…
• ¿Cuándo considerar la adopción de SW OS?**
• En el momento de renovar licencias de SW propietario, especialmente
servidores de aplicación, bases de datos y SO.
• Se está restructurando la estructura TI por cuestiones técnicas o reducción
de costes.
• Hay productos OS maduros que cumplen con los requisitos de la
organización con pocas (o sin) necesidad de modificaciones.
• “What we are seeing is and increasing demand for OS based on
quality, reliability and speed, not just cost savings.”
• El usuario percibe más valor por su inversión en la adquisición de
servicios en torno al SW, que en la tradicional adquisición de
licencias.
** Fuente: ACCENTURE. Driving Enterpris Agility and High Performance (2012)
17. El usuario…
• Nivel de compromiso / participación**
• Estudio centrado en empresas automoción Alemania (25, 50% industria europea
respecto a ingresos).
• Etapas:
• Sourcing Se acepta la adopción / incorporación del SW OS a la organización.
• Initiating Se pone en marcha y se inician proyectos SW OS
• Contributing Se vuelca la experiencia interna a la comunidad OS
• El sourcing debe hacerse de forma sistemática, atendiendo a la complejidad
de las licencias y a los riesgos de licencias contaminantes.
• La contribución a la comunidad OS se aprecia como una oportunidad de:
• Definir estándares
• Evitar divergencias locales respecto a otras implementaciones.
• Crear alternativas a las ya existentes.
• Las motivaciones “personales” o “psicológicas” (reconocimiento, aportación a
la comunidad, etc.) no se identificaron como relevantes.
** Fuente: FAU Nürmberg Universität / BearingPoint. FOSS Management Study (2012)
18. El usuario…
Mantenibilidad del SW
• Aspectos generales
• ¿En qué medida es fácil mantener o evolucionar un SW?
• En el caso del SW cerrado, no se suele prestar atención a este factor.
• Es una “responsabilidad” del suministrador.
• Depende de varios factores:
• Características estructurales del código: complejidad, anidamientos, etc.
• Comentarios y explicaciones que incorpora el SW.
• Calidad de la documentación necesaria para mantener el SW
• Trazabilidad y relación entre especificaciones, diseño y ficheros de código.
• Cumplimiento de estándares de codificación.
• Disponibilidad de pruebas.
• Disponibilidad de procedimientos de generación, despliegue, instalación…
• Son aspectos “medibles” y evaluables de forma objetiva
• Ejemplo: estudios de Riehle con resultados satisfactorios, aunque
parciales.
19. El usuario…
Mantenibilidad del SW
• ¿Qué debemos considerar?
• Qué las características que determinan la mantenibilidad del SW
se cumplan.
• Incorporar dichas cláusulas a los contratos.
• No siempre se puede controlar en su totalidad este aspecto, dado
que:
• El OS se construye a partir de otros software OS existentes, versiones
previas…
• Pero, se debe exigir para las evoluciones que se realizan.
• No confundir:
• SW con “código fuente”.
• “menor coste” con “menor rigor en el desarrollo del SW”
20. El usuario…
Quién y cómo debe mantener y evolucionar el SW con garantías
• Aspectos generales
• No debe confundirse “saber programar” con “poder mantener y
evolucionar un software”.
• Se requiere:
• Recursos cualificados
• Compromiso con el usuario a largo plazo Vocación empresarial.
• El responsable del mantenimiento debe asegurar la
“mantenibilidad futura” de su trabajo, incluso por terceras partes.
• En el estudio antes citado** se señala que los procesos que
gobiernan el uso de SW OS pueden considerarse “patchwork, at
best”
** Fuente: FAU Nürmberg Universität / BearingPoint. FOSS Management Study (2012)
21. El usuario…
Quién y cómo debe mantener y evolucionar el SW con garantías
• ¿Qué debemos considerar?
• Debe evaluarse la competencia técnica y la capacidad de
gestión de los suministradores potenciales.
• Metodologías de despliegue y buenas prácticas en el
mantenimiento del SW.
• Mantenimiento del SW “Miniciclo de desarrollo”.
• Todas las actividades de desarrollo de SW, deben ejecutarse en una
actividad de mantenimiento, aún a menor escala…
• El éxito del SW libre exige un enfoque profesional / empresarial.
• Red de socios cualificados
• Certificaciones personales
• Formación continua del personal, planificada, no “reactiva”.
• Disponibilidad de una infraestructura y recursos para dar ese
mantenimiento.
• Compromiso con el usuario
22. El usuario…
El SW como activo de mi organización
• Aspectos generales
• Tradicionalmente, el suministrador “atiende” a las necesidades de
configuración de sus usuarios:
• Disponibilidad de versiones anteriores
• Compatibilidad hacia atrás de nuevas versiones
• Evitar que los cambios que se hacen en una nueva versión, impliquen que
algo que se había hecho sobre una anterior deje de funcionar.
• Atiende la migración a nuevas versiones
• Instrucciones detalladas para la migración entre versiones.
• Adaptaciones para nuevas versiones de sistemas operativos.
• Soporte y atención a usuarios.
23. El usuario…
El SW como activo de mi organización
• ¿Qué debemos considerar?
• Debe prestarse mayor atención al control de la configuración de
versiones: archivo seguro, procedimientos de generación de
binarios, saber qué versiones, parches, logbooks, etc., han sido
desplegados, etc.
• Debe atenderse a posibles errores y problemas identificados por la
“comunidad” o por el creador del SW (monitorización externa).
• Debe controlarse la disponibilidad de “parches”, su aplicabilidad,
etc.
• Deben establecerse mecanismos de atención y soporte a
usuarios…
• .., o en su defecto:
• Se deben subcontratar estas actividades
24. El usuario…
Conclusiones
• El despliegue de SW libre presenta una exigencias
adicionales al “modelo tradicional” relativas a su gestión:
• Mayor Libertad Mayor responsabilidad.
• Se requiere:
• Atender a la mantenibilidad del código fuente.
• Características, documentación, pruebas, etc.
• Para no comprometer las libertades 2 y 4.
• Control del código fuente – y la capacidad de gestionarlo - como
un activo de la organización.
• Disponer de procedimientos de mantenimiento y “vigilancia” de la
evolución general/global del software.
• Enfoque profesional, metodologías de mantenimiento y gestión de
servicio.
• Do it at your Risk?
25. El usuario…
Conclusiones
• Conclusiones del informe CENATIC AGE*
• La falta de personal experto en soluciones OS y la necesidad de
formación es considerado como el principal freno que dificulta la
adopción de OSS por parte de la Administración Pública.
• En licitaciones públicas de software, normalmente no se dispone
de departamentos o metodologías que evalúen la calidad del
software ofertado (79% de los organismos).
* Fuente: CENATIC “Encuesta sobre el Software de Fuentes Abiertas en la Administración General del
Estado (ESFA-AGE). 2011”
26. El usuario…
Conclusiones
• Necesidad de definir procesos y política**
¿Tiene su organización una política para…?
** Fuente: FAU Nürmberg Universität / BearingPoint. FOSS Management Study (2012)