{"id":2690,"date":"2021-11-29T16:43:21","date_gmt":"2021-11-29T14:43:21","guid":{"rendered":"https:\/\/femprocomuns.coop\/?p=2690"},"modified":"2022-01-09T19:39:18","modified_gmt":"2022-01-09T17:39:18","slug":"arcilla-una-invitacion-a-enfangarse","status":"publish","type":"post","link":"https:\/\/femprocomuns.coop\/es\/arcilla-una-invitacion-a-enfangarse\/","title":{"rendered":"Arcilla, una invitaci\u00f3n a enfangarse"},"content":{"rendered":"

Arcilla, semillas y c\u00f3digo fuente. Tres textos (2\/3).<\/span><\/h2>\n

Presentamos tres textos sobre creaci\u00f3n colectiva y apropiaci\u00f3n tecnol\u00f3gica escritos por el colectivo art\u00edstico TAG Taller d\u2019Intangibles entre 2006 y 2012. Los recuperamos como aportaciones que invitan a la reflexi\u00f3n y al debate sobre la tecnolog\u00eda, la creaci\u00f3n art\u00edstica colectiva, la autoridad de la autor\u00eda y la apropiaci\u00f3n tecnol\u00f3gica y creativa.<\/strong><\/span><\/p>\n

El TAG Taller de Intangibles es un colectivo art\u00edstico creado en 1996 y que, especialmente en el periodo mencionado, combin\u00f3 la pr\u00e1ctica art\u00edstica con la investigaci\u00f3n, la reflexi\u00f3n sobre la propia pr\u00e1ctica y la producci\u00f3n escrita.<\/strong><\/span><\/p>\n

El contexto sociopol\u00edtico de estos textos es el de la crisis del 2008, las primaveras \u00e1rabes 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 \u00abcolaborativas\u00bb.<\/strong><\/span><\/p>\n

Este segundo texto<\/strong> se propone cuestionar el principio de autoridad que se ejerce desde la autor\u00eda<\/strong> o desde el conocimiento experto sobre las tecnolog\u00edas que utilizamos colectivamente, explorando la posibilidad de un sistema de creaci\u00f3n colectiva radicalmente modelable, como un bloque de arcilla, donde todo el mundo pueda ser administrador con la m\u00ednima curva de aprendizaje y con una robustez razonable que no pare el funcionamiento.<\/span><\/p>\n

<\/p>\n

\"Argila<\/p>\n

<\/h1>\n

Arcilla, una invitaci\u00f3n a enfangarse<\/h1>\n

Repensar los sistemas de creaci\u00f3n colectiva en red<\/h2>\n

Jaume Ferrer Rosera y David G\u00f3mez Fontanills. Noviembre 2006. TAG Taller d\u2019Intangibles \u00b7 enlloc.net.<\/strong><\/p>\n

Versi\u00f3n 1.2 \u2013 2021 \u00b7 Licencia: Creative Commons 3.0 Atribuci\u00f3n Compartir Igual<\/p>\n

Publicado originariamente como a ponencia en el \u00abCongreso de la Cibersociedad\u00bb<\/em><\/p>\n

 <\/p>\n

Presentaci\u00f3n<\/h2>\n

La propuesta \u201cArcilla\u201d 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\u00f3n colectiva en red.<\/p>\n

Es una propuesta te\u00f3rica destinada a estimular el debate en torno a los sistemas de creaci\u00f3n colectiva en red. Hemos imaginado un sistema en red hipot\u00e9tico<\/strong> y lo hemos contrastado con una met\u00e1fora anal\u00f3gica<\/strong> para visualizar m\u00e1s claramente los retos que plantea. Proponemos partir de estos retos para revisar de una forma cr\u00edtica algunos entornos de creaci\u00f3n existentes y tambi\u00e9n para usarlos como punto de partida para generar nuevos sistemas.<\/p>\n

\u201cArcilla\u201d plantea la posibilidad de crear un sistema multiusuario en red orientado a la creaci\u00f3n colectiva que re\u00fana las siguientes caracter\u00edsticas:<\/p>\n

    \n
  • Que pueda ser reprogramado<\/strong> mientras es usado<\/li>\n
  • Que la programaci\u00f3n sea f\u00e1cil<\/strong> para cualquier participante<\/li>\n
  • Que sea robusto<\/strong> a pesar de los cambios<\/li>\n
  • Que sea distribuido<\/strong> para garantizar un control descentralizado<\/li>\n<\/ul>\n

    El prop\u00f3sito de este planteamiento no es tanto conseguir un dise\u00f1o como abrir un debate que nos permita cuestionar el principio de autoridad<\/strong> que se ejerce desde la autor\u00eda<\/strong> o desde el conocimiento experto<\/strong> sobre las tecnolog\u00edas que utilizamos colectivamente.<\/p>\n

    El hecho que la creaci\u00f3n en red se d\u00e9 dentro de unos entornos de trabajo tecnol\u00f3gicamente mediados plantea la existencia de una finalidad y de unas condiciones que son previas a la experiencia est\u00e9tica de los participantes. Esto dibuja un modelo lineal<\/strong> seg\u00fan el cual primero el autor (artista, programador, dise\u00f1ador…) define las condiciones de experiencia y despu\u00e9s los participantes interaccionan bajo estas condiciones. A pesar de que la interacci\u00f3n entre los participantes puede hacer emerger propiedades del sistema no previstas por el autor, la experiencia se desarrolla en l\u00edneas generales seg\u00fan los l\u00edmites fijados por el mismo dise\u00f1o. Estos entornos son lineales en el sentido que implican un antes y uno despu\u00e9s, y esta linealidad se traduce en una capacidad de control desigual sobre la experiencia. Alguien prefija unos l\u00edmites que los participantes no pueden modificar posteriormente.<\/p>\n

    \u00bfSer\u00eda posible dise\u00f1ar 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\u00e9tica que implica su utilizaci\u00f3n, sino tambi\u00e9n de la que supone reprogramar el propio entorno a trabajo? Un entorno as\u00ed se podr\u00eda llamar no lineal<\/strong> porque no habr\u00eda un antes y un despu\u00e9s, sino que los momentos de definici\u00f3n de las condiciones de uso y la misma aplicaci\u00f3n de estas condiciones se podr\u00edan producir en el mismo instante, y porque los participantes tomar\u00edan el control del sistema, incluida su finalidad. Se asemejar\u00eda a un proceso biol\u00f3gico, porque estar\u00eda dise\u00f1ado de forma que su propio metabolismo, la interacci\u00f3n entre los participantes, lo acabara alterando completamente y lo har\u00eda evolucionar hacia un entorno diferente, de una forma imprevisible, pero al mismo tiempo asegurando que continuara siendo un entorno a trabajo entre varios usuarios.<\/p>\n

    Metaf\u00f3ricamente podr\u00edamos hablar de un entorno que es como la arcilla<\/strong>, 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\u00edculo se propone apuntar algunas cuestiones b\u00e1sicas sobre las caracter\u00edsticas que tendr\u00eda que ofrecer un “entorno a arcilla” y sobre las l\u00edneas de discusi\u00f3n que una propuesta como esta puede conllevar.<\/p>\n

    Contexto: el germinador<\/h2>\n

    Hemos estado haciendo una tarea de identificaci\u00f3n de sistemas, pr\u00e1cticas y procesos, que procuramos describir mostrando las semejanzas y diferencias entre ellos. Este trabajo de recopilaci\u00f3n tambi\u00e9n sirve para proponer variantes o generar propuestas nuevas.<\/p>\n

    De este trabajo con las propuestas surge la reflexi\u00f3n que quiz\u00e1s habr\u00eda que tener en cuenta, no solo las condiciones de la experiencia sino tambi\u00e9n qui\u00e9n o qu\u00e9 factores definen estas condiciones. A partir de esta l\u00ednea de pensamiento se llega al planteamiento de una propuesta donde la definici\u00f3n de las condiciones<\/strong> forme parte de aquello que puede ser cambiado. Y as\u00ed surge \u201cArcilla\u201d como propuesta te\u00f3rica para impulsar este debate.<\/p>\n

    Empezaremos describiendo algunos modelos que nos servir\u00e1n como contraste con el modelo propuesto para, despu\u00e9s, 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\u00f3n con la met\u00e1fora y finalmente miraremos de justificar qu\u00e9 sentido tiene hacer una propuesta como esta y qu\u00e9 v\u00edas de discusi\u00f3n puede abrir.<\/p>\n

    \"Germinador<\/p>\n

    Contraste: obra abierta, sistema cerrado<\/h2>\n

    \"Box<\/p>\n

    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.<\/p>\n

    Este es el caso de algunos trabajos de ne.art, los cuales seguir\u00edan un modelo donde los participantes disfrutan de una experiencia que est\u00e1 limitada por unas condiciones impuestas previamente por un artista-programador. Qui\u00e9n crea el sistema, sea un individuo o un colectivo, ocupa una posici\u00f3n que no pueden ocupar el resto de participantes.<\/p>\n

    La versi\u00f3n fuerte<\/strong> de este modelo la constituir\u00eda 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\u00f3n por parte de terceros sin el permiso de los autores. La versi\u00f3n d\u00e9bil <\/strong>estar\u00eda representada por aquellos casos donde el sistema es software libre y\/o los otros elementos necesarios se ponen a disposici\u00f3n bajo una licencia copyleft<\/em> que permite distribuirlos y modificarlos libremente. Supuestamente los participantes podr\u00edan clonar el sistema en otro servidor y modificarlo. Pero este tampoco es el modelo que propone \u201cArcilla\u201d d\u00f3nde, como veremos con m\u00e1s detalle m\u00e1s adelante, se busca eliminar la necesidad de replicar el programa o de crear l\u00edneas alternativas de desarrollo.<\/p>\n

    Contraste: capas de cebolla<\/h2>\n

    \"File:Onion<\/p>\n

    Los proyectos m\u00e1s importantes de desarrollo de software<\/em> libre nos ofrecen otro modelo donde hay un gran grupo de participantes en la experiencia y un grupo m\u00e1s peque\u00f1o 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<\/p>\n

    Algunos procesos de desarrollo comunitario de software libre se han descrito utilizando la met\u00e1fora de las capas de cebolla<\/strong>. Seg\u00fan este modelo hay diferentes “capas” o niveles de implicaci\u00f3n en el desarrollo de un software<\/em>, desde una capa externa con muchos usuarios que simplemente lo utilizan y, quiz\u00e1s, reportan a algunos errores, a un n\u00facleo central formado por uno (el maintainer<\/em>) o pocos usuarios que deciden la incorporaci\u00f3n de aportaciones, las l\u00edneas de desarrollo y coordinan las tareas que hay que hacer. Entremedias hay varios grados de contribuci\u00f3n y compromiso con el proyecto. En el modelo de capas de cebolla te\u00f3ricamente cualquiera persona puede pasar de una capa a la otra. El hecho de ir entrando hacia el interior puede depender de normas de elecci\u00f3n 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<\/em> de Linux<\/em>, la distribuci\u00f3n Debian<\/em> o el software de servidor Apache<\/em> (VAN WENDEL DE JOODE te alto., 2003).<\/p>\n

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

    Contraste: troncos y ramas<\/h2>\n

    \"Breezeicons-actions-22-state-fork<\/p>\n

    Al garantizar el acceso al c\u00f3digo fuente<\/strong> y la libertad para modificarlo, el software<\/em> libre hace posible que una persona, grupo u organizaci\u00f3n tome el programa y desarrolle una versi\u00f3n diferente. Pero a la pr\u00e1ctica en los principales proyectos de desarrollo hay una evoluci\u00f3n conjunta del software en un solo “tronco<\/strong>” 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.<\/p>\n

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

    La posibilidad de hacer forks<\/em>, en un momento dado, es un mecanismo de resoluci\u00f3n de conflictos y una garant\u00eda para evitar las tentaciones de monopolizaci\u00f3n o de apropiaci\u00f3n 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<\/strong> de manera fluida sin dejar de funcionar.<\/p>\n

    Reto: un sistema reprogramado mientras es usado<\/h2>\n
    \n

    Con \u201cArcilla\u201d se propone que las modificaciones se hagan “en vivo”, que se reprograme<\/strong> el software<\/em> mientras es utilizado en red y que no haya que clonarlo para hacer modificaciones. La idea sobre c\u00f3mo evoluciona el software<\/em> ser\u00eda m\u00e1s pr\u00f3xima a como se modifica el texto de un wiki<\/strong> que a c\u00f3mo se modifica un programa a partir de diferentes versiones que se van publicando como beta<\/em> o release<\/em>. La diferencia respecto a escribir en un wiki seria que el hecho de intervenir podr\u00eda modificar, no solo la estructura de los contenidos, sino la funcionalidad b\u00e1sica del mismo sistema como herramienta. Hasta el punto de poder convertirla en una herramienta completamente diferente. Existen entornos de programaci\u00f3n como Emacs<\/em> que admiten reprogramaci\u00f3n, pero el reto aqu\u00ed es conseguir la reprogramaci\u00f3n en red durante el mismo uso del sistema, es decir, mientras otros usuarios lo est\u00e1n usando.<\/p>\n<\/blockquote>\n

    Reto: un sistema f\u00e1cil de reprogramar<\/h2>\n

    Adem\u00e1s se plantea un escenario donde los participantes en la experiencia pasan a modificar<\/strong> en el programa con facilidad<\/strong>, desapareciendo la idea de un n\u00facleo estable de desarrolladores. No tendr\u00eda que existir una diferencia significativa entre el n\u00famero de usuarios que participan de la experiencia de creaci\u00f3n 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<\/strong> para usar el software o para modificarlo es corta y equiparable.<\/p>\n

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

    Todas estas son aproximaciones a tener en cuenta a la hora de pensar un \u00absistema de Arcilla\u00bb pero tambi\u00e9n plantean uno de los retos de la propuesta y una posible paradoja<\/strong>: si se simplifica la manera de programar, se podr\u00eda estar creando un tipo de \u00ablenguaje de autor\u00bb que requiere de un nivel m\u00e1s bajo de software trabajando por debajo y m\u00e1s dif\u00edcil de reprogramar, el cual podr\u00eda imponer sus l\u00edmites a la mayor\u00eda de usuarios.<\/p><\/blockquote>\n

    Reto: un sistema robusto<\/h2>\n

    Otro reto seria que el entorno fluido capaz de ser reprogramado sin perder la funcionalidad b\u00e1sica<\/strong> de ser un entorno a trabajo colectivo, independientemente de la evoluci\u00f3n de su finalidad y posibilidades. Habr\u00eda que plantearse si las estrategias para conseguir esta consistencia implican la necesidad de mantener o no ciertas condiciones iniciales en el \u00e1mbito tecnol\u00f3gico o social y tambi\u00e9n de qu\u00e9 manera las condiciones legales de distribuci\u00f3n afectan este objetivo.<\/p>\n

    Los sistemas de tipo CVS (Concurrent Versions System<\/em>), usados en el desarrollo de software<\/em> para poder trabajar con diferentes versiones; o los historiales de cambios de los wikis<\/em>, nos proporcionan ejemplos de c\u00f3mo 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<\/strong>: la existencia de partes del sistema que, al estar encargadas de mantener el registro de cambios del mismo sistema, no tendr\u00edan que poder ser cambiadas y por tanto quedar\u00edan fuera del control de los usuarios.<\/p><\/blockquote>\n

    Reto: un sistema distribuido<\/h2>\n
    \n

    Si el entorno se mantiene en el mismo servidor de d\u00f3nde ha surgido, se produce una dependencia hacia el administrador de este servidor (que directa o indirectamente podr\u00eda ser el dise\u00f1ador o artista que ostenta la posici\u00f3n de autor, el maintainer<\/em> o el web-master<\/em>). Habr\u00eda que encontrar la forma de distribuirlo en varios servidores<\/strong>, o que cualquier usuario pudiera servir y administrar parcialmente o totalmente el software<\/em> desde su propia m\u00e1quina. Las redes de tipos P2P, la forma de funcionar de algunos netbots<\/em> [y los sistemas basados en blockchain<\/em>] son referentes a tener en cuenta.<\/p>\n<\/blockquote>\n

    Met\u00e1fora hecha realidad: arcilla anal\u00f3gica<\/h2>\n

    La reflexi\u00f3n y las discusiones en torno a la propuesta Arcilla nos llevaban continuamente al referente de la met\u00e1fora<\/strong> y pensamos que ser\u00eda interesante hacer una experiencia de creaci\u00f3n colectiva con arcilla de verdad, el barro, la arcilla “anal\u00f3gica”. As\u00ed surgi\u00f3 \u201cArcilla entre manos\u201d. En el momento de escribir este art\u00edculo hemos experimentado \u201cArcilla entre manos\u201d en dos contextos muy diferentes, un festival de arte y un encuentro de hackers<\/em>. Ambas experiencias tuvieron lugar durante el 2006. La primera se llev\u00f3 a cabo como parte de las actividades del Germinador@lloc<\/em>, en el Festival Ma\u00e7art, que cada a\u00f1o se celebra en Ma\u00e7anet de Cabrenys. La experiencia se repiti\u00f3 durante el Hackmeeting<\/em>, el encuentro en torno al software<\/em> libre, el conocimiento abierto y la escena de los hacklabs<\/em> de todo el estado espa\u00f1ol, que en 2006 tuvo lugar en Matar\u00f3 bajo el nombre de Hackiluro<\/em>.<\/p>\n

    Durante un tiempo determinado (en ambos casos fueron 3 d\u00edas) 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\u00f3n<\/strong> modelando la pieza de barro. Les propon\u00edamos intervenir libremente, modificando o transformando, si quer\u00edan, lo que hab\u00edan hecho los participantes precedentes. Solo les ped\u00edamos que no se llevaran barro de la pieza, aparte nos preocupamos de mantener el barro h\u00famedo, para que no se secara.<\/p>\n

     <\/p>\n

    \"Argila<\/p>\n

     <\/p>\n

    Exprimiendo la met\u00e1fora<\/h2>\n

    Analizar \u00abArcilla entre manos\u00bb como sistema nos puede ayudar a entender los elementos clave de la propuesta te\u00f3rica que planteamos con \u00abArcilla\u00bb, y tambi\u00e9n nos ayuda a extraer elementos que sean \u00fatiles en futuras propuestas de creaci\u00f3n colectiva. \u00ab<\/em>Arcilla entre manos\u00bb se fundamenta en seis principios b\u00e1sicos:<\/p>\n

    1. Plasticidad:<\/strong> se basa en una propiedad f\u00edsica, no en una regla social, seg\u00fan la cual si la arcilla dispone del agua suficiente, mantiene la plasticidad y se puede modelar.<\/p>\n

    2. No disgregaci\u00f3n: <\/strong>una regla social que consiste en el hecho que los usuarios no tendr\u00edan que llevarse fragmentos, se trata de conservar el bloque entero.<\/p>\n

    3. Mantenimiento m\u00ednimo:<\/strong> 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\u00edgida, entonces los usuarios ya no pueden seguir trabajando. En caso de sustracci\u00f3n requerir\u00eda que alguien a\u00f1adiera m\u00e1s arcilla.<\/p>\n

    4. Resistencia: <\/strong>una vez secada del todo, si la arcilla se sumergiera en agua suficiente tiempo, podr\u00eda volver a recuperar su plasticidad (siempre que no se cociera al horno). Tambi\u00e9n se podr\u00eda recuperar de una sustracci\u00f3n a\u00f1adiendo nueva arcilla.<\/p>\n

    5. No especializaci\u00f3n:<\/strong> 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\u00e1s partido y quiz\u00e1s puede llegar a resultados m\u00e1s controlados, pero en principio todo el mundo, disponga de experiencia o no, puede realizar aportaciones significativas de cualquier alcance.<\/p>\n

    6: Instrucciones m\u00ednimas:<\/strong> en principio solo hay que informar al usuario sobre la necesidad de cumplir el principio 2 y sobre como realizar el mantenimiento (principio 3).<\/p>\n

    Qu\u00e9 hacen los usuarios de \u201dArcilla entre manos\u201d?:<\/p>\n