Políticas de adquisición de Software

Esta semana el gobierno federal de Estados Unidos a través de las oficinas de Informática y de adquisiciones publicaron la Política Federal de Código Fuente, la cual espera incrementar la eficiencia en adquisición de software: cada año se estima que el gobierno federal gasta más de $6 billones en software a través de más de 42,000 transacciones. Si bien el monto es exorbitante en comparación con el gasto en software en la región, el problema específico (distintas entidades de gobierno comprando y/o desarrollando software con las mismas funcionalidades sin ningún tipo de coordinación) es muy común a muchos países. Esta breve nota presenta sólo dos aspectos que considero bastante relevantes para países que aún no cuentan con políticas similares, y no pretende ser un resumen de la política, la cual puede ser consultada en inglés directamente aquí.

Análisis de solución de software en tres pasos

Si bien el proceso recomendado es bastante sencillo, me pareció muy interesante la lista de factores que se recomienda considerar en cada una de las etapas del análisis:

• Soluciones Híbridas: Soluciones que incluyen una mezcla de soluciones existentes, comerciales y/o hechas a la medida deberían ser consideradas en todos los pasos del análisis.
• Arquitectura Modular: Las agencias deberán considerar enfoques modulares en la arquitectura de la solución final. Esto puede reducir el riesgo y el costo, incrementando a su vez la capacidad de interoperabilidad y flexibilidad tecnológica.
• Cómputo en la nube: Se recomienda a las agencias evaluar opciones de cómputo en la nube seguras a lo largo del análisis.
• Estándares abiertos: Sin perjuicio de la solución elegida, toda compra de software y desarrollo de software por parte del gobierno debe considerar el uso de estándares abiertos hasta donde sea posible. Los estándares abiertos permiten que el software pueda ser usado por cualquiera en cualquier momento, fomenta la innovación y el crecimiento independientemente de la tecnología que se use para su implementación (sea propietaria, mixta, o código abierto).
• Consideraciones específicas: Rendimiento, costo total de propiedad, seguridad y privacidad, interoperabilidad, habilidad para compartir y/o reusar, requerimientos en caso de migración de proveedor, y disponibilidad de soporte técnico de calidad, son algunos aspectos que deben ser considerados en particular.

Reuso del código y publicación de código abierto

La política enfatiza con mucha razón la necesidad de, para el caso de desarrollos hechos a la medida, que se adquieran derechos de uso que permitan, entre otros, compartir el código libremente con otras agencias federales para su uso y reuso. Adicionalmente, se solicita que cada agencia mantenga un inventario del código a la medida que desarrolle (y su documentación), el cual se pondrá a disposición de todas las agencias federales. También se pide que el código se ponga a disposición de otras agencias en la página http://www.code.gov (el portal se lanzará en los próximos tres meses).

Una de las medidas más interesantes es la exigencia de que al menos 20% del código a la medida desarrollado por cada agencia federal sea publicado como código abierto¹. La política resalta los beneficios de publicar código abierto, y se solicita a las agencias publicar el código en una manera que fomente comunidades con retos similares, mejore los mecanismos de retroalimentación y colaboración, y cree incentivos en los mismos empleados federales para que ellos también contribuyan con la comunidad de desarrollo en código abierto. Además, se listan seis principios que las agencias federales deben seguir:

• Apalancar comunidades existentes. Donde sea posible, se pide a las agencias acercarse y coordinar con comunidades existentes relevantes. Sólo se deberán crear comunidades ad-hoc cuando las existentes no satisfagan las necesidades de la agencia.
• Comprometerse en desarrollo abierto. Se pide que, en la medida de los posible, las agencias sigan prácticas de desarrollo abierto, las cuales ayudan a que el código abierto se desarrolle y pueda ser reutilizado. Entre otras, se mencionan la distribución de productos mínimos viables, involucrar al público antes del lanzamiento, y apoyarse en el conocimiento del público para mejorar los proyectos.
• Adoptar un cronograma de publicación regular. En los casos en los que no se puedan usar prácticas de desarrollo abierto, se debe establecer un cronograma de publicación incremental para poner a disposición del público el código y su documentación.
• Involucrarse con la comunidad. Se deben abrir canales de comunicación de dos vías con las comunidades de desarrollo, a fin de solicitar el apoyo y la retroalimentación del público.
• Considerar contribuciones al código. Las agencias deben anticipar y considerar la integración de aquellas contribuciones que la comunidad pueda hacer al código publicado.
• Ducumentación. Se resalta la importancia de contar con una buena documentación, aunque no conozco políticas similares a este nivel. Los ahorros que políticas de este tipo pueden generar (al interior y entre países) son muchas veces subestimados o desconocidos. El BID y la Red de Gobierno Electrónico de América Latina y el Caribe (RED GEALC) está en el proceso de crear e implementar un Mecanismo colaborativo regional de Software Público ver aquí lo cual podría ayudar a generar espacios de colaboración e innovación ue informe al público y permita facilitar el uso y la adopción del código.

Hay varios esfuerzos en Latinoamérica y el Caribe por promover el uso de código abierto.

¿Qué opinan? ¿Conocen alguna iniciativa similar? ¿Tiene su país una política de este tipo?

¹ Se han identificado excepciones (restricciones legales, riesgo de seguridad nacional, integridad y/o vulnerabilidad de los sistemas, misión u operación de las agencias, interés nacional) bajo las que una agencia puede eximirse de las obligaciones de esta política.