This post is also available in: Català (Catalán) English (Inglés)

Arcilla, semillas y código fuente. Tres textos (2/3).

Presentamos tres textos sobre creación colectiva y apropiación tecnológica escritos por el colectivo artístico TAG Taller d’Intangibles entre 2006 y 2012. Los recuperamos como aportaciones que invitan a la reflexión y al debate sobre la tecnología, la creación artística colectiva, la autoridad de la autoría y la apropiación tecnológica y creativa.

El TAG Taller de Intangibles es un colectivo artístico creado en 1996 y que, especialmente en el periodo mencionado, combinó la práctica artística con la investigación, la reflexión sobre la propia práctica y la producción escrita.

El contexto sociopolítico de estos textos es el de la crisis del 2008, las primaveras árabes y los movimientos del 15M y Occupy; es posterior al movimiento contra las guerras del Golfo, a las primeras oleadas del net.art experimental, la emergencia de los sistemas wiki, la web 2.0 y las plataformas «colaborativas».

Este segundo texto se propone cuestionar el principio de autoridad que se ejerce desde la autoría o desde el conocimiento experto sobre las tecnologías que utilizamos colectivamente, explorando la posibilidad de un sistema de creación colectiva radicalmente modelable, como un bloque de arcilla, donde todo el mundo pueda ser administrador con la mínima curva de aprendizaje y con una robustez razonable que no pare el funcionamiento.

Arcilla, una invitación a enfangarse

Repensar los sistemas de creación colectiva en red

Jaume Ferrer Rosera y David Gómez Fontanills. Noviembre 2006. TAG Taller d’Intangibles · enlloc.net.

Versión 1.2 – 2021 · Licencia: Creative Commons 3.0 Atribución Compartir Igual

Publicado originariamente como a ponencia en el «Congreso de la Cibersociedad»

 

Presentación

La propuesta “Arcilla” surge del proyecto Germinador. En octubre del 2005, desde el TAG Taller de Intangibles, pusimos en marcha un proyecto para recoger y generar propuestas de creación colectiva en red.

Es una propuesta teórica destinada a estimular el debate en torno a los sistemas de creación colectiva en red. Hemos imaginado un sistema en red hipotético y lo hemos contrastado con una metáfora analógica para visualizar más claramente los retos que plantea. Proponemos partir de estos retos para revisar de una forma crítica algunos entornos de creación existentes y también para usarlos como punto de partida para generar nuevos sistemas.

“Arcilla” plantea la posibilidad de crear un sistema multiusuario en red orientado a la creación colectiva que reúna las siguientes características:

• Que pueda ser reprogramado mientras es usado
• Que la programación sea fácil para cualquier participante
• Que sea robusto a pesar de los cambios
• Que sea distribuido para garantizar un control descentralizado

El propósito de este planteamiento no es tanto conseguir un diseño como abrir un debate que nos permita cuestionar el principio de autoridad que se ejerce desde la autoría o desde el conocimiento experto sobre las tecnologías que utilizamos colectivamente.

El hecho que la creación en red se dé dentro de unos entornos de trabajo tecnológicamente mediados plantea la existencia de una finalidad y de unas condiciones que son previas a la experiencia estética de los participantes. Esto dibuja un modelo lineal según el cual primero el autor (artista, programador, diseñador…) define las condiciones de experiencia y después los participantes interaccionan bajo estas condiciones. A pesar de que la interacción entre los participantes puede hacer emerger propiedades del sistema no previstas por el autor, la experiencia se desarrolla en líneas generales según los límites fijados por el mismo diseño. Estos entornos son lineales en el sentido que implican un antes y uno después, y esta linealidad se traduce en una capacidad de control desigual sobre la experiencia. Alguien prefija unos límites que los participantes no pueden modificar posteriormente.

¿Sería posible diseñar un entorno a trabajo que los participantes pudieran modificar durante su uso, alterando completamente su finalidad y reglas, de forma que se convirtieran en coautores, no solo de la experiencia estética que implica su utilización, sino también de la que supone reprogramar el propio entorno a trabajo? Un entorno así se podría llamar no lineal porque no habría un antes y un después, sino que los momentos de definición de las condiciones de uso y la misma aplicación de estas condiciones se podrían producir en el mismo instante, y porque los participantes tomarían el control del sistema, incluida su finalidad. Se asemejaría a un proceso biológico, porque estaría diseñado de forma que su propio metabolismo, la interacción entre los participantes, lo acabara alterando completamente y lo haría evolucionar hacia un entorno diferente, de una forma imprevisible, pero al mismo tiempo asegurando que continuara siendo un entorno a trabajo entre varios usuarios.

Metafóricamente podríamos hablar de un entorno que es como la arcilla, que se puede modelar y puede tomar cualquier forma, y que si se vuelve a la cuba de amasar, se puede reciclar y puede volver a ser modelado por otras personas y con otras finalidades. Este artículo se propone apuntar algunas cuestiones básicas sobre las características que tendría que ofrecer un “entorno a arcilla” y sobre las líneas de discusión que una propuesta como esta puede conllevar.

Contexto: el germinador

Hemos estado haciendo una tarea de identificación de sistemas, prácticas y procesos, que procuramos describir mostrando las semejanzas y diferencias entre ellos. Este trabajo de recopilación también sirve para proponer variantes o generar propuestas nuevas.

De este trabajo con las propuestas surge la reflexión que quizás habría que tener en cuenta, no solo las condiciones de la experiencia sino también quién o qué factores definen estas condiciones. A partir de esta línea de pensamiento se llega al planteamiento de una propuesta donde la definición de las condiciones forme parte de aquello que puede ser cambiado. Y así surge “Arcilla” como propuesta teórica para impulsar este debate.

Empezaremos describiendo algunos modelos que nos servirán como contraste con el modelo propuesto para, después, repasar uno a uno los cuatro retos planteados en la propuesta. Explicaremos las experiencias basadas en el uso de un bloque de arcilla para explorar la relación con la metáfora y finalmente miraremos de justificar qué sentido tiene hacer una propuesta como esta y qué vías de discusión puede abrir.

Contraste: obra abierta, sistema cerrado

Parece una paradoja, pero algunas de las propuestas que facilitan los recursos y las condiciones para crear colectivamente en internet no suelen facilitar que los participantes puedan cambiar estas condiciones.

Este es el caso de algunos trabajos de ne.art, los cuales seguirían un modelo donde los participantes disfrutan de una experiencia que está limitada por unas condiciones impuestas previamente por un artista-programador. Quién crea el sistema, sea un individuo o un colectivo, ocupa una posición que no pueden ocupar el resto de participantes.

La versión fuerte de este modelo la constituiría el conjunto de casos donde el software vinculado al sistema y otros elementos creados para proporcionar la experiencia se mantienen bajo una licencia que restringe el uso e impide la modificación por parte de terceros sin el permiso de los autores. La versión débil estaría representada por aquellos casos donde el sistema es software libre y/o los otros elementos necesarios se ponen a disposición bajo una licencia copyleft que permite distribuirlos y modificarlos libremente. Supuestamente los participantes podrían clonar el sistema en otro servidor y modificarlo. Pero este tampoco es el modelo que propone “Arcilla” dónde, como veremos con más detalle más adelante, se busca eliminar la necesidad de replicar el programa o de crear líneas alternativas de desarrollo.

Contraste: capas de cebolla

Los proyectos más importantes de desarrollo de software libre nos ofrecen otro modelo donde hay un gran grupo de participantes en la experiencia y un grupo más pequeño de desarrolladores del sistema. Personas del primer grupo pueden pasar al segundo, a pesar de que el paso puede estar dificultado por normas sociales o por el nivel de conocimientos

Algunos procesos de desarrollo comunitario de software libre se han descrito utilizando la metáfora de las capas de cebolla. Según este modelo hay diferentes “capas” o niveles de implicación en el desarrollo de un software, desde una capa externa con muchos usuarios que simplemente lo utilizan y, quizás, reportan a algunos errores, a un núcleo central formado por uno (el maintainer) o pocos usuarios que deciden la incorporación de aportaciones, las líneas de desarrollo y coordinan las tareas que hay que hacer. Entremedias hay varios grados de contribución y compromiso con el proyecto. En el modelo de capas de cebolla teóricamente cualquiera persona puede pasar de una capa a la otra. El hecho de ir entrando hacia el interior puede depender de normas de elección y/o reconocimiento social, del nivel de conocimientos o la capacidad para adquirirlos y de la disponibilidad que cada cual puede destinar. Este esquema se ha utilizado para describir proyectos como el desarrollo del kernel de Linux, la distribución Debian o el software de servidor Apache (VAN WENDEL DE JOODE te alto., 2003).

El modelo de las capas de cebolla es seguramente una buena manera de organizar la producción de software optimizando los esfuerzos y estableciendo una buena comunicación entre usuarios y programadores, a la vez que crea las bases para la incorporación escalonada de nuevos desarrolladores y garantiza la continuidad del proyecto. Pero el experimento que proponemos hacer con “Arcilla” es buscar un modelo donde todos los usuarios que participan en la experiencia de creación colectiva sean (o puedan ser fácilmente) desarrolladores o transformadores potenciales de las condiciones de esta experiencia. Esto implicaría una curva de aprendizaje corta, tanto en la manera de participar en la creación colectiva como en los conocimientos para modificar el software.

Contraste: troncos y ramas

Al garantizar el acceso al código fuente y la libertad para modificarlo, el software libre hace posible que una persona, grupo u organización tome el programa y desarrolle una versión diferente. Pero a la práctica en los principales proyectos de desarrollo hay una evolución conjunta del software en un solo “tronco” al cual se van incorporando las mejoras siguiendo el modelo de las capas de cebolla. Sucesivamente se van publicando nuevas versiones que corrigen errores o incorporan nuevas funcionalidades.

Siempre es posible clonar el programa y desarrollarlo en una línea diferente a la que se está siguiendo. A eso se le llama un fork y no se da muy a menudo. Puesto que el objetivo es hacer un buen programa, crear forks equivale a dispersar los esfuerzos de la comunidad. Normalmente se crea cuando hay un conflicto dentro de esta al cual no encuentra solución. La nueva línea de desarrollo aspira a sustituir la antigua y en la mayoría de casos una sustituye la otra. Un caso menos conflictivo sería cuando un sistema muy complejo con múltiples funcionalidades se decide dividir en varios proyectos, cada uno de los cuales potenciará algún de sus aspectos.

La posibilidad de hacer forks, en un momento dado, es un mecanismo de resolución de conflictos y una garantía para evitar las tentaciones de monopolización o de apropiación excesiva de los proyectos. Pero con la propuesta Arcilla no estamos pensando ni en un sistema en versiones, ni con ramificaciones, sino en un sistema que evoluciona de manera fluida sin dejar de funcionar.

Reto: un sistema reprogramado mientras es usado

Con “Arcilla” se propone que las modificaciones se hagan “en vivo”, que se reprograme el software mientras es utilizado en red y que no haya que clonarlo para hacer modificaciones. La idea sobre cómo evoluciona el software sería más próxima a como se modifica el texto de un wiki que a cómo se modifica un programa a partir de diferentes versiones que se van publicando como beta o release. La diferencia respecto a escribir en un wiki seria que el hecho de intervenir podría modificar, no solo la estructura de los contenidos, sino la funcionalidad básica del mismo sistema como herramienta. Hasta el punto de poder convertirla en una herramienta completamente diferente. Existen entornos de programación como Emacs que admiten reprogramación, pero el reto aquí es conseguir la reprogramación en red durante el mismo uso del sistema, es decir, mientras otros usuarios lo están usando.

Reto: un sistema fácil de reprogramar

Además se plantea un escenario donde los participantes en la experiencia pasan a modificar en el programa con facilidad, desapareciendo la idea de un núcleo estable de desarrolladores. No tendría que existir una diferencia significativa entre el número de usuarios que participan de la experiencia de creación colectiva y aquellos que modifican y hacen evolucionar el software. De hecho, la idea es que potencialmente todos los usuarios son participantes y desarrolladores; la curva de aprendizaje para usar el software o para modificarlo es corta y equiparable.

Tradicionalmente se ha intentado facilitar el acceso a los conocimientos necesarios para programar de varias maneras: con lenguajes de programación que se puedan usar de forma parecida al lenguaje humano (como por ejemplo SmallTalk); formas de scripting especializadas dentro de herramientas de autor (como por ejemplo Lingo dentro de Director o ActionScript dentro de Flash), o sistemas de tags y de programación propios de algunos wikis (como por ejemplo el que proporciona Mediawiki); asistentes basados en el uso de formularios para evitar tener que escribir código fuente; o entornos de programación de lenguajes de propósito general que permiten usar una codificación más compacta y especializada en tareas de alto nivel (como por ejemplo Processing).

Todas estas son aproximaciones a tener en cuenta a la hora de pensar un «sistema de Arcilla» pero también plantean uno de los retos de la propuesta y una posible paradoja: si se simplifica la manera de programar, se podría estar creando un tipo de «lenguaje de autor» que requiere de un nivel más bajo de software trabajando por debajo y más difícil de reprogramar, el cual podría imponer sus límites a la mayoría de usuarios.

Reto: un sistema robusto

Otro reto seria que el entorno fluido capaz de ser reprogramado sin perder la funcionalidad básica de ser un entorno a trabajo colectivo, independientemente de la evolución de su finalidad y posibilidades. Habría que plantearse si las estrategias para conseguir esta consistencia implican la necesidad de mantener o no ciertas condiciones iniciales en el ámbito tecnológico o social y también de qué manera las condiciones legales de distribución afectan este objetivo.

Los sistemas de tipo CVS (Concurrent Versions System), usados en el desarrollo de software para poder trabajar con diferentes versiones; o los historiales de cambios de los wikis, nos proporcionan ejemplos de cómo se puede mantener la robustez durante un proceso de trabajo mediante el recurso de recuperar/comparar el estado actual con estados anteriores. Pero estos mecanismos plantean una nueva paradoja: la existencia de partes del sistema que, al estar encargadas de mantener el registro de cambios del mismo sistema, no tendrían que poder ser cambiadas y por tanto quedarían fuera del control de los usuarios.

Reto: un sistema distribuido

Si el entorno se mantiene en el mismo servidor de dónde ha surgido, se produce una dependencia hacia el administrador de este servidor (que directa o indirectamente podría ser el diseñador o artista que ostenta la posición de autor, el maintainer o el web-master). Habría que encontrar la forma de distribuirlo en varios servidores, o que cualquier usuario pudiera servir y administrar parcialmente o totalmente el software desde su propia máquina. Las redes de tipos P2P, la forma de funcionar de algunos netbots [y los sistemas basados en blockchain] son referentes a tener en cuenta.

Metáfora hecha realidad: arcilla analógica

La reflexión y las discusiones en torno a la propuesta Arcilla nos llevaban continuamente al referente de la metáfora y pensamos que sería interesante hacer una experiencia de creación colectiva con arcilla de verdad, el barro, la arcilla “analógica”. Así surgió “Arcilla entre manos”. En el momento de escribir este artículo hemos experimentado “Arcilla entre manos” en dos contextos muy diferentes, un festival de arte y un encuentro de hackers. Ambas experiencias tuvieron lugar durante el 2006. La primera se llevó a cabo como parte de las actividades del Germinador@lloc, en el Festival Maçart, que cada año se celebra en Maçanet de Cabrenys. La experiencia se repitió durante el Hackmeeting, el encuentro en torno al software libre, el conocimiento abierto y la escena de los hacklabs de todo el estado español, que en 2006 tuvo lugar en Mataró bajo el nombre de Hackiluro.

Durante un tiempo determinado (en ambos casos fueron 3 días) dispusimos un gran bloque de arcilla sobre una mesa en un espacio con cierta concurrencia de asistentes a los mencionados acontecimientos. Invitamos a la gente a participar en una obra colectiva en evolución modelando la pieza de barro. Les proponíamos intervenir libremente, modificando o transformando, si querían, lo que habían hecho los participantes precedentes. Solo les pedíamos que no se llevaran barro de la pieza, aparte nos preocupamos de mantener el barro húmedo, para que no se secara.

 

 

Exprimiendo la metáfora

Analizar «Arcilla entre manos» como sistema nos puede ayudar a entender los elementos clave de la propuesta teórica que planteamos con «Arcilla», y también nos ayuda a extraer elementos que sean útiles en futuras propuestas de creación colectiva. «Arcilla entre manos» se fundamenta en seis principios básicos:

1. Plasticidad: se basa en una propiedad física, no en una regla social, según la cual si la arcilla dispone del agua suficiente, mantiene la plasticidad y se puede modelar.

2. No disgregación: una regla social que consiste en el hecho que los usuarios no tendrían que llevarse fragmentos, se trata de conservar el bloque entero.

3. Mantenimiento mínimo: si la rociamos de vez en cuando para mantener su nivel de humedad, la arcilla conserva la capacidad de responder a las presiones de los usuarios y deformarse, ser acumulada, ser amasada… pero si dejamos que se seque pierde la plasticidad y queda rígida, entonces los usuarios ya no pueden seguir trabajando. En caso de sustracción requeriría que alguien añadiera más arcilla.

4. Resistencia: una vez secada del todo, si la arcilla se sumergiera en agua suficiente tiempo, podría volver a recuperar su plasticidad (siempre que no se cociera al horno). También se podría recuperar de una sustracción añadiendo nueva arcilla.

5. No especialización: trabajar sobre el bloque o cuidar de su mantenimiento no requiere conocimientos especializados, cualquier usuario puede hacerlo. Evidentemente, quien disponga de experiencia previa modelando puede sacar más partido y quizás puede llegar a resultados más controlados, pero en principio todo el mundo, disponga de experiencia o no, puede realizar aportaciones significativas de cualquier alcance.

6: Instrucciones mínimas: en principio solo hay que informar al usuario sobre la necesidad de cumplir el principio 2 y sobre como realizar el mantenimiento (principio 3).

Qué hacen los usuarios de ”Arcilla entre manos”?:

• Modifican la forma total o parcial del bloque.
• No pueden alterar sustancialmente los principios de la aplicación, a excepción del 2 (infringir la regla de conservar el bloque entero)
• A pesar de que en las experiencias realizadas no fue así, en principio cualquier usuario hubiera podido encargarse del mantenimiento (humedeciendo la arcilla si notaba que estaba demasiado seca o reintroduciendo arcilla si esta fuera disgregada).
• Los usuarios interactúan con otros usuarios:
  • Directamente hablando o gesticulando mientras trabajan en el bloque de arcilla
  • Indirectamente trabajando a partir de la modificación que han introducido otros usuarios

Observando los principios y las posibilidades de acción de los usuarios, se pueden extraer algunas conclusiones respecto a los límites del sistema:

• Aparentemente, ”Arcilla entre manso” no es sustancialmente diferente de cualquier otro sistema de creación conjunta de los que hemos tenido ocasión de estudiar (GÓMEZ, 2004)(FERRER, 2004), en el sentido que los usuarios siguen sin poder alterar los principios de la aplicación, siempre que la utilicen de forma convencional. La diferencia importante es que el sistema es tan robusto (principio 4) y su mantenimiento requiere tan poca especialización (principio 5) que cualquier usuario puede asumir el rol de administrador del sistema.
• Presenta dos puntos débiles, pero. Los principios 2 (no disgregación) y 3 (mantenimiento mínimo) son reglas sociales que pueden ser infringidas, hecho que si no fuera compensado por algún usuario que asumiera la administración podría hacer que el sistema dejara de estar orientado a la creación conjunta. Ahora bien, se trataría solo de una situación provisional. A diferencia otros sistemas, en ”Arcilla entre manso” incluso después de un periodo de no administración (secado o disgregación) cualquier usuario podría recuperar el sistema simplemente añadiendo más arcilla o amasándola de nuevo. No se requeriría la intervención de los creadores originales de la propuesta, siempre que se conservara la documentación (principio 6) o bien esta pudiera ser reconstruida por la memoria de algunos participantes.
• El aspecto más interesante es que permite cambiar algunos principios básicos que son fundamentales, concretamente el de la plasticidad (1) y el de la documentación que explica cómo usar y como mantener la arcilla (6), a pesar de que para hacerlo hay que usar el sistema de forma no convencional.
• Se pueden alterar las propiedades físicas de la arcilla cociéndola o mezclándola con otras sustancias que cambien su plasticidad (o que imposibiliten aprovecharla, por ejemplo si alguien hubiera tenido la mala idea de empotrar agujas o trozos de cristal). Por suerte, el horno necesario para cocer la arcilla o los aditivos son recursos que no estaban al alcance de la mayoría de usuarios. En Hackiluro algunos usuarios empezaron a usar un palo como herramienta de modelado que finalmente acabó siendo incorporado como estructura interna encima de la cual el bloque de arcilla logró una forma que hubiera sido imposible conseguir con arcilla sola.
• Se puede destruir o alterar la documentación modificando/incluyendo nuevas normas o eliminando el principio 2 (no disgregación). En este caso seria suficiente con reescribir el cartelito que acompaña el bloque o simplemente eliminarlo. Esta situación no se produjo. La carencia de informalidad probablemente obedece a razones diversas, pero posiblemente el contexto de los dos acontecimientos donde realizamos la experiencia y el hecho que desde el TAG asumiéramos el mantenimiento del bloque fueron factores condicionantes. En Hackiluro se crearon dinámicas paralelas donde algunos participantes colaboraron activamente en el montaje y supervisión de un sistema de captura que iba acumulando imágenes de los cambios que experimentaba el bloque a lo largo de los tres días. En cierto modo la documentación original del sistema fue expandida notablemente.

Aproximación conservadora y aproximación radical

Una de las cuestiones que “Arcilla” hace emerger con fuerza está relacionada con la fortaleza del sistema.”Arcilla entre manos” garantiza de forma razonable (si bien no absoluta) que el sistema continúe funcionando, a pesar de que el uso no convencional es la única vía de que dispone el usuario para participar en la redefinición de las condiciones generales de la experiencia de uso.

En un sistema basado en software se podría establecer el símil que la capacidad de reprogramación equivale a la plasticidad del sistema; mientras que la documentación tiene un equivalente en la documentación electrónica (explicaciones, instrucciones, letreros…), aquello que mantiene la finalidad y forma de uso del sistema y sobretodo que evita la sustracción manteniendo libre el código (condiciones de distribución). Esto nos permite definir dos formas de aproximación al problema que plantea “Arcilla”, una de conservadora y otra de radical.

Una aproximación conservadora implicaría que la misma plasticidad (capacidad de reprogramar) y la documentación del sistema (finalidad y distribución) tienen que permanecer protegidas, para garantizar que, efectivamente, el sistema admita la reprogramación y el sentido de creación conjunta (libre) pase lo que pase. Pero esto nos acerca a la idea de “arenal” o “caja de arena” escolar. Todo el mundo puede hacer y deshacer dentro de la caja de arena como entorno seguro “de pruebas”, pero no puede alterar los principios la caja de arena. Es el modelo de proyectos de creación conjunta como la Wikipedia. En este sentido, “Arcilla” solo introduciría la diferencia que no se orientaría a contenidos sino a comportamientos reprogramables, pero trabajaríamos dentro de un entorno predefinido y protegido. En este caso el reto recaería en conseguir cumplir el principio 5 (no requerir conocimientos especializados para que esté al alcance de todo el mundo).

Una aproximación radical a “Arcilla” implicaría permitir a los usuarios actuar sobre la misma plasticidad del sistema (capacidad de reprogramar) y sobre la documentación (finalidad y distribución). Teniendo en cuenta el principio 5 de no especialización, se estaría invitando explícitamente el usuario a actuar de forma no convencional, por lo tanto, en un contexto de software en red, ¿como podría “Arcilla” continuar siendo “Arcilla”, es decir, siente reprogramable y/o no propietaria? Este no es un debate nuevo, los wikis han demostrado fortaleza a pesar de la aparente debilidad que supone el acceso ilimitado a la edición de contenidos (GÓMEZ, 2005). Habría que ver hasta qué punto se podría asegurar la fortaleza cuando es el mismo código el que se deja accesible para ser editado.

Es fácil imaginarse otras cuestiones, como por ejemplo, ¿qué aporta una aproximación conservadora y que aporta una aproximación radical? Es posible una vía intermedia? ¿Es posible, no ya técnicamente sino teóricamente, una aproximación radical que supere la aparente paradoja que supone facilitar/promover usos no convencionales y al mismo tiempo pretender que se mantenga la consistencia del sistema de acuerdo con la propuesta original?

“Arcilla” como herramienta de estudio

Sin ánimo de llegar a conclusiones definitivas, dado que la investigación continúa abierta, recuperamos aquí la finalidad de “Arcilla”. Empezábamos este artículo diciendo que se trataba de una propuesta teórica, el objetivo de la cual era servir de estímulo al debate. Nos ayuda también a constatar las posibilidades que ofrece, en el campo de la creación colectiva en línea, un método basado en la formulación de propuestas teóricas como complemento de la investigación experimental:

• Facilita tomar conciencia de los diferentes modelos que existen.
• Facilita identificar las características de los sistemas.
• Nos ayuda a hacer visible los sustratos ideológicos y/o políticos en las tecnologías.
• Propicia el debate sobre la apropiación de las tecnologías y sobre la actitud que tomamos en relación con estas.
• Propicia el debate sobre la autonomía de la sociedad civil en el desarrollo tecnológico.
• Propicia el debate sobre la fractura digital por razones de conocimientos y el viejo debate sobre el acceso a los conocimientos técnicos y el ejercicio del poder en relación a estos.

Con “Arcilla” pretendemos contribuir a revisar de forma crítica los sistemas existentes pero también a imaginar nuevos sistemas. Creemos que el intento de resolver los retos planteados puede hacer visibles algunas propuestas y sistemas que parcialmente ya los resuelven, a la vez que puede ser el punto de partida de nuevas propuestas que aporten nuevas soluciones. Por lo tanto, se plantea como una herramienta de análisis orientada al estudio y a la producción en el campo de la creación colectiva en red.

 

 

 

 

 

 

 

Bibliografía

• VAN WENDEL DE JOODE, R. BRUIJN, J.A. VAN EETEN, M. J. G., 2003, Protecting the Virtual Commons: Self-Organizing Open Source Communities and Innovative Intellectual Property Regimes, The Hague: Asser Press, versió en línia (Digital Library of the Commons) http://dlc.dlib.indiana.edu/documents/dir0/00/00/10/75/
• GÓMEZ, David, 2004, Sistemes de creació col.lectiva en xarxa: cooperació i conflicte; regles formals i informals,
• GÓMEZ, David, 2005, “Wikipedia, un projecte comunitari en xarxa”, a COL·LECTIU INVESTIGACIÓ, Recerca activista i moviments socials, Barcelona: El Viejo Topo.
• FERRER, Jaume, 2004, Sistemes cooperatius i de creació col.lectiva en xarxa: conflicte, competència i cooperació entre persones, eines automatitzades i agents de software.

 

Ver también

• Video a partir de capturas de webcam de Arcilla entre manos en el HackIluro de 2006 [Archive.org].
• Primer artículo de la série “Arcilla, semillas y código fuente”: Creación colectiva: una panorámica.