Comments: (4)

Una “forja” para gobernanza, código y datos abiertos | GitHub & Government

CATEGORY: A+OS + cultura abierta + ⚐ ES

GitHub and Government - Organizations

GitHub es lo que en el mundo del desarrollo de software se conoce como una “forja”, una plataforma que permite a muchas personas trabajar en el mismo código de una forma distribuida, y que a través del sistema de control de versiones Git se encarga con precisión de la coordinación de las aportaciones y del control de versiones. De esta manera, cualquiera puede acceder al código fuente de un software, crear una copia, modificarlo, proponer sus modificaciones para su incorporación, crear una versión propia con otros fines…

Eso de por sí ya es de una potencia enorme, pero la gente de GitHub está siendo mucho más ambiciosa: Además de ser una de las principales plataformas para el desarrollo colaborativo de software, ahora quieren convertirse en una herramienta para colaborar en muchos otros tipos de proyecto, desde un modelo para impresión 3D hasta una normativa urbana.

GitHub y la gobernanza

La gobernanza o gobierno es una de las áreas en las que más puede aportar la filosofía de lo abierto. La transparencia de las actividades gubernamentales, el acceso a los datos públicos (que paradójicamente, no suelen publicarse) y la inclusión de los ciudadanos en los procesos de gestión y regulación de lo público son pasos fundamentales para hacer efectiva la democracia.

Con todo esto en mente se lanzó el pasado octubre la sección GitHub and Government (government.github.com), que reúne historias sobre open source (fuetne abierta), open data (datos abiertos) y open government (gobernanza abierta), destacando proyectos que usan GitHub para poner en abierto la “fuente”, publicar conjuntos de datos y hacer accesibles documentos y herramientas de gobierno.

GitHub and Government

Página web de “GitHub and Government”

Os resumo aquí, para que os hagáis una idea, algunas de estas historias, destacadas de entre las actividades de una comunidad bastante amplia:

Datos abiertos: El Open Data Portal de Chicago, que comparte una serie de conjunto de datos sobre el estado de la ciudad (carriles bici y aparcamientos, geometría de calles y edificios, pasos elevados para peatones, etc.)  para que los propios ciudadanos puedan tanto usarlos como (y aquí es donde entra GitHub) supervisarlos y actualizarlos, salvando una gran brecha burocrática y facilitando la corrección de errores y el aumento de precisión. Más info: Forking your city

Fuente abierta: El Web Experience Toolkit es un sistema abierto que permite a cualquier institución canadiense montar una página web reutilizando y adaptando una serie de componentes, sin tener que partir de cero, reduciendo el coste de desarrollo y apoyándose en soluciones con una usabilidad, accesibilidad e interoperabilidad probadas. Más info: Canadian web experience toolkit

Gobernanza abierta: Cuando los encargados de la estrategia digital de la presidencia de los Estados Unidos solicitaron a la oficina de administración electrónica que desarrollara una política de datos abiertos, ésta decidió hacerlo de manera abierta, alojando el borrador en GitHub para agilizar el desarrollo y permitir la colaboración fluida de distintas partes interesadas. El Project Open Data resultante ha recibido más de 100 actualizaciones desde entonces. Para curiosear en los detalles: Project Open Data opens more than data

La plataforma y su proyección

Aunque GitHub aún tiene su público principal en una comunidad de programadores y hackers, con este tipo de pasos intenta posicionarse como una plataforma colaborativa igualmente atractiva para makers o creadores en general y accesible para personas con menos conocimientos técnicos. Para ello están haciendo mucho por hacer más intuitivo y visual el sistema de control de versiones Git, pensado inicialmente para ser usado desde la línea de comandos.

Personalmente creo que es una apuesta acertada por llevar una herramienta de colaboración en software a otros ámbitos de la cultura abierta. Me resulta inspirador pensar que, con ciertas adaptaciones (tanto del software como de nuestros conocimientos), muchos de los que trabajamos en el ámbito de la arquitectura, la ciudad, el activismo o la política podríamos aprovechar este tipo de plataformas para trabajar de forma más abierta, colaborativa y, de paso, ordenada:

¿Os suenan nombres de archivo tipo plantageneral5_v3_final02_imprimir_def? ¿Os habéis vuelto locos alguna vez tratando de comparar dos versiones de un mismo documento, o de fundir  los cambios de uno en otro? Usar un sistema de control de versiones permite, entre otras cosas, que eso no suceda, que el trabajo se coordine y se facilite así la colaboración.

Comments (4)

Pegamos una interesante conversación que ha tenido lugar en los comentarios de Facebook:

Jorge Toledo García: Me gusta la forma en que GitHub se está posicionando como plataforma de colaboración para otros ámbitos de la cultura abierta, más allá del software libre.

Domenico Di Siena: Sí, está genial. A ver como la comunidad se lo apropia.

Alfonso Sánchez Uzábal: La filosofía que tiene GitHub detrás es muy buena. Como cuentas en el artículo, toda la plataforma funciona bajo el sistema de control de versiones git, que es distribuido. El problema que tiene github es que recentraliza lo que git distribuye. Lo que no quita que ha extendido el modelo de desarrollo colaborativo basado en el código abierto muchísimo. Llevo tiempo pensando que git es el protocolo perfecto para escribir una novela, un blog, generar un diseño o redactar una ley entre varios. Al fin y al cabo que es una novela, un diseño o una ley sino código :)

Jorge Toledo García: Bueno… según qué diseño, los códigos se complican, es difícil diseccionarlos y compararlos dentro del SCV. Con el texto todo es más fácil.
Estoy de acuerdo en que GitHub quita lo “descentralizado” a Git y lo lleva todo a su “casa”. Y además es una plataforma privativa (¿o me equivoco?), con lo cual toda la idea de adaptar, versionar, etc. el software se acaba con el suyo propio.

Alfonso Sánchez Uzábal: Sí, el código de GitHub no está disponible en GitHub Por otro lado, un diseño es exáctamente igual de diseccionable que un texto, si utilizas estándares abiertos. Por ejemplo SVG no es otra cosa que XML, es decir, línea tras línea de código. La viabilidad de desarrollar un diseño colaborativamente no tiene que ver con lo complicado que sea el código, sino con si éste es abierto o cerrado. Pocos diseños habrá más complicados que el código de Linux, por poner un ejemplo.

Jorge Toledo García: Lo sé, Alfonso, el tema es que incluso teniendo esos estándares (que en ciertos ámbitos estamos aún lejos) hay que construir visualizadores para que por ejemplo un “diff” tenga sentido para un diseñador. Mirando las diferencias en el código un SVG me hago una idea de que se ha movido un objeto X pixels a la izquierda, pero no de cómo queda eso en comparación con cómo quedaba antes. Tendría que haber una manera de hacer todo ese trabajo de revisión, comparación, combinación, etc. en el mismo formato gráfico que usamos para trabajar.

Jorge Toledo García: En el último Visualizar en Medialab Prado algunos se pusieron a trabajar en un visualizador de cambios para SVG en Inkscape. Cosas así serían la leche.

Hans Brinker: ¿Acaso hemos encontrado, por fin, una manera sencilla de colaborar en proyectos de arquitectura por internet?

Alfonso Sánchez Uzábal: Hans Brinker siempre que no uses DWG por ejemplo como formato, sí.

Jorge Toledo García: @Hans Bueno, no diría que “sencilla”… aún.

Alfonso Sánchez Uzábal: Estoy contigo, una manera de visualizar los cambios ayudaría, pero no es imprescindible. Insisto: un diseño no es diferente de un programa o un texto. Un diseño es código compilado, igual que una aplicación para el móvil. Cuando estás programando software y usas git para hacerlo colaborativamente, no estás viendo el resultado y te entiendes con los demás programadores. Todo consiste en documentar el código y ser ordenado y riguroso a la hora de trabajar: nombrar bien los commits, no incluir más de una tarea en cada commit… Creo que la cosa pasa más por aprender a usar git (y por extensión a trabajar colaborativamente) que por visualizar los cambios de otra manera.

Hans Brinker: ¡Abajo el DWG! Aunque yo lo sigo usando (por cierto, que he estado pensando de lo que estuvimos hablando en el BAT la wikipedia y colaborar… y aunque el recuerdo es un poco borroso voy sacando algunas conclusiones que iré aplicando en mi mismo con el tiempo, y que tienen que ver por ejemplo, con usar DWG, pero esto es otro tema, centremonos).
Estoy con Alfonso, creo que está mas la cosa por aprender a trabajar colaborativamente que en que sea sencillo, aunque yo, por la parte que me toca, quiera lo segundo, creo que lo primero es más importante. De todas maneras, esto de lo que hablais son cambios ya importantes y serios en un camino que siempre ha parecido posible, pero no muy real. Cuando vamos a tardar en ver ahí un proyecto “tradicional”?

Jorge Toledo García: Me gustaría ver qué dice @aitor a eso, Alfonso xD No estoy del todo convencido de lo que dices, aunque también es cierto que empiezo ahora a familiarizarme con Git y no estoy muy suelto en eso. Una diferencia que veo es que los programadores trabajan directamente con el código y por eso tiene sentido colaborar sobre él, mientras que los diseñadores trabajan, piensan y colaboran en formatos visuales que manipulan ese código por ellos. Haría falta “bajar un nivel” y no sé si sería muy práctico.

Jorge Toledo García: Hans yo, ya puestos, sí que querría que fuera fácil. Estoy de acuerdo en que conocer cómo funcionan las cosas es importante, pero si para hacer un proyecto “tradicional” tengo que hacerme casi programador y hablar en código con otros arquitectos, no creo que llegue.
El éxito de GitHub, y la razón por la que está llegando más allá de los programadores, es porque le ha dado un entorno, una interfaz y una manera de trabajar que rompe la barrera de la terminal y la acerca a lo que es habitual en otros ámbitos.

Hans Brinker: Jorge, no se si ese argumento se parece demasiado a aquellos que se negaban a usar no autocad, sino el propio ordenador para hacer arquitectura “tradicional” no hace tantos años… Lo digo porque a mi me pasa igual que a ti, me parece una barrera bastante grande de saltar tener que primero a “aprender a hablar” para poder hablar, pero es que, lo pienso y creo que no queda otra, nuevos tiempos, nuevos lenguajes, y aunque estemos muy comodos con lo que sabemos, hay que espabilar y aprender los nuevos lenguajes para no quedarse fuera de la conversación, porque nos interesa además.
Vamos, que si es necesario hacerse programados para poder hablar en codigo con otros arquitectos y poder colaborar entonces de manera sencilla, adelante, sobre todo si la otra alternativa es quedarse como estamos.

Carlos Cámara: Respecto a lo de que github centraliza lo que es distribuido no termino de compartirlo. Git es un sistema distribuido, y eso no significa que varias personas trabajan con el mismo código, sino que todas las personas tienen una copia exacta del repositorio con los cambios que han hecho todos los participantes. Eso es lo que lo diferencia de otros sistemas de control de versiones como SVN y eso significa que github es uno de los muchos lugares que tienen una copia exacta del código (un lugar que ofrece otras cosas interesantes como gestión de tareas, gestión de quipos…) Por eso mismo no hay que preocuparse: si los de github se volviesen tan evil como google o si en cualquier momento queremos mover el repositorio de un lugar a otro basta con editar la configuración del archivo .gitconf (que está en texto plano) y cambiar la url. El código y el historial se habrán movido con ello. Sí que perderíamos las funcionalidades que son de github, como pull requests, pero ese es otro tema.
Respecto a usar git para formatos gráficos me reservo la opinión para un próximo post, pero estoy convencido de que es posible. (Siempre que tengamos un formato abierto, claro)

Alfonso Sánchez Uzábal: Jorge, ¿no tiene autocad una línea de comandos que sabe usar, y usa, la mayor parte de los arquitectos? Me pongo un poco taliban, pero no me vale lo de que la línea de comandos es difícil. Por otro lado, para entender por qué es importante la línea de comandos, por qué hay que manejarla, aunque además se use una metáfora como el escritorio o la que sea: http://biblioweb.sindominio.net/tel…/command_es/node7.html
Carlos, efectivamente con gitub nuestro código no corren peligro: siempre estará en nuestras máquinas locales y en todas las máquinas de todos los programadores. Sin embargo, lo que corre peligro es la comunidad, ya que se relaciona a través de un nodo central que es github. Si github no está, ¿cómo colaborará esa comunidad? GitHub es la red social de los programadores, no es un sistema de control de versiones. Es decir, es una plataforma de comunicación que ha recentralizado las comunidades que antes eran distribuidas.

Jorge Toledo García: Creo que una cosa es usar una línea de comandos y otra distinta es comparar, discutir y gestionar los cambios en un plano mirando un XML. No digo que no sea posible, de hecho en diseño web y en diseño paramétrico se colabora mucho “en código” para hacer cosas gráficas. Pero sigo dudando, y me parece una duda constructiva, de que se pueda trasladar de forma directa la forma de colaborar de un programador a la de un arquitecto. O de que esa sea realmente la mejor solución posible.
Si todo esto suena a que la línea de comandos no me gusta o a que estoy en contra de aprender código, nada más lejos. En lo personal me planteo justo lo contrario, y por eso he aprendido a usar Git sin usar GitHub. Pero creo que no tenemos por qué conformarnos con ella si podemos construir una experiencia de colaboración mucho más cercana a nuestro flujo de trabajo.

A ver, se me ocurren dos cuestiones que necesitan aclaraciones.

Primero, no es lo mismo un diseño que un programa informático y, en concreto, es el leguaje de cada uno lo que marca una diferencia cualitativa. El lenguaje gráfico es un lenguaje natural y, como tal, su construcción se apoya en la función simbólica. Esto quiere decir que la relación entre significado y significante depende de distintas variables. Referente, referencia e interpretante, las partes constituyentes del signo, son variables (cambian). Esto implica que el lenguaje gráfico, al apoyarse sobre variables, es en sí mismo evolutivo. Cambia con el tiempo y en función del contexto, siendo su lógica interna imposible de encerrar en un conjunto de reglas sencillas.

Por el contrario, el código informático es un lenguaje formal (o lógico) que se apoya en sentidos convencionales, es decir, las relaciones entre significante y significado se establecen por convención de una forma inmutable. Esto hace que el lenguaje no evolucione y pueda ser interpretado por máquinas. Para interpretar un lenguaje natural necesitarías una inteligencia artificial.

Segundo, sobre la cuestión de la descentralización de GitHub, es con claridad una estrategia de acumulación de poder, cosa que no debe extrañarnos tratándose de un negocio.

La apuesta de GitHub es la creación de un interfaz gráfico para el uso de GIT. Esto implica la generción de metáforas visuales. Y esto implica, a su vez, dos cosas: 1) la reducción de las posibilidades de GIT ya que al añadir una capa semiótica están simplificando las opciones (si no lo entiendo mal, el interfaz de GitHub propone metáforas para algunas de las funcionalidades de GIT, pero no de todas). 2) La universalización y consolidación del la herramienta en un pubico mayoritario. La facilidad de uso (conseguida mediante la simplificación y la elaboración de metáforas visuales) junto con que la plataforma corre como una web app (sobre cualquier navegador) además de una aplicación de escritorio mientras conservan la posibilidad de la línea de comandos (comprende todo el rango de posibilidades de uso) atrae multitud de usuarios.

Lo que no hay que perder de vista es que GitHub es un negocio y, como tal, la centralización bajo su control de todo lo que se hace constituye su poder. Estoy de acuerdo en que lo ideal sería que el código de GitHub estuviera disponible y que, muy importante, el propio GitHub tiviera una estructura federal o descentralizada, pudiendo cada uno implementar nodos a su conveniencia. Naturalmente, el esfuerzo de universalización de GitHub se hace bajo criterios empresariales y esto nunca lo van a permitir.

Estoy de acuerdo con Aitor que como lenguajes, el diseño y la programación no son la misma cosa. Pero esa diferencia, a la hora de ser tratada por un sistema de control de versiones, git en este caso, no importa.

El código es código. Se puede hacer correr diff (comando UNIX que permite comparar dos archivos) sobre dos ficheros vectoriales SVG y el programa nos devolverá las diferencias entre ambos. Exactamente igual que si usamos diff con dos archivos de texto.

Jorge, dices: “Creo que una cosa es usar una línea de comandos y otra distinta es comparar, discutir y gestionar los cambios en un plano mirando un XML”. Estoy de acuerdo, es más, los programadores tampoco hacen eso. Los programadores debaten y discuten por otros muchos canales: reuniones, irc, listas de correo… y luego programan colaborativamente usando un sistema de control de versiones. Exactamente igual que podría hacer un arquitecto o un diseñador.

jorge

Sí, lo hacen por otros canales, pero lo hacen mirando el código directamente. Un código escrito en su lenguaje de programación habitual, mientras que para nosotros el “lenguaje” de trabajo es gráfico. Vamos, que ellos trabajan y gestionan usando el mismo lenguaje, y nosotros no podemos hacerlo… de momento.

En concreto, mi duda está en situaciones como la resolución de conflictos en cambios hechos a un mismo archivo, o en la comparación de versiones distintas. Dices:
Se puede hacer correr diff sobre dos ficheros vectoriales SVG y el programa nos devolverá las diferencias entre ambos. Exactamente igual que si usamos diff con dos archivos de texto.

Git me me devolverá las diferencias en el código del SVG, pero, ¿cómo sé yo qué diferencias son esas en el documento gráfico? Ahí es donde git(hub) tiene potencial aún por desarrollar (y están en ello). Las comparaciones, fusiones y demás operaciones “internas” a un archivo deberían poder hacerse en el mismo lenguaje en el que se trabaja. En el caso de la programación o la redacción de textos, coinciden, pero en el diseño no.

O eso, o los diseñadores/arquitectos/etc tendríamos que aprender un lenguaje más (varios, de hecho: uno por formato de archivo) hasta ser capaces de “ver” a través del código y no tener que mirar el resultado gráfico para saber qué hace esta o aquella línea.

Post a comment