domingo 20 de septiembre, 2009

El MOP, la imparcialidad tecnológica y la cuestión del FLOSS

Como ya había comentado, el Ministerio de Obras Públicas (MOP) de Chile ha publicado en la red un documento preliminar sobre el uso de tecnologías de la información en el ministerio y como se puede mejorar el proceso de selección de estas tecnologías y evaluar el impacto que estas decisiones tienen en el mismo MOP y en el resto del país. De más esta decir que estos esfuerzos – sobre todo poniendo el tema en la esfera pública antes de que se tomen decisiones finales – son más bien raros y muy bienvenidos. Un análisis completo está un poco afuera de mis intereses y capacidades (muchas de la infraestructura de TI del MOP funcionan a lo que podríamos llamar «escala corporativa»), pero acá de todos modos se pueden destacar algunos temas.

Aunque el prólogo del Ministro Bitar es un poco preocupante, y temí que la discusión se reduciría a una simplemente de costos del software de código abierto vs. el software propietario1), la discusión que viene después abarca varios temas. Una cosa interesante que emerge de la discusión inicial, por ejemplo, es el hecho de que el crecimiento más o menos orgánico de la infraestructura de TI en el MOP (y uno sospecha, en el resto del Estado) ha terminado en una situación actual donde hay una mezcla de una infraestructura central con una distribuida, con sistemas adquiridos en forma ad hoc para solucionar un problema específico, etc. Es decir, muchos de los problemas de falta de definición de criterios de compra o de uso de tal o cuál plataforma son históricos y no arrastrados por un buen tiempo, y en ese sentido, son un buen reflejo de lo que ha pasado con la industria del software en general.

La parte más interesante del informe es el capítulo 6, donde se entrega un  Manifiesto MOP relativo al software, que ayudaría a la toma de decisiones por parte del MOP. Así quedan plasmados, entonces, principios que demandan Imparcialidad Tecnológica, Buenos Prácticas de Seguridad, etc. El texto definiendo cada principio es, me parece, demasiado breve, y se deberían incluir en el informe algunos casos de estudio para que los lectores pudiéramos entender como se aplicarían. Más aún, la brevedad y/o ambigüedad de las definiciones abren a veces más interrogantes. Así, mientras creo que «Buenas Prácticas de Seguridad» pueden ser definidas y juzgadas sin demasiado problema, el principio de estándares públicos es más complicado:

Todo programa, componente de software, elemento de datos y servicios asociados debe desarrollarse bajo normas de programación, estándares de codificación y herramientas de aceptación universal.

No estoy seguro que significa aceptación universal. Por ejemplo, se podría medir como penetración en el mercado, o como que son accesibles universalmente. Esas dos definiciones pueden resultar en decisiones totalmente opuestas. En la primera, una tecnología podría ser utilizada simplemente porque es popular en un momento en particular, incluso si tecnologías alternativas muestran menor penetración pero han sido desarrolladas como soluciones abiertas o donde la competencia entre proveedores es mayor. Una aclaración parece necesaria en esta sección.

En el principio de Cada decisión en su mérito, se plantea que el Costo Total de Propiedad (o TCO – Total Cost of Ownership) debería ser un pilar fundamental al momento de elegir una solución de TI para el MOP. En general, creo que esa posición es razonable, pero cabe preguntarse también si el Ministerio, como un ente estatal, no debería también considerar en su análisis de impacto los que tendría en la sociedad en general el que un ministerio particularmente poderoso adquiriera tal o cuál solución. Y aunque el tema si se menciona en otras partes del informe (p.e. en la influencia que estas políticas pueden tener en la industria local del software), no hay que olvidarse que TCO es un concepto creado y aplicado en el sector privado, que poco o nada debe preocuparse del impacto social de sus decisiones. Para el Estado el estándar es – o debería ser – mas alto, y no hay duda de que las decisiones de adquisición de infraestructura TI por parte de este reverberan en muchas otros sectores de la sociedad.

Un último principio muy interesante mencionado es el de la Replicabilidad, definido como:

Todos los productos y soluciones de software que se liciten y/o adquieran como un paquete o para los que se soliciten su diseño y construcción, deberán permitir su intervención para adaptarlos a las necesidades de otros servicios del Ministerio o incluso para su adaptación para otras reparticiones públicas.

Esto, de nuevo, parece muy razonable2, pero creo que este principio abre la puerta a lo que debe ser una discusión mucho más amplia sobre derechos de autor y el uso de software – de cualquier tipo – en el Estado, una discusión que – con todo respeto al panel de expertos informáticos que ayudaron a crear este informe – requiere invitar a otros profesionales. Esta bien claro que el desarrollo del software propietario se ha basado en la idea que este es inmodificable y que, de hecho, el que paga una licencia es un mero arrendador (por es eso es que el nombre «usuario» es el que compra la licencia, y el «dueño», el que lo escribe). Entonces, este principio parece, a simple vista, cementar una idea que personalmente me parece necesaria cuando hablamos de usar dineros públicos para desarrollar TI en el Estado: que los resultados de ese esfuerzo deberían estar disponibles para otras entidades en el Estado mismo, y como una extensión natural, a toda la ciudadanía. Me pregunto, eso sí, si esa es la idea que tenían en la cabeza los autores del Manifiesto.

Hay otras cosas interesantes en el informe, y vale la pena leerlo. Desde afuera, e interactuando con lo que frecuentemente son páginas web pobremente diseñadas, se nos olvida lo compleja que es la infraestructura que está detrás y que ocupa mucho de los recursos y las tareas que ocupan al Estado, y el informe es un paso interesante en abrir la discusión sobre un tema tan importante, que va mucho más allá de la cuestión de si deberían usar Windows o Linux (pregunta con respecto a la cuál se declaran agnósticos, en todo caso).  Esperemos que continúe.

  1. Aquí, el informa usa equivocadamente el término «licenciado» como sinónimo de propietario, pero software de código abierto o «libre» puede tener licencias asociadas (i.e. Red Hat []
  2. aunque «Replicabilidad» parece un nombre equivocado, porque sugiere copia o repetición, que no tiene mucho que ver con adaptación []

~

1 Comentario »

  1. humm.. … llamativo como queda casi «a libre interpretación» lo que debería ser claro y consistente, principios como «si lo pago lo poseo» son tan cotidianos y directos que resulta a veces exasperante ver cómo cambian las cosas cuando se mezcla con la politica

    VictorV — 20 de septiembre de 2009 @ 9:33 am

Los contenidos de este blog están publicados bajo una licencia Creative Commons Atribución-Compartir-Igual. (c) 2005-2021 El Diablo en los Detalles | Usando WordPress y una versión modificada de Barecity.