Desde hace ya más de un año, un grupo de periodistas y profesionales de la comunicación nos hemos estado reuniendo para debatir en torno a los problemas y desafíos a los que se enfrenta el periodismo. Llevamos tiempo pensando que es hora de abrir el debate a más gente, recoger más ideas y puntos de vista. Por eso hemos creado BCNMediaLab.

El proyecto arranca con una serie de eventos que tendrán lugar en Barcelona cada dos meses. El primero de ellos es sobre el choque cultural que tiene lugar en empresas periodísticas con la interacción directa entre periodistas y audiencia a través de las redes sociales. ¿De quién es la cuenta de Twitter de un periodista? ¿Qué sucede con la presencia en redes sociales de un periodista destacado si deja un medio por otro? ¿Y si lo despiden? Estas son algunas de las preguntas que intentaremos responder.

Como punto de partida del BCNMediaLab, un manifiesto, una declaración de intenciones que resume en 1o puntos clave lo que pensamos de la situación actual de los medios:

El periodismo no está muerto, tampoco morirá.

No se trata de hacer un nuevo periodismo, sino de repensar las bases del periodismo. Deconstruir para volver a construir.

La autocrítica es necesaria si el periodismo quiere recuperar su credibilidad.

El periodismo necesita recuperar su función social.

El cambio tecnológico ha trastocado toda la cadena de valor. No sólo cambian los modelos de negocio sino que queda alterado el propio ejercicio de la profesión.

La tecnología es un medio, no un fin en sí mismo. Puede ser un gran instrumento para hacer mejor periodismo, pero hace falta investigación, creatividad y voluntad para querer explorarlo.

El periodismo ya no pertenece en exclusiva a sus instituciones y empresas tradicionales.

Vemos con preocupación la dificultad de las empresas periodísticas tradicionales para encontrar modelos de negocio rentables. Queremos ayudar a explorar nuevas posibilidades.

Para que exista un periodismo de calidad se debe garantizar unas condiciones jurídicas y laborales adecuadas para la persona que lo ejerce.

No sabemos cómo será el periodismo del futuro, porque somos nosotros quienes podemos escribirlo.

En internet esto no es una nueva tendencia de marketing, es el modelo de negocio de muchas empresas. De hecho, todo este buzz 2.0 se llegó a definir así: “tú haces el trabajo, ellos se llevan la pasta”. Userlabor es un protocolo abierto basado en XML que permite definir quién hace el trabajo sucio en las grandes redes sociales como Youtube, Flickr… Otra cosa será que lo incluyan.

While service providers may understand, calculate, and leverage user contribution to determine business plans and solicit advertisers, its value often remains opaque to the users. Activity logs are stored as the property of respective service providers and some providers allow access to parts of these records through their Application Programming Interfaces (API). Still, there is no means for interpreting this information universally across different services.

Yomemicontigo es uno de esos propósitos. También es el proyecto de tesis de Lola, mediante el que pretende investigar los procesos de aprendizaje colaborativo y autónomo, apoyándose en enfoques educativos como el conectivismo y el aprendizaje para toda la vida. La idea para llevar a cabo este proyecto es una red social para estudiantes de español. En ella, además de perfiles de usuario, y herramientas como blogs, foros y grupos, también habrá actividades, propuestas por Lola, como relatos colaborativos, ejercicios basados en mapas y otras cosas.

El primer paso para construir Yomemicontigo es elegir el armazón que nos servirá como base de desarrollo. En nuestro caso, elegimos Drupal, pero estuvimos valorando también otras opciones, como Dolphin, Elgg o Moodle. Siempre dentro del software libre:

• O casi. Dolphin fue rechazado desde el principio por no ser software libre. En vez de GPL, es CC-BY, y para deshacerte del enlace a BoonEx, has de pagar una cierta tarifa. Las funcionalidades están bien, pero el hecho de no ser software libre limita mucho el tamaño de la comunidad que puede aportar plugins para funcionalidades extras, o la documentación necesaria para poder personalizar el diseño.
• Moodle también fue descartado desde el principio. No es propiamente un CMS o un gestor de comunidades, sino que es propiamente un LMS. El hecho de estar diseñado tomando el curso como elemento central, con calificaciones y actividades cerradas, limitaba mucho nuestras posibilidades. Además, este enfoque es totalmente opuesto a la filosofía educativa de la que partía el proyecto, mucho más abierto e informal.
• Elgg fue uno de los candidatos con más posibilidades de ser utilizado como esqueleto del proyecto. Elgg es un gestor de comunidades y redes sociales basado en el usuario. En ese sentido, tenía todas las funcionalidades que buscábamos: perfiles, grupos, amigos, mensajes, blogs de usuario, etc. Sin embargo, carecía de versatilidad para añadir la parte de actividades. Otros puntos en contra eran la reducida comunidad de desarrolladores y una cierta fama de código enmarañado que dificultaban el desarrollo y el diseño de temas visuales propios, aunque esto parece ser que iba a cambiar en versiones posteriores.
• Sabiendo por qué no hemos escogido las aplicaciones anteriores, está claro por qué hemos escogido Drupal.

En primer lugar, está la versatilidad. Con Drupal y los módulos adecuados, se puede replicar cualquier cosa: flickr, myspace, lo que quieras. Hay cientos de módulos disponibles que amplían las funcionalidades de Drupal. De hecho, hay demasiados módulos, tanto que varias funcionalidades están cubiertas por más de un módulo, como chat o grupos, y cuesta elegir el adecuado buceando en los foros de soporte, aunque este problema está comenzando a ser resuelto con la fusión de varios proyectos.

En realidad, la duplicidad de módulos es ecológicamente efectiva, ya que la resolución de necesidades o problemas desde diferentes perspectivas enriquece el resultado final cuando varios proyectos comienzan a trabajar juntos, o uno de ellos es abandonado en beneficio de otro. La gestión de los módulos en el sitio de Drupal tampoco es la más adecuada, y no es posible distinguir cuáles son los módulos más populares (más descargados o más en uso actualmente), estables, actualizados o mejor soportados.

Para complicar las cosas, las peculiaridades del desarrollo de Drupal hacen que para cada versión se hayan de actualizar todos los módulos existentes. Eso deja obsoletos a módulos perfectamente estables, cuyo desarrollo ha sido ya abandonado. Esa es la única razón de utilizar la versión 5.7 en vez de la más reciente y muy mejorada 6.2. Módulos básicos para el proyecto como Organic Groups todavía no tienen su correspondiente versión para la rama 6.x.

La curva de aprendizaje demasiado pronunciada es otra de las críticas que se le suelen hacer a Drupal. Y es una crítica veraz, reconocida por el propio Dries Buytaert, creador e impulsor del proyecto Drupal, en la DrupalCon del 2007 en Barcelona, que fue mi primera toma de contacto con este CMS. Sin embargo, no era algo que me preocupase demasiado. Fuese cual fuese la elección que tomásemos, habría una curva de aprendizaje hasta lograr a dominar el sistema elegido. En el caso de Drupal, este aprendizaje se haría con un alto volumen de documentación disponible, una comunidad amplia y activa y con la seguridad, sabiendo que Drupal ha sido utilizado para poner en marcha versiones digitales de periódicos y revistas, de poder rentabilizar esta inversión en otros proyectos en el futuro.

La gran cantidad de documentación existente, en foros, blogs, en el propio sitio de Drupal, en libros, etc. me daba la seguridad de poder aprender a poner en marcha cualquier cosa, y de saber cómo funciona. Así, cuando llegue el momento de realizar el diseño de la interfaz de Yomemicontigo, cuento con libros, ejemplos y tutoriales suficientes para saber dónde situar cada función de PHP. El diseño de Yomemicontigo y el libro sobre los temas de Drupal que utilizaré como referencia para ayudarme tendrán su propia entrada en un futuro.

En la próxima entrada veremos la lista de módulos adicionales que hemos seleccionado, qué nos permitirán hacer y por qué hemos elegido esos módulos sobre otros adicionales.