Sobre la posible responsabilidad de la Administración Pública en un programa desarrollado mediante un modelo libre (aspectos técnicos)

Copio otro artículo que acabo de publicar en la Desbitácora, segunda parte del anterior:

El modelo de trabajo en dos fases, con repositorio a cargo de la comunidad de desarrolladores y versiones oficiales a cargo de la A. P. es fácilmente implementable en los sistemas de «forja» de código actuales, y con poca dificultad en cualquier otro que se desee. Por ejemplo, el sistema ya existe en la forja de OSOR.eu. A tal fin se distingue entre tres formas de obtener el código:

• A través de los medios propios del repositorio o a través de su interfaz web


• En forma de bola 'tar' o archivo comprimido generado automáticamente por la forja


• En forma de bola 'tar', archivo comprimido o paquete (fuente o binario) creado por los desarrolladores propios de la A. P.

En los dos primeros casos el usuario obtiene una versión del código que se considera, a todos los efectos, como inestable o de desarrollo. En el tercero, el código obtenido se considera, a todos los efectos, código publicado por la A. P.

A modo de ejemplo, véase el proyecto SEXTANTE de la Junta de Andalucía alojado en OSOR.eu que nos proporciona los tres modos:

• El acceso a través de

  svn checkout https://svn.forge.osor.eu/svn/sextante

  o a través de

  http://forge.osor.eu/plugins/scmsvn/viewcvs.php/?root=sextante



• La descarga de

  http://forge.osor.eu/snapshots.php?group_id=13

  enlazada desde http://forge.osor.eu/scm/?group_id=13 e identificada como «copia nocturna»


• Los ficheros presentados en http://forge.osor.eu/projects/sextante/

Los casos a) y b) quedan claramente al alcance de cualquiera, pero sin embargo quien obtiene el código por dichas vías es plenamente consciente de que obtiene código no necesariamente comprobado, mientras que el caso c) es el resultado del esfuerzo consciente por parte de ciertos desarrolladores en empaquetar una versión determinada del código.

De esta manera, el flujo de trabajo comienza con desarrolladores que realizan cambios en el código y añaden tales cambios al repositorio. Según la confianza que se tenga en dichos desarrolladores, podrán añadirlos directamente a la rama «tronco» del repositorio o no, pero en cualquier caso dichos cambios son parte de la base de código desde ese mismo momento. Nótese que la responsabilidad es puramente personal del desarrollador que realiza el cambio, y que no se trata necesariamente de personas responsables ante la A. P.

El flujo continúa con la evaluación de dichos cambios por parte de dos grupos, los usuarios que decidan obtener esa versión del código y probarla, y con ello informar de posibles fallos o regresiones de código, y los restantes desarrolladores que decidan hacer una «revisión por iguales» del cambio y, en su caso, portarlo a otras ramas del repositorio.

El siguiente paso es que uno de los desarrolladores que sí tienen la responsabilidad ante la A. P. de seleccionar el código aceptable para su publicación haga una revisión de una serie de cambios al «tronco» del repositorio y publique una nueva versión oficial del programa. Es en este punto, y solamente en éste, donde aparece la responsabilidad de la A. P. ante los usuarios.

Queda el caso puntual de las versiones inestables oficiales, entendiendo por tales las versiones «candidatas para la liberación» que se publican por muchos proyectos, tanto libres como privativos. Dichas versiones son necesarias, casi imprescindibles, para probar el código antes de liberarlo, pero suelen publicarse de la misma manera que las versiones oficiales. Suelen contener una indicación clara de su estado no definitivo, como las letras 'rc' (Release Candidate) o el indicativo 'beta'. Sin embargo, el publicarlas de la misma manera que las versiones oficiales definitivas puede tomarse, con un poco de mala fe o de ineptitud, como indicativo de que se encuentras endosadas por la A. P.

El caso con estas versiones es que efectivamente se trata de versiones publicadas oficialmente, ya que es código que ha sido comprobado por los desarrolladores de confianza. En ese sentido la A. P. es responsable de la publicación de una versión inestable, pero es el usuario el responsable de haber elegido esa versión para su descarga estando disponible una versión estable oficial aunque sea más antigua: ningún usuario puede aducir que descargó una versión 'rc', 'beta' o '0.x' sin saber que se trata de versiones de prueba. Para reforzar este punto, versiones tales no deben presentarse en la página principal del proyecto, pero sí en la página de versiones liberadas de la forja. No es un problema que aparezcan en la zona de noticias de la página principal del proyecto si se presentan como versiones de prueba.

La diferencia presentada entre código en el repositorio y código publicado oficialmente hace posible el modelo de comunidad en el que la única normativa para ser considerado como desarrollador es haber contribuido con código válido.