• Offray
• Blog
• 2006-12-17-SoftSocial

Software Social

Este lunes y martes que pasaron estuve en el evento de Objetos Virtuales de Aprendizaje organizado por la Fundación Karisma, con el apoyo de Politécnico Grancolombiano, el Ministerio de Educación y el Ceantic de la Javeriana. Dicho sea de paso, creo que la palabra "objeto" no es la más adecuada, pues si bien hace énfasis en la reutilización, indexación y los metadatos, es demasiado "neutral" respecto a los enfoque pedagógicos y la definición actual se puede aplicar a todo (es decir, en últimas no define nada); prefiero, entonces, el nombre Mediaciones Virtuales o Digitales.

Lo más grato, además del encuentro con la gente, fue encontrar LeMill un repositorio de mediaciones virtuales que está concebido desde el construccionismo social como fundamento teórico y que toma interesantes elecciones de diseño visibles en su implementación. Alguna vez había escrito antes sobre lo interesante que sería una infraestructura de software social que empoderara El Directorio, pero usara python en lugar de soluciones LAMP; pues bueno, LeMill parece ser esta solución y ayuda a resolver muchas de las tensiones que hemos visto en Eduwiki, en particular en lo referido a una interface más llamativa y un contenido más fácil de indexar y encontrar. Otra de las cosas es que se trata de una solución federada, lo cual permite a varias insitituciones colocar instancias de LeMill permitiendo que por ejemplo las búsquedas se hagan transparentemente entre ellas.

Definitivamente Plone es una solución que hay que tener en el radar, pues cosas como LeMill están desarrolladas en base a él y Zope. Sin embargo sigo pensando que a pesar de lo bueno, es una solución con costos de incorporación altos y una curva de aprenzaje muy inclinada y sería bueno ver como otras arquitecturas basadas en python (y en general en lenguajes de programación sintácticamente simples y poderosos), pero más sencillas van emergiendo. Esto quizás implique recorrer un camino en dos vías: Desde una arquitectura compleja y poderosa, haciéndola simple y deconstruible y desde una arquitectura simple y sin sobrecargas, haciendola compleja. Esto se podría hacer, en el primer sentido con un proyecto como migrar Eduwiki a Plone y en el segundo con extender MoinMoin para brindarle más características que se empiezan a necesitar en El Directorio. Si se cuenta con la gente interesada, podría surgir un interesante proyecto interinsitucional en ese sentido.

Hay cosas que me gustaría ver implementadas en LeMill:

• Una forma de ver las diferencias entre dos versiones históricas de un mismo documento. Teemu dice que esta solicitud es muy orientada al programador, mientras que su grupo objetivo, los educadores, podrían no estar interesados en ella. Pero hay educadores con experiencia en programación que podríamos estar muy interesados. Tal vez alguna opción "avanzada" de interface, debería habilitar los históricos de esta forma.

• Me gustaría que se soportaran diferentes lenguajes de etiquetamiento para los documentos. Plone usa Restructured Text, pero sería chévere poder ver también el documento en formato wiki de Moin, por ejemplo. De hecho la idea de que un mismo contenido debería poderse ver en más de un formato es más complicada que eso (como lo muestra Ted Nelson) y tiene que ver más con continuidad de la experiencia y sistemas de representación.

• Sería chévere que hubiera un mayor énfasis en los últimos documentos o actividades que un usuario ha estado haciendo en la plataforma. Actualmente hay un sistema de "Borradores" pero creo que puede ser mejorado.

• Como está basado en Zope, sería bueno adecuar el editor externo de éste, de modo que los contenidos que tienen un tipo mime que muestra que no pueden ser editados directamente en LeMill, puedan ser editados con una aplicación externa y que exista un control de versiones sobre ellas.

• Lo anterior nos lleva a un punto que alcancé a preguntarle brevemente a Teemu y es lo relacionado con el contenido heredado de otras plataformas y que no puede ser mostrado/editado directamente en el navegador. Teemu dice que probablemente este contenido tendría que ser reescrito por las incoveniencias que trae un contenido que funciona en una plataforma, pero no en otras, mientras que el navegador es "universal". Creo sin embargo que si este contenido está disponible en un formato abierto y es editable en software libre multiplataforma, no es necesario dicha reescritura. Bastaría con que el navegador soportara Java (lo cual la mayoría ya lo hacen y con la noticia reciente de la liberación será aún más fácil) y se podría mostar la aplicación corriendo desde un servidor remoto (en caso de que no se pueda desplegar localmente) vía VNC. Es una solución parchuda y chapucera, pero funcional. Hicimos una demostración de esta posibilidad antes en SciGWI y valdría la pena hacer más exploraciones en ese sentido (a pesar de que java sea un lenguaje que no me gusta, puede ser útil como puente con lenguajes/programas más interesantes, por su ubicuidad).
  
  

Pero las reflexiones sobre el diseño no son sólo de índole técnica. En la parte legal LeMill implementa el uso de licencias Creative Commons Attribution Share Alike y en lo conceptual las divisiones entre Contenidos, Actividades, Herramientas y Grupos tiene mucho sentido hablando desde lo educativo. El software social se debe pensar desde una óptica distinta a como se piensa el software monousuario (esta tradición de diseño desde el usuario y no desde el colectivo en realidad ha viciado mucho del diseño posterior de softwre social). Más al respecto aparece en el texto: Group as User: Flaming and the Design of Social Software, del cual quisiera resaltar algunos apartes (especialmente para nuestros recientes trolls y vándalos):

• «Flaming is one of a class of economic problems known as The Tragedy of the Commons. Briefly stated, the tragedy of the commons occurs when a group holds a resource, but each of the individual members has an incentive to overuse it. (The original essay used the illustration of shepherds with common pasture. The group as a whole has an incentive to maintain the long-term viability of the commons, but with each individual having an incentive to overgraze, to maximize the value they can extract from the communal resource.) In the case of mailing lists (and, again, other shared conversational spaces), the commonly held resource is communal attention. The group as a whole has an incentive to keep the signal-to-noise ratio high and the conversation informative, even when contentious. Individual users, though, have an incentive to maximize expression of their point of view, as well as maximizing the amount of communal attention they receive. It is a deep curiosity of the human condition that people often find negative attention more satisfying than inattention, and the larger the group, the likelier someone is to act out to get that sort of attention. [...] Like weblogs, wikis also avoid the tragedy of the commons, but they do so by going to the other extreme. Instead of everything being owned, nothing is. Whereas a mailing list has individual and inviolable posts but communal conversational space, in wikis, even the writing is communal. If someone acts out on a wiki, the offending material can be subsequently edited or removed. Indeed, the history of the Wikipedia , host to communal entries on a variety of contentious topics ranging from Islam to Microsoft, has seen numerous and largely failed attempts to pervert or delete entire entries. And because older versions of wiki pages are always archived, it is actually easier to restore damage than cause it. (As an analogy, imagine what cities would look like if it were easier to clean graffiti than to create it.)

  Weblogs and wikis are proof that you can have broadly open discourse without suffering from hijacking by flamers, by creating a social structure that encourages or deflects certain behaviors. Indeed, the basic operation of both weblogs and wiki -- write something locally, then share it -- is the pattern of mailing lists and BBSes as well. Seen in this light, the assumptions made by mailing list software looks less like The One True Way to design a social contract between users, and more like one strategy among many.»
  
  

Hablando de las posibles estratégias, he estado pensando que hacer con los Spamers, trolls y vándalos. Los primeros son poco frecuentes y el filtro de SPAM de Moin más la revisión permanente de los que estamos interesados genuinamente, ha hecho que el SPAM no cunda. Tenemos hasta ahora un sólo Troll y la estrategia social que surgió de listarlos en una página y la advertencia de no alimentarlos, ha servido bastante bien. En cuanto a los vándalos (que podrían ser los mismos trolls ya que los ataques son dirigidos a las mismas personas) la vigilancia y arquitectura ha dado buena cuenta de ellos: sabemos desde qué IP se conectan, hemos bloqueado algunas de sus páginas objetivos, pero lo mejor es que el colectivo está pendiente de ellos y los intentos infantiles de daño no tienen prácticamente repecusión. Los actos de vandalismo son de la misma lógica de las imitaciones de la infancia en la que se ponía voz de bobo y se decía "me llamo fulano y soy un bobo", la diferencia es que en lugar de la voz, editan las páginas de las personas que pretendenen ofender, como si un lector inteligente creyera que alguién puede decir algo como lo que ellos escriben sobre sí mismo, y en lugar de "soy un bobo" escriben algo relacionado con sus traumas sexuales (y me refiero a los de los vándalos). Creo que la mejor política es la de dejarlos desperdiciar su tiempo y ver cómo el control social hace que sus ediciones sean infructusas. Otra posibilidad es cambiar las políticas de edición para que sólo usuarios registrados puedan hacer ediciones (pero se perderían aportes anónimos interesantes en muchas de las páginas y el sistema de históricos, unido a la poca relevancia e impacto de los actos de vandalimo, aún no lo ameritan), una tercera opción sería permitir el ingreso de nuevos usuarios, mediante un sistema de aprobación en la cual, usuarios que ya han mostrado sentidos de pertenencia y compromiso, validen el ingreso de otros. Yo iría desde la primera, que tal vez sea la más efectiva, a las siguientes. Lo clave es cómo la arquitectura refleja, favorece y potencia las interacciones sociales de quienes la usamos.

Y los enlaces de despedida:

• Giving it Away, recomendado por Carolina Botero, explora las implicaciones sobre los modelos en los cuales los contenidos pueden circular libremente, a pesar de los intereses ya creados por las editoriales. (Un tema sobre el cual vale la pena escribir más tarde).

• Hey Dude, Where's My Data?: Argumentando razones por las cuales pienso que debemos apropiar infraestructuras (es, entre otras por eso que este Blog/Bliki está aquí y no en cualquier otro de los servicios gratuitos con infraestructuras ajenas). Estoy de acuerdo en casi todo, pero que si bien las insdustrias pueden proponer estándares, no basta con que estos sean estándares de facto, si su control sólo está en manos de una compañía y no de un colectivo más neutral. Tampoco comparto la postura respecto al software privativo versus el software libre (que el llama de código abierto versus comercial, siguiendo una larga tradición de mal uso de las palabras, particularmente en lo que a la comerciabilidad del software libre se refiere).

-- Offray 2006-12-17 18:57:07

Add your comment Markup