De la multitud a la comunidad

8323 lecturas

Encontré un paper muy interesante titulado Crowds and Communities: Light and Heavyweight Models of Peer Production por Caroline A. Haythornthwaite, de la U. de Illinois. El artículo describe en detalle dos modelos de colaboración por Internet que son substancialmente distintos. El primero es el modelo del crowdsourcing, en el que hay pequeñas colaboraciones hechas por muchos individuos con poca interacción entre sí, y sin ningún compromiso en el tiempo hacia el mediano o largo plazo. El segundo es el modelo de comunidad virtual, basado en conexiones fuertes entre un conjunto de miembros que tienen un grado de compromiso alto con el proyecto que están haciendo.

Entender cómo funcionan el tipo de redes de colaboración que Internet hace posible es central. El autor de "We Think" (ver revisión en Manzana Mecánica) argumenta que uno de los grandes desafíos del siglo XX será "crear y sostener una economía de la innovación masiva en que los asuntos centrales sean cómo la gente puede colaborar más efectivamente para crear nuevas ideas.".

El caso lightweight: crowdsourcing

Haythornthwaite describe el primer tipo de red de colaboración ejemplificándolo con proyectos como SETI@Home, proyectos en que:

  • No se necesita entrenamiento para participar, ni calificaciones.
  • La tarea que hay que hacer está definida centralmente.
  • Las contribuciones individuales se realizan en unidades pequeñas.
  • El reconocimiento se obtiene en base a indicadores cuantitativos.
  • Se interactúa poco con los otros miembros de la red.
  • Se espera que uno entre y salga del proyecto cuando quiera.

El caso de SETI@Home es prototípico porque simplemente se descarga un programa y se ejecuta en un computador. Otros casos menos extremos incluyen por ejemplo la gente que reporta bugs (defectos) en programas de software libre, y la mayoría de las tareas de los sistemas de crowdsourcing como el Mechanical Turk de Amazon.

El caso heavyweight: comunidades virtuales

El segundo tipo de red de colaboración se puede ejemplificar con las comunidades científicas o las comunidades de desarrolladores que forman el núcleo de los proyectos de software libre; en este tipo de proyectos:

  • El acceso a la comunidad es selectivo.
  • La comunidad define parcial o totalmente las tareas a realizar.
  • Las contribuciones individuales se realizan en unidades de tamaño variable.
  • El reconocimiento se obtiene en base a indicadores cualitativos y cuantitativos.
  • Se interactúa bastante con los otros miembros de la red.
  • Los participantes contribuyen tiempo y esfuerzo para mantener y sostener una comunidad sana y viable.

Lo de heavyweight viene principalmente del overhead que produce el tener que mantener una comunidad, el tener un compromiso tanto con el producto de la comunidad como con la comunidad en sí. Hay más interacción con otros para aprender las reglas de la comunidad y hacerlas respetar, crear y mantener relaciones de confianza mutua, explicar lo que uno está haciendo, convencer a los otros de que la dirección que uno propone es la correcta, etc.

Democracia y comunidades virtuales

Un aspecto importante es la forma en que estas comunidades se gobiernan a sí mismas. En las comunidades de tipo lightweight, la tarea a realizar es definida en forma central y no hay mucho espacio para la participación en las decisiones que afectan la dirección del proyecto. En cambio en las comunidades de tipo heavyweight, los participantes básicamente esperan ser parte de las decisiones importantes.

Sin embargo, esta participación no tiene por qué ser democrática (1 participante = 1 voto), sino que a menudo sólo los miembros que han mostrado un compromiso más o menos estable con el proyecto tienen derecho a voto. Por ejemplo en una reciente votación sobre cambio de licencia en la Wikipedia, solamente los editores con 25 ediciones o más podían votar. Más importante aún, la votación es un mecanismo que se reserva para unas pocas decisiones; se prefiere el consenso y se le da más tribuna en la discusión a los miembros más centrales de la comunidad, a los que han acumulado más mérito.

En "We Think", Leadbeater indica que la colaboración masiva tiene éxito cuando crea comunidades que pueden sacar lo mejor de su propia diversidad. Esto sucede cuando los integrantes de la comunidad tiene una meta en común y desarrollan una forma aceptada por todos de revisar y ordenar las ideas, y un cierto tipo de liderazgo. Lo que no sucede con una comunidad así definida es que la comunidad se convierta en una democracia igualitaria. Un ejemplo es el caso de Ubuntu, una popular distribución de Linux. Hay un proceso de decisión abierto y transparente, pero que está encabezado por un comité reducido de personas. Todos pueden hacer sugerencias y enterarse de todas las decisiones y de los motivos que hay para ellas, pero la decisión es rara vez democrática. En una comunidad en que la gente aparece y desaparece todo el tiempo, una democracia igualitaria no es ni esperable ni apropiada. El mecanismo de toma de decisiones es a menudo meritocrático.

Como hemos discutido otras veces (ej.: en el caso de Ubuntu), la distribución del trabajo en los proyectos colaborativos no es uniforme:

En prácticamente todos los proyectos colaborativos hay un grupo pequeño que contribuye mucho, y un grupo grande que contribuye poco. Esto es injusto, pero los sistemas de producción por pares funcionan debido a que hay unos pocos que trabajan mucho, y al hecho de que ellos a su vez pueden beneficiarse de que hayan muchos cuyo aporte es más pequeño, pero indispensable. [Shirky]

Este sólo hecho justifica que las decisiones no sean democráticas, tanto desde un punto de vista de autoría moral (los que más trabajan deberían tener más derechos sobre cómo debe evolucionar el producto), como desde el punto de vista de la calidad de las decisiones (los que más trabajan conocen mejor el producto). En el fondo, mientras hayan mecanismos para recibir opiniones de todos los miembros de la comunidad, y un núcleo que tome buenas decisiones considerando esas opiniones sin necesariamente tomarlas como vinculantes, un proyecto puede durar mucho tiempo y dar muy buenos resultados.

Fuentes: Charles Leadbeater: "We Think". Profile Books. 2008; Caroline A. Haythornthwaite: "Crowds and Communities: Light and Heavyweight Models of Peer Production", HICSS, 2009. Fotos: Mick O Says So @ Flickr (CC), CC Chapman @ Flickr (CC)

Foto de ChaTo

— Doctor en Ciencias de la Computación, dedicado a la minería de datos en medios sociales para mejorar la respuesta durante crisis humanitarias, y para estudiar la relación entre medios tradicionales de noticias y medios sociales. +Más información »

2 Comentarios

¿Y que pasa con el contrato de debian?

A mí por lo menos la siguiente frase del contrato de Debian, me hace mucho sentido como la base para garantizar la colaboración a mediano y largo plazo:

"Nos guiaremos por las necesidades de nuestros usuarios y de la comunidad del software libre. Sus intereses serán una prioridad para nosotros."

Es decir yo veo en la meritocracia un medio para demostrar que se pueden asumir responsabilidades dentro del proyecto, pero son las necesidades e intereses generales de la comunidad son lo que establecen las directrices del proyecto, claro está decir que los coordinadores y gente más comprometida serán los encargados de interpretar hábilmente lo que la comunidad trata de comunicar cuando reportan cientos de problemas o listas de deseos. Más que _tomar las decisiones_ es compatibilizar la mirada de arriba hacia abajo que es más de mediano y largo plazo, con la mirada de abajo hacia arriba de corto plazo que imprime la dinámica de la gente que participa de forma esporádica en el proyecto.

Saludos

Referencia
http://www.debian.org/social_contract.es.html