Planificación de la adopción de software Open Source en la Administración

En el artículo anterior, ‘Adopción de software Open Source en la Administración‘, comentábamos sobre las ventajas inherentes a la adopción de software Open Source en las administraciones públicas (AA.PP.), pero también destacábamos algunas resistencias o barreras no menos importantes. En el artículo correspondiente a esta semana, trataremos de dar las líneas generales correspondientes a la planificación de esa adopción.

Vertebración del proceso de planificación Open Source en la Administración

Inicialmente, deberían crearse diversos grupos de trabajo que vertebren el proceso de arriba a abajo. Cada grupo tendría unas labores claramente identificadas, y según su carácter, podríamos clasificarlos en:

• Estratégico: planificación, presupuesto disponible y adecuación a los cambios legislativos. Configuración de un grupo de trabajo de personal con capacidad de decisión (político) y personal técnico para elaborar un plan estratégico sobre TI en los próximos años en el ámbito del Open Source. Se establecerán las distintas formas de licitación de los proyectos, así como los costes y beneficios derivados de la adopción de software de fuentes abiertas (SFA), así como su integración en el marco legislativo actual.
• Organizativo: diseñando los cambios a realizar. Un subgrupo de trabajo estudiará el impacto sobre la organización: departamentos y/o personal afectado, nuevos marcos de interrelación entre los existentes, desaparición y creación de otros puestos de trabajo… Otro subgrupo se encargará de la parte más técnica relacionada con el establecimiento de los requerimientos, la detección de software que posean un alto grado de cumplimiento de esos requerimientos, al estudio del licenciamiento de ese software y su incompatibilidad con otros, …
• Operativo: adaptando el modelo informático al administrativo. Análisis exhaustivo de adecuación de los distintos software «preseleccionados» a las necesidades y de su funcionalidad; agilidad en la operativa; posibilidades de evolución; costes directos, indirectos y ocultos (a corto y largo plazo); grado de customización sin afectar al core; estudio del grado de «salubridad» de la comunidad; interoperabilidad; integración con otros software; posibilidad de migración; etc.
• Tecnológico: creación de las infraestructuras necesarias. Detección de las nuevas infraestructuras adecuadas para soportar este despliegue tecnológico, así como su compatibilidad con las ya existentes.

Directivas Europeas para la adopción Open Source en la Administración

Esta adopción requiere ajustarse a una serie de procedimientos debidamente reglados y que principalmente se reflejan en le procedimiento OSEPA (Open Source software usage by European Public Administrations) publicado en mayo-2011 (punto 5 – Directrices y recomendaciones para la adquisición de software libre en AA.PP.).

• Planificación y preparación
  • Estudio de mercado. Visión general de lo que ofrece el mercado con la intención de detectar los productos que más se adecúen a nuestras necesidades.
  • Diferencias entre el software libre y propietario. No solo tratar de establecer las diferencias en funcionalidad y precio, sino desde el punto de vista de las ventajas que ofrece también el software libre de forma intrínseca.
  • Capacidad y disponibilidad de los recursos propios. Si la customización no puede hacerse internamente por falta de cualificación del personal o por su disponibilidad, conllevará unos costes de formación o de externalización.
  • Colaboración con otras AA.PP. Muchas AA.PP tienen requerimientos similares, la colaboración entre ellas permitiría reducir los costes de desarrollo.
  • Formación personal adquisiciones. Su formación sobre estándares abiertos, interoperabilidad, marco legal, etc., les permitirá evaluar los distintos productos en el mercado que mejor se adecúen a sus necesidades.
• Licitación y especificaciones
  • Soluciones de código abierto y propietario. La disyuntiva permitirá ejercer presión sobre las compañías de código cerrado, así como adoptar en determinadas circunstancias modelos mixtos. La licitación del open debe incluir el traslado de los derechos de propiedad a la organización pública sin restricciones sobre propósito y uso, estudio del código fuente para cualquier fin (estudio, pruebas, formación, adaptación a sus necesidades y distribución) y su uso sin limitaciones. En este caso cobra especialmente importancia la distribución, dado que permitirá transferir la solución y el know-how a otras AA.PP.
  • Cumplimiento de estándares abiertos. Ello garantizará la interoperabilidad de las soluciones mediante datos públicos seguros, accesibles y recuperables. En las licitaciones debe ser una cláusula irrenunciable que evite la dependencia de proveedores y/u obligue a los usuarios a adquirir software propietario.
  • Requisitos frente marcas. Es decir, licitación en base a cumplimiento de requisitos y funcionalidades, y no en base a fabricantes o marcas que condicionen a los usuarios.
  • Reutilización del software en toda la jerarquía de los servicios públicos. Mantener ese derecho en la licitación, evitará más dependencias de proveedores.
• Adjudicación selección / contrato
  • Madurez del software de código abierto. Conocimiento de las comunidades de desarrollo, apoyo disponible, documentación operativa y técnica, resolución de la comunidad, etc.
  • Licencias y condiciones de uso. Conocimiento de las licencias, «permisividad» de éstas, garantías, etc.
  • Costes directos, indirectos y ocultos, a corto y largo plazo.
  • Evaluación de proveedores. Detectar los proveedores fiables, maduros en las herramienta y que siguen apostando por ellas.

Si se desea ampliar información, en la página de OSEPA arriba mencionada, se encuentra bastante documentación sobre el tema: checklist para la adopción, guías de buenas prácticas, políticas de recomendación de software libre, etc.

(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).

Autor: Sergio Martínez

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly

Email