El caso por la infraestructura compartida en medios sin fines de lucro (y por qué sigue fallando)

Veinte periodistas. Nueve redacciones. Una colaboración editorial sobre inseguridad alimentaria en zonas rurales de Estados Unidos. El trabajo periodístico que surgió de la Rural News Network de INN fue realmente notable. Pero al leer este artículo sobre cómo se articuló la colaboración, no podía dejar de pensar en todo lo que omitía: cómo era la configuración técnica, de qué manera se compartían las historias entre publicaciones, si alguna de esas nueve redacciones operaba sobre plataformas compatibles. Ese tipo de detalles nunca aparece en los resúmenes. Tampoco se construye con anticipación, y ahí está exactamente el problema.

El argumento a favor de la infraestructura compartida entre medios sin fines de lucro y socios comunitarios es claro. Las organizaciones más pequeñas agrupan recursos, reducen costos redundantes y amplían su alcance sin aumentar sus presupuestos de forma proporcional. En teoría funciona. En la práctica, la mayoría de los intentos de compartir tecnología se estancan antes del año, o nunca pasan de la etapa de conversación. Quiero ser específico sobre las razones, y sobre cómo luce una configuración que realmente se sostiene en el tiempo.

Dónde suele romperse lo "compartido"

El primer punto de quiebre es el CMS. La mayoría de las redacciones pequeñas terminan usando WordPress porque es accesible y tiene un ecosistema amplio. Eso no es el problema. El problema es que cada instalación termina personalizada de manera diferente: distintos temas, distintos conjuntos de plugins, distintas estructuras de URL, distintos flujos de trabajo editoriales integrados en el panel de administración. Dos redacciones que técnicamente usan WordPress no necesariamente están corriendo sistemas compatibles. Mover contenido entre ellas requiere reformateo manual, y la sindicación se convierte en un proyecto en lugar de una función.

El segundo punto de quiebre es la propiedad y la gobernanza. Los acuerdos de hosting compartido requieren que alguien sea dueño de la cuenta, gestione las renovaciones, maneje las actualizaciones de seguridad y atienda las solicitudes de soporte. En una red de redacciones con muchos voluntarios o con poco personal, esa responsabilidad tiende a recaer sobre quien tenga mayor capacidad técnica, luego se convierte en su segundo trabajo no remunerado, y finalmente se abandona cuando esa persona se agota o se va. Sin un acuerdo claro sobre quién es responsable de qué, la infraestructura compartida se convierte en un pasivo.

El tercer punto de quiebre son las herramientas de newsletter. El correo electrónico es a menudo donde los socios de colaboración más quieren hacer promoción cruzada, pero las plataformas de newsletters están profundamente ligadas a cuentas organizacionales individuales, listas de suscriptores y reputaciones de remitente. Compartir una cuenta de Mailchimp entre organizaciones parece sencillo hasta que te das cuenta de que aplana la identidad de marca, genera complicaciones de cumplimiento en torno al consentimiento de los suscriptores, y hace casi imposible rastrear qué organización está impulsando qué crecimiento.

Qué funciona realmente

La infraestructura compartida funciona mejor cuando tiene un alcance limitado y está regida por acuerdos escritos desde el principio.

En cuanto al hosting, un solo servidor de WordPress administrado que corra múltiples instalaciones independientes bajo una misma cuenta es genuinamente rentable y técnicamente directo. Cada redacción conserva su propio sitio, su propio tema, su propio dominio. La capa compartida es el servidor, el calendario de copias de seguridad y el monitoreo de seguridad. Eso vale la pena pagarlo de forma colectiva. No vale la pena intentar fusionar los entornos editoriales encima de eso.

La sindicación es la mejor opción para compartir contenido. Una configuración liviana basada en RSS o API, donde una redacción publica y las redacciones socias pueden incorporar el contenido aprobado a su propio CMS con el formato y la atribución correctos, es mucho más duradera que intentar unificar los entornos de publicación. Mantiene el control editorial de forma local mientras hace que la distribución sea compartida. Esto es algo que puedo construir para una red y mantener sin que el personal de las redacciones tenga que aprender nada nuevo.

Para los newsletters, el modelo más conveniente es la promoción cruzada coordinada en lugar de herramientas compartidas. Cada medio conserva su propia lista y su propia cuenta en la plataforma. La colaboración toma la forma de un calendario editorial compartido, un lenguaje de promoción acordado, y quizás una página de destino con marca conjunta que captura nuevos suscriptores y los dirige a la lista correspondiente según su ubicación geográfica o preferencia de idioma. Más simple, más limpio, y capaz de sobrevivir cuando la capacidad de un socio disminuye.

La pregunta de quién construye y mantiene todo esto

Aquí voy a ser directo sobre la posición de Rainsystems. Un estudio web que trabaja principalmente con medios comunitarios y sin fines de lucro no es un proveedor de infraestructura neutral. El valor no está solo en configurar el stack técnico. Está en comprender que cualquier par de redacciones socias, incluso aquellas que sirven a comunidades cercanas, tienen audiencias distintas, identidades editoriales distintas y relaciones distintas con las personas sobre las que informan. La infraestructura compartida debería reforzar esas diferencias en lugar de nivelarlas.

La mayoría de los proyectos de infraestructura compartida en medios sin fines de lucro fracasan no porque la tecnología sea incorrecta, sino porque nadie con habilidades técnicas y conocimiento del sector mantiene la relación entre ambos. La colaboración de la Rural News Network sobre inseguridad alimentaria funcionó porque alguien se encargaba de coordinar a las partes, gestionar los plazos y mantener el proyecto en movimiento. Lo mismo aplica en el plano técnico. La infraestructura compartida sin una administración continua no es más que mantenimiento diferido.

Si tu redacción está en conversaciones tempranas sobre una alianza de contenido o una colaboración en red, el momento de pensar en la capa tecnológica es antes de publicar la primera pieza con firma conjunta. No después.