Bajar a la lista de etiquetas (categorías de artículos)

viernes, 27 de agosto de 2010

Una tarde de risas

Hace poco (dos semanas) fue el cumpleaños de una amiga. Fuimos un grupito de amigos a su casa, donde había invitado también a otros amigos suyos. Pasamos una buena tarde comiendo, bebiendo refrescos y jugando a varios juegos de grupo como el Party&Co o Los Hombres Lobo de Castronegro.

Fue una de las mejores tardes de mi vida, y sin una gota de alcohol.

miércoles, 25 de agosto de 2010

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:



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.

martes, 17 de agosto de 2010

Sobre la posible responsabilidad de la Administración Pública en un programa desarrollado mediante un modelo libre

Copio un artículo que acabo de publicar en la Desbitácora:

Si una Administración Pública distribuye un programa libre, tiene cierta responsabilidad con los usuarios del mismo incluso en el caso de que la propia Licencia del programa indique lo contrario, ya que, al contrario que un distribuidor cualquiera, una A. P. sí tiene una obligación legal real de velar por los receptores del programa, que son sus ciudadanos. Dicha responsabilidad puede ser mayor aún en el caso de que el usuario del programa sea la propia A. P. de modo tal que un problema en el programa suponga para aquélla la pérdida de datos de los ciudadanos o cualquier otro resultado que les perjudique.

Al mismo tiempo, crear un programa al modo de los proyectos libres implica que varias personas (los desarrolladores en quienes se tiene confianza suficiente como para permitirles acceso de escritura al repositorio), algunas de las cuales no tendrán ningún tipo de relación contractual directa ni indirecta con la A. P. que promocione el programa, podrán realizar cambios al mismo, algunos de los cuales pueden ser perjudiciales, bona fide o maliciosamente.

Parece entonces que llegamos al dilema cruel de que una A. P. debe renunciar a liberar un programa y desarrollarlo a través de una comunidad o aceptar la responsabilidad de un programa que no se encuentra bajo su control.

Sin embargo, se trata de un falso dilema, ya que hay un paso intermedio entre el desarrollo y la publicación, que es el punto en el que la A. P. puede intervenir a fin de controlar el proceso conforme a su responsabilidad sin correr el riesgo de molestar a la comunidad de desarrolladores con injerencias. Dicho punto es la liberación de versiones oficiales del programa.

El flujo de trabajo correcto para bordear adecuadamente el problema es:
  1. que los desarrolladores trabajen libremente, hasta el punto en que tal cosa sea posible para que el programa no se aleje de las especificaciones, en el repositorio de código

  2. que un grupo seleccionado de desarrolladores, responsables ante la A. P. (funcionarios, contratados por la A. P. o contratados por una empresa contratada a tal fin por la A. P.), seleccione regularmente el código de la rama «tronco» del repositorio, lo empaquete (a modo de paquete fuente o de paquetes fuente y binario) y lo publique


De este modo, los usuarios que lo deseen pueden obtener las versiones de desarrollo del código, lo cual es imprescindible para la detección de fallos en el mismo y su mejora, sin responsabilidad para la A. P., y ésta puede proporcionar versiones oficiales que hayan pasado el filtro de los desarrolladores contratados, con plena responsabilidad.

Es conveniente, pero no necesario, que la distinción entre estas dos maneras de proporcionar el código sea patente en la interfaz web del repositorio de código, con una mención del tipo «[La A. P.] no se hace responsable de los posibles fallos de estas versiones de desarrollo y niega toda responsabilidad sobre el mismo. Si no es usted un usuario avanzado, por favor utilice las versiones oficiales que puede encontrar en [sitio web].».

Ante un problema real que se produzca como consecuencia del uso del código, la estrategia de defensa de la A. P. debe variar en función de que dicho fallo se produzca en un código obtenido del repositorio o en un programa de la distribución oficial.

En el primer caso, la A. P. debe negar toda responsabilidad, indicando que el usuario sabía lo que hacía al descargar una versión de desarrollo, e indicando que el usuario asumió toda la responsabilidad al usar la interfaz web del repositorio de desarrollo del código (si lo hizo así) o indicando que el usuario era plenamente consciente del peligro de utilizar una versión de desarrollo, ya que es inconcebible que un usuario lo suficientemente avanzado como para utilizar el repositorio sin usar su interfaz web no lo sea.

En el segundo caso, la A. P. debe aceptar la plena responsabilidad por el perjuicio causado, ya que es, al menos, responsable civil subsidiario, pero al mismo tiempo debe averiguar qué desarrollador aceptó el cambio en el código que causó el problema e iniciar las acciones penales y, en su caso, disciplinarias adecuadas, ya que sin duda se trata de uno de los «desarrolladores de confianza» plenamente identificados por ser funcionarios, contratados por la A. P. o contratados por una empresa contratada a tal fin por la A. P.

lunes, 9 de agosto de 2010

¿Cómo pueden?

Acabo de darme un paseo por la Ciudad de Los Adelantados, por las calles peatonalizadas de La Laguna.

El tiempo estaba lagunero: nublado y con un punto de frío, incluso en agosto. Y los laguneros, que adoramos el tiempo típico de nuestra ciudad, andábamos por la calle. Sí, como lo oyen: 18C y un 94% de humedad nos encanta. Y no eran aún las nueve, ni siquiera las ocho y media.

Unas condiciones ideales para los comercios, ¿no?, calles llenas.

Pues debe parecerles lo contrario, a los comerciantes de Carrera, Herradores y alrededores: estaban cerrando. No dejaron de quejarse de la peatonalización misma, ahora de la crisis, y sin embargo cierran sus puertas con las calles llenas de gente. ¿Cómo pueden?

No es por el oro

Acabo de mirar mis números del Sorteo del Oro de Cruz Roja. No me ha tocado nada, pero en realidad no me importa. Comprar billetes de este sorteo puede ser por la esperanza de que te toque el premio, pero en realidad... no es por el oro.